July 29, 2026
Stop Reading the Code
An agent just wrote three hundred lines in forty seconds. You open the diff, start reading line by line, and somewhere around line ninety…

By David Lee
4 min read
An agent just wrote three hundred lines in forty seconds. You open the diff, start reading line by line, and somewhere around line ninety your eyes glaze over. By the time you finish, you could have written half of it yourself. So what exactly did the agent buy you?
Robert Martin, the man who spent decades teaching a generation to care about every line, has a blunt answer. He says he does not read the code his agents write. He calls this the only way to actually capture the productivity of an agent. Coming from the author of Clean Code, that sounds like heresy. It is not. It is the logical end of an argument he has been making his whole career, just pointed at a new bottleneck.
The bottleneck moved
Here is the uncomfortable arithmetic. A capable agent generates code far faster than any human can read it, let alone review it with real attention. If your workflow requires a human to read every line before it ships, then your throughput is permanently capped at human reading speed. The agent is now a very expensive way to feel busy.
Think of it like the shift from hand tools to a CNC machine. A master woodworker inspects every cut by hand because their hands made the cut. A machine shop does not work that way. Nobody eyeballs each pass of the mill. They set tolerances, then they measure the finished part against those tolerances with gauges. The trust lives in the measurement system, not in watching the spindle turn.
Martin is proposing the same move for software. Stop inspecting the cut. Build the gauges.
Not reading is not the same as not caring
The easy misreading of this is "ship whatever the robot produces and hope." That is the opposite of what he means. His actual practice is to surround the agent with so many constraints that bad code cannot survive the trip.
The constraints he leans on are not exotic. They are the disciplines he has taught for years, now turned into an automated gauntlet:
Acceptance tests, often written in Gherkin, which is a format that describes behavior in near plain language (given a logged out user, when they submit valid credentials, then they land on the dashboard). These pin down what the software should do in terms a stakeholder could read.
Unit tests and high coverage, so the smaller pieces are locked in behavior by behavior.
Mutation testing, which is the sneaky one. A mutation tool deliberately injects small bugs into the code, flips a greater than into a less than, deletes a line, and then reruns your tests. If the tests still pass, your tests are theater. They prove nothing. Mutation testing measures whether your safety net actually catches things, which matters enormously when a machine is writing both the code and, if you let it, the tests.
Quality metrics read from the outside. Instead of judging the code by reading it, he judges it by what it measures out to: test coverage, dependency structure, module size, and cyclomatic complexity, which counts the number of independent paths through a piece of code. A high number means tangled logic that is hard to test and harder to maintain. You do not need to read a function to know a complexity score of forty is a problem.
The point is that every one of these is machine checkable. A human defines the standard once. The machine enforces it on every run, at agent speed, without getting tired around line ninety.
The pipeline, made concrete
Earlier this year Martin went past theory and showed the plumbing. His setup runs a chain of agents, each with a narrow job and each stage more formal than the last: one shapes the requirements into a specification, one writes the code, one refactors it, and one reviews the architecture. Formality goes up and human intervention goes down as work moves along the line.
Picture a factory line rather than a single genius in a room. The raw request enters one end. Each station has a specific responsibility and a specific check it must clear before the part advances. The human is not standing at every station squinting at the work. The human designed the line and reads the dials at the end.
His O'Reilly course, AI Agents for Clean Code, teaches exactly this bundle of acceptance testing, unit testing, mutation testing, and code quality analysis. His Clean Coders series Clean AI: Agentic Discipline walks through the same ideas with agents like Claude Code doing the typing. Same gospel he always preached. New pulpit.
The skill that is now worth money
For most of software history the core competencies were reading code and writing code. That was the job. If Martin is right, the valuable skills are quietly shifting to writing the tests, defining the constraints, and setting the metrics that the code has to satisfy.
There is a nice irony here. Martin has pushed test driven development for decades, often to eye rolls from people who found writing tests tedious. In an agent driven world, a rigorous test suite is arguably worth more than the code itself. The code is now cheap and regenerable. Ask the agent again and you get a fresh batch. The tests are the durable asset, because they are the specification of what "correct" even means. Lose the code and you can rebuild it. Lose the tests and you have lost the only thing that told you the code was any good.
Where this can bite you
It would be dishonest to pretend everyone agrees. A strong camp of engineers argues the exact opposite: never ship code you do not understand, because you remain accountable for it. Their worry is real. Tests only catch what you thought to test. A subtle security flaw, a bad architectural choice, a dependency you did not want, all of these can pass a green suite and still hurt you three weeks later in production. If your gauntlet has a gap, the agent will happily march code straight through it, and you will not have looked.
So the honest framing is not "reading code is obsolete." It is that reading every line by default is a poor use of a scarce human. The constraints have to be genuinely good, and mutation testing exists precisely because most test suites are not as good as their authors believe. The method is only as trustworthy as the weakest gauge in it.
The discipline did not disappear
The headline sounds lazy. Do not read the code. The reality is the opposite of lazy. You are trading the local, per line discipline of careful reading for a systemic discipline that has to be even more rigorous, because it runs without you watching.
Agents do not free you from discipline. They demand a different kind. The craftsmanship just moved up a level, from the code to the constraints that judge it. Which, when you think about it, is a very Uncle Bob place for it to end up.
This piece is part of what I'm building at leestack.dev — a space where I get obsessive about system design, architecture, and engineering strategy. Interactive labs are in the works. Probably worth a tab you won't close.