At Open Source Summit in Minneapolis last week, a developer told Linus Torvalds that 99% of their code is written by AI. Torvalds said he literally gets angry hearing it.
His rebuttal: 100% of code is also written by a compiler. That's been true for decades, and nobody used it to argue that programmers weren't writing the code. AI is just the next abstraction layer in a long chain: machine code, assembler, high-level languages, compilers, now AI. The responsibility doesn't move.
He's not anti-AI. He called it genuinely useful and predicted it would increase developer productivity by a factor of 10, roughly the same leap compilers once delivered. His exact words: "AI is a great tool, but it's a tool. AI is not changing programming."
Where he draws the line is shipping code you don't understand. If you can't trace the logic, can't explain why an approach was chosen, can't diagnose it when it breaks without asking the AI what it was thinking. That's a liability problem dressed up as a productivity win.
Why this matters if you're buying development work
Most people reading this aren't engineers. They're business owners who hire someone to build systems that run parts of their business. Torvalds' argument applies directly.
When a vendor says "we use AI to build faster," fine. When they can't explain how something works, why it was built the way it was, or what happens when it breaks. That's the problem.
We've seen this go wrong. A business inherits a system built quickly with AI, the developer leaves, something breaks six months later, and nobody can diagnose it because nobody actually understood it. The code ran. Understanding was assumed. It wasn't there.
The prompt is not the alibi. Whoever generated the code is responsible for what it does.
The abstraction argument
Torvalds' compiler analogy is worth sitting with.
When compilers became standard, some programmers worried they were losing touch with what the machine was actually doing. The ones who stayed sharp understood the abstraction. They knew roughly what the compiler would produce, could read the output when they needed to, and caught the cases where its decisions weren't right.
Same discipline now. A developer using AI well understands what the generated code is doing well enough to review it, change it, and debug it. A developer using AI poorly ships the output because the tests passed.
Both can claim 10x productivity. Only one of them actually delivers it. The other delivers a faster accumulation of problems.
What this looks like for us
We use AI tools in our development work. Claude, GitHub Copilot, others. We're not going to pretend otherwise, and we're not apologising for it. The speed gains are real and our clients benefit from them directly.
But our engineers review what gets generated. They understand why the code is structured the way it is. They can walk you through it in plain language if you ask. When something breaks in production, there's no moment of staring at a file nobody recognises.
That's Torvalds' actual point: you're responsible for what you ship, full stop. The tool that helped you write it is not a defence.
If you're evaluating development partners, ask them to explain how something they built actually works. Not the pitch. The code. The answer will tell you more than their AI tool list.
We've written about what realistic AI ROI looks like in year one and the specific Claude Opus 4.8 features worth paying attention to right now. The same point runs through all of it: AI amplifies skill. It doesn't replace it. The engineers who win long-term are the ones who use it to go faster while staying in command of what they ship.
