Every team that bought coding agents this year got the same result: the generation side of the shop sped up ten times and the shipping rate barely moved. The constraint moved to the one seat nobody re-engineered, and it is the seat with a person in it.
The generation side won. Nobody told the review side.
Start with the concession, because it is true and it is the whole reason this matters.
Coding agents work. The team at detail.dev put it as plainly as anyone this week: agents can
oneshot games that are actually fun, and with the right guardrails they execute migrations and
language rewrites in complex codebases that would have been a quarter's work two years ago. Theo
Browne spent an entire video this week arguing that if you cannot tell the difference between this
year's frontier models and last year's, the problem is your prompting, and he is mostly right. The
ceiling on what a single engineer can emit in a day has gone up by an amount that is genuinely hard
to describe to someone who has not sat in front of it.
And yet the same detail.dev post opens with the sentence every engineering manager has been
avoiding saying out loud: a lot of orgs spent the first half of this year offloading as much work as
possible to armies of agents, and the results have been disappointing. Mountains of dubious code, no
tsunami of incredible software. They call it the trough of disillusionment. We would call it
something more boring. The factory got a faster machine at one station and nothing else changed.
Where the work actually went
Here is the shape of a change to production software in 2024, roughly, in the units that matter:
minutes of a human's attention.
Somebody spends four hours writing it. Somebody else spends twenty minutes reviewing it. A machine
spends six minutes testing it. Somebody spends five minutes deploying it. The human write step
dominates, so every tool of the last fifteen years attacked the write step: better editors, better
languages, better frameworks, and now agents.
Now the write step takes twelve minutes. Not four hours. The agent drafts, the engineer steers, and a
change that used to be an afternoon is a coffee. Which means the engineer produces, on a good day,
somewhere between five and fifteen times as many changes as before. Every one of them still needs
twenty minutes of somebody else's attention before it ships.
The write step shrank by an order of magnitude; the review step did not move. Minutes are illustrative for a mid-sized change; the ratio is what every team we have talked to describes.
Do the arithmetic once and it stops being a vibe. If the review capacity of a six-person team is
fixed at, say, forty reviews a day, then the team ships forty changes a day whether the engineers
produce forty or four hundred. The other three hundred and sixty sit in a queue. Engineers notice the
queue, so they stop producing, or they start rubber-stamping each other, or they merge their own
work at six in the evening when nobody is looking. Every one of those behaviours shows up in the
incident log within a month.
This is why the productivity numbers are so confusing. The individual is faster. The system is
producing the same amount of finished software as before, with worse review. Both things are true.
The seat nobody re-engineered
Look at what the tools industry did in response. It built more agents. Agents to write the tests,
agents to review the pull request, agents to fix the review comments, agents to review the fix.
Some of it is good. Fireship's sponsor this week, Macroscope, says its review tool now auto-approves
forty percent of pull requests across its customers, which is a vendor claim from a sponsor segment
and we would treat it as exactly that, but it tells you where the market thinks the money is. The
market thinks the answer to a review bottleneck is to remove the reviewer.
We think that is the wrong objective function, for the same reason it was wrong in the back office.
The human in the review seat is the accountability. When the change breaks production, somebody
approved it, and that somebody has a name and a manager and a memory of what they were told. An
auto-approval does not have a memory. It has a log line. You can automate the reading of a diff;
you cannot automate the standing-behind of one.
So the question is the one detail.dev asks at the end of their piece and then does not quite answer:
when the software mostly drives itself, what do the engineers do? Our answer is not glamorous. They
review. And the entire engineering problem of the next two years is making that review seat fast
enough to keep up with the machines feeding it, without turning it into a stamp.
What a fast review seat looks like
We have written before about the eight-second decision, and the number is not rhetorical. It is
roughly the time a competent reviewer needs to accept or reject a change when everything they need
to know is in front of them and nothing they do not need is. Almost no review tool is built for that
number. They are built for the twenty-minute review, which was designed for human-written code where
the intent had to be reverse-engineered from the diff.
Agent-written code has a property human-written code never had: the intent already exists in
writing, because somebody typed it into a prompt. The specification, the plan, the reason for every
choice, the tests it ran, the things it decided not to do. All of that is sitting in a transcript
that the review tool throws away. The review seat is slow because it is being asked to rediscover
information the system already had.
What the reviewer needs in front of them for an eight-second decision, and where each piece already exists today (nowhere in the pull request).
Five things. The request, the plan, the verification, the blast radius, and the list of things the
agent decided it was not sure about. That last one is the one nobody surfaces and the one that
makes the decision fast, because a reviewer who can see "the agent was unsure about the retry logic
and left it as before" knows exactly where to spend their eight seconds.
The harness study that hit Hacker News this week is interesting in this light. Nine researchers ran
176 matched configurations across four models on SWE-Bench Verified and Terminal-Bench, varying
planning, action space and context management. One of their findings is that for stronger models,
explicit planning stopped improving accuracy and became mainly a cost saver. Read as a review
problem rather than a benchmark problem, that says the plan is cheap to produce and does not hurt
the agent. Which means there is no excuse for it not being attached to the pull request, because it
is the single most useful artefact a reviewer could have and the model will write it for nothing.
What to do on Monday
Measure the queue. Not the cycle time, which averages away the problem, but the number of changes
waiting for a human and how long the oldest one has waited. If that number is growing week over week,
you have the disease and no amount of model upgrades will treat it.
Then re-engineer the seat rather than removing it. Attach the prompt and the plan to the pull
request, automatically, as the description. Make the agent state what it verified and how, in a
fixed format, at the bottom. Make it list what it was unsure about. Route by blast radius: a change
that touches one file and no data can go to a fast lane with a fast reviewer; a change that touches
billing goes to a slow lane with a senior one. Give reviewers a budget of decisions per day rather
than a queue of infinite length, and watch what happens to the quality of the decisions.
One more thing worth stealing from manufacturing, since the factory metaphor is doing so much work
here. A line with a bottleneck station is run at the pace of the bottleneck, on purpose, and the
upstream stations are told to stop rather than pile up inventory. Software teams do the opposite:
they celebrate the pile. A hundred open pull requests is not throughput. It is inventory, and
inventory decays, because the codebase underneath it keeps moving and every day a change waits is a
day closer to a merge conflict and a re-review. Cap the queue. Let the agents idle. It feels wrong
for about a week.
And resist the auto-approve until you have done all of that. Not because the tools are bad but
because auto-approving forty percent of changes into a system with no fast human lane for the other
sixty is how you get a queue of the hardest sixty percent with the least context, reviewed by the
most tired people. The machines will keep getting faster on a schedule you do not control. The seat
is the only part of the pipeline you actually own.
The engineers were never the slow part. The place where a person has to say yes is the slow part,
and it was always going to be, and the job now is to make yes cheap without making it meaningless.
Sources
- Towards Self-Driving Codebases (detail.dev) (HN, 119 points, 17 Sep 2026)
- Please stop using stupid models (t3.gg, video) (18 Sep 2026)
- Anthropic researchers are quitting... and now we know why (Fireship, video) (15 Sep 2026; the Macroscope figure is from the sponsor segment, so a vendor claim)
- An Empirical Study of Harness Design for Coding Agents (arXiv 2609.20804) (HN, 217 points, 18 Sep 2026)
- Levelbrook: the eight-second review (earlier playbook piece)
Originally published on the Levelbrook playbook. Levelbrook is a principal-led Rails and AI-systems consultancy; the playbook is where we write down what we see.
