2026-07-28 · Being Linux Torvalds

Transcript

Transcript. Paraphrased; sources in notes.md.

HostWelcome to July 28th, 2026. I am Daniel, and joining me today is Samantha, a builder who is never afraid to tear apart a hype cycle, even if she is the one using the tools. Samantha, how are things in your corner of the stack?

GuestDaniel, it is absolute chaos, in the best way possible. I have been deep in an agentic workflow all morning, mostly trying to figure out why my AI assistant insists on using deprecated libraries. It is that classic trade off, right? You save two hours of boilerplate but spend forty minutes playing detective on the code it generated.

HostThat actually leads perfectly into our first story. Over on Lobsters, there is a fascinating debate sparked by a post from Antirez. He suggests we should look at ourselves as the Linus Torvalds of our own projects, acting as maintainers for an army of AI agents. Ladybird, for the uninitiated, is a from-scratch independent web browser, and Antirez is a well-known developer, but this analogy has ruffled some feathers.

GuestI saw this, and I have to say, the optimism in me loves the idea of scaling myself. But come on. A maintainer manages humans who have, you know, context and the ability to actually understand the design philosophy of a project. When I am shipping with agents, they do not have a mission statement. They have a context window.

HostThe Lobsters thread is pretty brutal about it. A user called typesanitizer points out that Linus Torvalds is not dealing with maintainers who suffer from short-term memory loss or make things up from thin air.

GuestExactly. Typesanitizer hits the nail on the head. If I had a human contributor who confabulated functions out of thin air, I would revoke their commit access, not call them a subsystem maintainer. Another user, steinuil, made a great point that just because you have the budget to run a swarm of models, it does not mean you are building Linux. It is a bit of a delusion of grandeur to think that volume of output equals the quality of a kernel.

HostIt feels like we are mistaking energy for direction.

GuestEnergy is cheap. Direction is the only thing that matters. I do use agents to handle my unit tests, which is a massive win, but I am the architect. If you abdicate that to the agent, you are not Linus. You are just a very confused project manager of a hallucination factory.

HostMoving from that chaos to the philosophy of computing, we have a piece on jcs.org about the tension between hand-crafting software and this new vibecoding era. The author reflects on watching Andreas Kling, who is a famous developer known for building his own OS from scratch, move from a traditional IDE to an AI-assisted one. The question here is about the soul of the work.

GuestThis one hit me hard, Daniel. I love a good tool that gets out of my way. But there is a real grief there, isn't there? A Lobsters user called tmcb put it perfectly. They said it is like being Sisyphus, but everyone is cheering for a crane lifting the boulder for you. And sure, the crane is faster, but sometimes the point of the work is the struggle with the rock.

HostIt is not just about the efficiency, it is about the isolation. Zetashift makes a comment that resonates with what you were saying earlier, that the actual useful automation is getting buried under the mountain of AI marketing.

GuestZetashift is spot on. I want better voice transcription, better tools that make my TUI experience snappier. But we are drowning in hype. It makes it hard to be a craftsperson when the community is obsessed with how much compute you can throw at a screen. I will admit, I do use a custom local model to help me parse legacy documentation, and that is legitimately helpful, but I am not letting it write my core logic. I need to know why the system works, or I am just a passenger in my own codebase.

HostFinally, let’s look at some big-picture engineering. Martin Fowler has some notes out from a recent retreat on the future of software development. The big takeaway is that we are shifting from a world where generating code is the hard part to one where verifying that code is the actual bottleneck.

GuestThis is the real talk we need. We have spent two years figuring out how to make code-gen go faster, but we have completely ignored how to check if that code is actually, you know, not a security disaster. The C-suite is pushing for this, and the disconnect from the reality of engineering is widening.

HostIt is definitely creating a new kind of shadow IT. Fowler mentions companies making decisions based on ML models trained on the wrong data, like the example of using desert-trained air filter sensors in the arctic.

GuestThat is a classic. You have an executive dashboard showing fifty million dollars in savings, but the reality is you are just breaking your field equipment because the model is misaligned with the physical environment. We are going to see a lot more of that. The verification step is where we need to put our human energy. That is why I have been spending my time building out tighter regression suites. If the machine generates it, the machine better be able to prove it does not break my production environment.

HostThat sounds like a long-term plan for a very busy afternoon.

GuestOh, it is. I am currently trying to automate the verification of the verification, which is either genius or the start of a very bad feedback loop. I am leaning toward genius, but I might change my mind by dinner.

HostI suppose we will hear about it next week. Samantha, thanks for the perspective, and thanks to everyone over on Lobsters for the lively debate today. We will be back tomorrow to do it all over again. See you then.