Mark Seemann, the software engineer who writes at blog.ploeh.dk, thinks the hard problem with AI-written code is not whether it can be trusted but who goes to court when it fails. His post of 12 October takes a position that a lot of engineering teams are quietly drifting toward, and then asks who pays for it.
The position belongs to someone else. Seemann opens with a tweet from Robert C. Martin, author of Clean Code, who wrote that his strategy is “to not read any of the code written by my agents.” Martin’s alternative is to surround the agents with what he called “extreme constraints”: unit tests, Gherkin tests, QA procedures, quality metrics, mutation testing and coverage. His confidence comes from the code having “run the gauntlet” of all of them. Seemann adds that Martin has since walked back his use of that approach, without saying how far.
Seemann is not Martin’s opponent on the engineering point. His first reaction was the old reflex: if nobody reads the code, how does anyone know it is correct? He then talks himself out of it. Human reading was never foolproof, he argues, and he cites Code Complete for the finding that code review is among the better ways of catching bugs, while noting that it still misses some. Test-driven development has its own blind spot: the test you never wrote leaves the system underspecified, and you may not notice.
So he lands somewhere uncomfortable for both camps. Nothing in principle, he says, stops software engineering from being run entirely by LLMs. The yardstick he borrows comes from autonomous vehicles: a machine-led process need not be flawless, it only has to beat the human-led one. He says plainly that he is not claiming we are there yet. Seemann also says that people running teams of agents, with separate agents writing tests and reviewing code, report good results.
The disagreement with the “just constrain it” crowd comes on liability. Even if defects fall below the human rate, they do not fall to zero, and Seemann sorts the leftovers into two piles. Benign errors, like a misaligned button or a miscalculated discount, can be fixed and apologized for. Serious ones cannot: a lost spacecraft, brakes that fail, a radiation overdose from a race condition, or merely a missed flight or a wrong tax bill.
His argument is that courts will not care how the code was made. He points to Dieselgate, where individual developers took the fall, and offers a fictional courtroom exchange in which a defendant says the LLM wrote the bug and the judge replies that he signed off on the release. This is speculation, and he labels his own reasoning that way. Seemann is an engineer, not a lawyer, and he does not cite a ruling or a statute on AI-generated software.
The nearest real example he offers is from the road. Færdselsstyrelsen, the Danish traffic authority, cleared Tesla’s FSD self-driving system in June 2026, with the proviso that the person in the driver’s seat remains answerable for the car. Seemann predicts drivers will relax as the system performs well, then face involuntary manslaughter charges under current Danish law when an accident does happen. The driver’s legal exposure, he says, will not depend on whether software was the real cause. His reading is that legislation lags the technology.
Martin describes a version of that bargain as his own working practice. A thorough verification stack lowers the odds of a failure, but Seemann’s point is that it may do nothing for the person whose name is on the release approval. His closing questions, whether organizations will call a failure nobody’s fault or courts will treat it as an accident, are left open on purpose.
For any company that lets agents write production code, the unresolved question is the sign-off. Before the review process goes away, decide in writing which named person approves a release and what evidence that person is relying on, because that person is the one a court is most likely to find.
Based on Mark Seemann’s blog post “Releasing AI-generated software” at blog.ploeh.dk, 12 October 2026
