Picture a Tuesday. You ask a coding agent for a small feature, the kind you would have pushed to Thursday. Four minutes later there are a few hundred lines across a handful of files, and the tests are green. You feel like you just won back a day.
Then you open the diff. The first file takes a minute. The second is fine. Somewhere around the fifth you notice you're scrolling, not reading, and by the seventh you're hunting for a reason to approve. You merge. On Wednesday you do it again, because it worked.
Here is my claim. Most AI business cases are fiction, because they price the typing and skip the reading. The typing got nearly free. The reading did not, and the reading is the only step that decides whether what you got is true. I'll defend it with other people's disasters, not mine.
The people paid to read, caught not reading
If anyone should be good at this, it's lawyers. Reading before signing is the entire product. Damien Charlotin keeps a database of court decisions where a party relied on hallucinated material, fabricated citations and invented quotes. On 27 October it held 2,225 decisions. Lawyers account for 879 of them. Most of the rest are people representing themselves, who at least have an excuse.
Then there's Deloitte. In 2025 its Australian arm delivered a report to the government on automated welfare penalties, under a contract worth about A$440,000. The report contained a fabricated quote from a federal court judgment and references to academic papers that do not exist. Deloitte refunded over A$97,000 and published a corrected version. A big-four firm, a government client, an expensive report about how automated systems wrongly punish people, and the footnotes went out wrong.
I'm not telling these stories to laugh. They are the Tuesday diff, one level up. Somebody got a fluent, confident, mostly right artifact for almost no effort, and the effort that remained, the checking, was the part that felt optional. It never is. It's the product.
Output is the part you can screenshot
Every AI demo stops at the moment the output appears. Nobody films the person checking it.
Faros AI, which sells engineering analytics, looked at telemetry from more than 10,000 developers across 1,255 teams and compared each team's two heaviest AI-adoption quarters with its two lightest. In the heavy quarters, teams completed 21% more tasks and merged 98% more pull requests. The pull requests were 154% bigger. Review time went up 91%. At company level, Faros found no significant improvement in delivery.
Output nearly doubled and each unit got two and a half times bigger. The reviewer's day did not.
Take it with the usual salt. It's correlation, and Faros sells the dashboards it measures with. A 91% rise in review time could mean harder reading or just a longer queue, and the data can't say which. But the direction matches what anyone who has reviewed a generated diff already feels.
A better story comes from METR. They took sixteen experienced open-source developers and gave them 246 real tasks in repositories they'd worked on for years. Tasks were randomly assigned to allow AI or ban it. Before starting, the developers predicted AI would make them 24% faster. With AI allowed, they took 19% longer. Afterwards, asked how it went, they said AI had made them about 20% faster.
Nobody was lying. Writing code with a model feels like movement. Reading it, fixing it and arguing with it feels like diligence, so the time slips into a category nobody counts as cost. That's my guess at where the hours went, not something METR measured. It's also a small study of early-2025 tools, so I read it as a result about that setting. The gap between the feeling and the clock is the part that travels.
The first file is a conversation. The five-hundredth is archaeology.
A new file in an empty repository gets judged on its own. The same file in a repository with fifty thousand lines gets judged against everything it might touch. The function it quietly duplicates. The convention it breaks. The caller three directories away that now behaves differently.
So review cost per piece depends on how much already exists. Total cost goes with volume times context, and the pairs that can interact grow with the square of the volume. That is superlinear. I'm not calling it exponential, because I can't defend the word, and the quadratic version already wrecks a plan.
I drew this. It's a model, not a measurement, and the shape rests on one assumption: new work gets checked against old work.
Your review capacity, meanwhile, is flat. A person reads at a fixed speed, and the second reviewer you hire arrives with a three-month ramp. The two lines travel together for a while, so nothing looks wrong. Then the curve crosses, the queue starts, and it doesn't clear on its own because the generator doesn't stop for the weekend.
There's a second effect, and again it's my reading rather than a measurement. When a colleague opens a pull request, you can ask why. Generated work comes with a prompt, which isn't a reason. So you rebuild the intent before you can judge the result, and that rebuilding takes hours too.
So you ask a second model to read it
Sooner or later someone in the room says the obvious thing. Let another model do the review.
It's a good idea for about a minute. A model reads as fast as it writes, it doesn't get tired at file five, and it costs cents. Then you ask what the two models have in common. It's the author proofreading its own essay in a different font.
A team at ICML 2025 measured it. On one leaderboard dataset, when two models are both wrong, they agree 60% of the time. Bigger, more accurate models have more correlated errors, even across different architectures and providers. The authors also tested LLM judges and hiring, which is my corner of this.
A reviewer that shares the author's mistake returns a clean verdict. You can't tell that verdict from a real one by reading it.
Now picture the sequel to Tuesday. You hand the diff to a second model. Thirty seconds later it says it looks good, with one suggestion about a variable name. You merge. The bug it missed is the kind the first model would also have written, which is how it got into the diff to begin with.
None of this says model review is useless. It catches the four cases that differ, and plenty of errors the two models don't share. It says model review can't be the only gate. If the same supply writes the work and signs it off, you bought one opinion twice and paid for both calls.
Satya Nadella put the principle in a sentence this month: "we need to separate the supply of intelligence from the authority over it." He was talking about monitoring agents, and Microsoft sells the monitoring, so weigh the source. The logic holds one level down, at the review.
The vendors are moving that way, in an uneven order. Microsoft launched agent monitoring on 19 October. On 27 October IBM announced short-lived credentials for agents, and Salesforce put an agent kill switch and hard spending limits into general availability. Salesforce's Agent Evals, the part that tests whether an agent did the work well, arrive in beta in November and in general availability in January 2027. Stopping an agent and capping its bill came first. Judging its work comes later. That's a reason to plan for the gap now.
What I ask before I say yes to an AI project
Four questions, in this order. Most proposals fail the first one, because nobody wrote the number down.
How many hours of review does this create each week, and whose are they? Put the number next to the compute line. If no calendar has those hours in it, the project has no reviewer, whatever the plan says.
What gets checked by something that isn't a model? Tests, type checks, schema validation, comparisons against a set of answers you trust. They don't tire at file five, and their cost doesn't grow with the size of the pile. Push as much as you can into them and save the human hours for what's left.
Is the reviewer independent of the author? A different family of model, a different method, or a person. The same vendor with a different prompt is the same opinion twice.
What stops the generating? Agree a limit on the review queue before launch. When it's full, generation pauses. A throttle on output is cheaper than a pile nobody can read.
At Shakers, a candidate can challenge an outcome and we have to say what produced it. So I price the review first. A decision nobody could check is a decision nobody can defend.
Closing
The next time someone shows you a demo, ask who reads the output on Thursday, and what that costs. If nobody can answer, you haven't bought automation. You bought a backlog with a good interface.