Here is a small milestone in the history of software engineering. Robert C. Martin — Uncle Bob, author of Clean Code, a book whose premise is that treating source code with care is close to a professional duty — recently announced what he called his current strategy for working with AI agents:
My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, test coverage, and a plethora of others. In the end, I have very high confidence in the code they produce because they’ve had to run the gauntlet of all of my constraints and tests.
Mark Seemann, a Danish software engineer writing on his blog on October 12, takes the tweet as an occasion to ask what software engineering even is now. He is careful about the details — thought leaders’ relationships with their LLMs change so fast that anything written months ago may be stale, and Martin has since walked back his harness use — because the tweet is not really the point. The point is the shape of an industry in which a human can ship software nobody has ever read.
Seemann’s first reaction to the idea of not even looking at generated code was: how do you know it’s correct? His second reaction, which arrived about a second later, was the more interesting one. Looking at the code was never foolproof. Programmers write code believing it does one thing and discover it does something slightly different — null-reference exceptions, off-by-one errors, overlooked state mutation. Research, he notes, suggests code review is among the more effective bug-catching methods (he cites Code Complete, 2nd ed, chapter 21), and yet defects slip through systematic human inspection all the time. Eyes on the code never guaranteed anything; they just made us feel better. He has company in this skepticism — an earlier rews piece made much the same argument about code review’s limits — though the implications run in both directions.
His working definition of the discipline comes from Dave Farley’s Modern Software Engineering: software engineering boils down to rapid feedback on falsifiable predictions about the software. Under that definition, writing and reviewing source code is one way to get the feedback, not the only way. Some practitioners now run ‘teams’ of agents — one writes tests, another does review — and Seemann, once skeptical of the apparent infinite regress, has come around to the view that the human-centered practices weren’t airtight either. Even test-driven development, which he considers the most scientific approach he knows, fails in a quiet way: the most common TDD mistake is the test you never wrote, which leaves the system underspecified without anyone noticing.
From there he arrives at the self-driving-car argument. A fully LLM-driven development process doesn’t need to be perfect. It just needs to be better than the human-centered one — a bar, he points out, that human programmers never cleared themselves. He is not claiming the industry is there yet, only that there seems to be no inherent barrier. Fine. But note what the argument quietly concedes: even a better-than-human process ships bugs. Lower frequency, not zero. Which raises the question the productivity stats never answer.
Where does the liability fall? Seemann sorts defects into the benign and the worse-than-benign. A misaligned button, a discount applied incorrectly, a traffic signal stuck at red — rectifiable, mostly. Then the other kind: a lost spacecraft, a car that accelerates when you brake, a lethal radiation overdose from a race condition. Or the merely life-wrecking kind: missed flights, incorrect tax bills, lost insurance coverage. His example of the expensive-but-legal sort is the Mars Climate Orbiter, which destroyed itself in 1999 over what turned out to be a metric-unit conversion error: no laws were broken, and the only harm was 327.6 million taxpayer dollars. Still, he writes, it would be an extraordinary software organization if such an error had no consequences for anyone. In the old days the consequence had a name: Dave wrote that code.
As long as the damage stays inside the organization, the worst case for the scapegoat is getting fired. Once the error creates legal liability, the organization goes to court, and — as Dieselgate showed — individual developers can end up taking the fall. Seemann’s observation is that judicial systems will decide where responsibility lives with reference to their own logic, decoupled from how the software was actually produced. He scripts the exchange, and it has the ring of a court transcript from about five years from now:
- But, your honour, the LLM wrote the bug. - So you say, son, but you signed off on the release, didn’t you? - Yes... - I can’t send an LLM to prison, but I can sentence you.
For how this plays out in practice, he points to a recent development closer to home. In June 2026, the Danish traffic authority Færdselsstyrelsen approved Tesla’s FSD self-driving system on the condition that the human behind the wheel remains ultimately responsible and stays attentive. His prediction is grimly mechanical: the better the system performs, the more drivers zone out, and within weeks or months most will be on their phones. It will mostly go well. Then, rarely, someone dies, and under Danish law as it stands the driver faces an involuntary manslaughter charge — which usually means prison — no matter that the ‘actual’ cause sat in the software. Legislation lags technological reality; the legal system needs a person it can sentence. California wrote a version of that principle into statute last year, barring defendants from blaming autonomous AI for harm.
So here’s the trade Seemann thinks software organizations will make, because people always make it: play the odds, because the odds look compelling. No quantity of verification infrastructure changes the legal position — you can build the most elaborate gauntlet of tests and constraints in the world, and when something goes wrong, the signature on the release is still yours. The LLM made the productivity gains possible; it cannot serve the sentence. His closing question is the whole essay in one line, and it’s worth sitting with: Are you ready to go to prison for an AI?
The strange part is that the engineering argument and the legal argument no longer even disagree. Both sides now accept that nobody reads the code. Only one of them has noticed.