Antirez, the creator of Redis, recently argued that expert programmers using AI should think of themselves as being Linus Torvalds.
The key part of his analogy is this:
Automatic programming, instead, in the hands of people that are expert technicians, or expert programmers, expert designers, expert software architects, is to assume the role of Linus, with the agents and the LLMs assuming the role of the different maintainers of the different subsystems.
This analogy does not work for me. As they exist today, I cannot be Linus and an LLM cannot be my subsystem maintainer.
Why? In one word: trust. Linus trusts his subsystem maintainers. He is able to focus on the big picture, safe in the knowledge that his lieutenants will consistently exercise good judgment in the long-term maintenance of their subsystems. He knows this because they have earned his trust by proving themselves over and over again.
Every time I have tried to give current LLMs the opportunity to prove themselves in this way, I’ve ended up regretting it. At a high level, I simply dislike too many of the decisions they make. This has happened even in areas (performance, databases, developer tool UX) where I feel qualified to judge how well an AI is doing. I’ve written about this in depth in my account of building Syntaqlite with AI, but beyond this, I’ve used LLMs in many different ways both in my job and in other side projects.
If a human behaved like this repeatedly, I would not give them ownership of any part of a project I own. Trust has to be earned, and current agents have not come close to earning enough of it for me to step back. It is much cheaper for me to stay involved while the design is taking shape than to discover at the end that a sequence of plausible local decisions added up to the wrong system.
And no, just passing tests or static verification is not enough for me. The decisions I most often dislike are precisely the ones that cannot be easily checked. Tests cannot tell me that an agent chose the wrong abstraction or produced an API that is unpleasant to use. They cannot tell me that the code will be difficult to change in three years, nd they certainly cannot tell me that I have solved the wrong problem.
None of this makes AI a bad tool. With clear parameters and enough steering, it is an extremely capable bounded implementer. AI has substantially changed what I can build, and I use it extensively every day.
But calling it a maintainer is a step too far. If I cannot trust it to exercise independent judgment, then I still have to own the code. At best, today’s AI is helping me implement my decisions; it is not freeing me to be Linus.