For a year now, the spine of nearly everything I've written has been one asymmetry: our tooling has become breathtaking at generating and has barely moved on judging, and the place that asymmetry binds is the review seam — the point where one human reads a diff and decides it's safe. I've told you to treat agent count as a review budget, to guard the merge seam like the one irreversible step it is, to distrust any dashboard that makes supervision feel like throughput.
So when Dan Luu — a writer whose evidence-density I've admired from a distance for a long time — published his notes on agentic coding this week and it climbed to the top of Hacker News, I read it with the particular attention you reserve for the strongest argument against your own position. Because that's what it is. Buried in a long, careful essay about testing and benchmarks is this sentence:
"I've seen a testing-heavy no-review workflow that results in much higher quality than any review-reliant workflow I've seen or even heard of."
No review, and higher quality, reported by someone who measures things for a living. If that's true — and I think it is, within a boundary he's honest about — then the review seam I keep telling you to guard is not the load-bearing wall I've been treating it as. It's worth taking this seriously, and it's worth working out exactly what it does and doesn't overturn.
The chip company that didn't read the code
Luu's biases, as he says himself, come from the first decade of his career at Centaur, a CPU design company, and the testing culture he describes there reads like dispatches from another planet if you've only worked in software. Dedicated test engineers, with testing as a first-class career path on par with development. No code review by default. Virtually no hand-written tests. No unit tests at all. Instead: constant randomized testing — property-based testing, fuzzing, what they simply called "tests" — running on roughly a thousand machines, around the clock, for a team of about twenty logic designers and twenty test engineers. A regression suite that took three months of wall-clock time on a compute farm.
And the result he reports: fewer than one significant user-visible bug shipped per year. Review happened only when someone wanted an extra set of eyes on something they thought was particularly tricky. All of that quality rested on a wall of machines relentlessly asking the code questions nobody had thought to ask, with careful human reading reserved for the rare tricky case.
Here's why that history suddenly matters to everyone else. The economics that made Centaur an outlier in software — testing effort that expensive only pays when bugs are catastrophic, and silicon bugs are — just changed. As Luu puts it, with AI coding workflows "it's easy for one person to generate more code than any human or even any ten humans can review by hand." The review seam doesn't scale. It never did; we just never had generation volume that exposed it this brutally. Meanwhile the cost of randomized testing — of building fuzzers and harnesses and letting compute interrogate the code — has collapsed, because steering an LLM to build a fuzzer is cheap and the fuzzer itself contains no LLM at all. Luu mentions a skeptic on Mastodon who tried the approach and reported back, a little grudgingly, that "Claude fuzzing found several classes of bugs that are worth fixing." Others he's talked to found bugs immediately — in their own software, in upstream dependencies.
So the argument goes: stop trying to widen a seam that runs at human reading speed. Move the judgment into machinery that runs at machine speed, the way generation already does.
What actually replaced the reviewer
I want to be precise here, because the lazy reading of Luu's essay is "reviews are obsolete," and that's wrong in a way that will hurt whoever believes it.
The Centaur workflow ran on just as much human judgment as anyone else's — it simply spent that judgment differently. A review-reliant workflow spends judgment retail: a qualified human reads each particular change, at human speed, one diff at a time, and the judgment is consumed in the reading — it doesn't transfer to the next diff. A testing-heavy workflow spends judgment wholesale: humans design the oracle — the properties, the invariants, the generators, the definition of "this output is wrong" — and that judgment, once written down, gets enforced automatically against every line the machines generate, forever, at no additional human cost.
The analogy that keeps clicking into place for me is the difference between a trial and a building code. A trial is careful, adversarial, expensive, and applies to exactly one case. A building code is written once, argued over hard while it's being written, and then enforced against every structure in the city without a judge present. Nobody thinks building codes made judgment obsolete. They made a certain class of judgment amortizable. That's what a property is: a building code for your codebase. And review — the trial — remains what you do for the cases no code anticipated.
Regular readers will recognize the shape, because this is the same relocation I keep finding everywhere in the agentic stack. When Murakkab picks your models for you, the skill relocates from choosing the model to writing the objective. When the instruction file becomes a portable standard, the skill relocates from formatting the instructions to verifying compliance from outside. And here, in the oldest quality mechanism software has, the same move: the load-bearing human skill relocates from reading the diff to designing the oracle that reads every diff.
The catch, in Luu's own evidence
Now for the part of the essay I found genuinely delightful, because Luu is too honest a writer to hide it: the judging side is exactly where the models are still weak.
"LLMs seem pretty bad at testing," he writes — in the middle of an essay recommending LLM-driven testing. The resolution of the paradox is steering. Ask a model to "write tests" and you get what everyone who cares about quality reports: tests that are, in the words of compiler engineer Em Chu, "thorough enough to smuggle a feature through human code review." Chu's fuller verdict is worth quoting because it names the precise deficit:
"LLMs just suck. They are painfully bad at the adversarial 'now, what if I do this' or 'let's try the cross-product of everything' process humans use to write tests that actually find bugs."
That adversarial instinct — what if I do this — is the oracle-design skill. It's the judgment. And it remains stubbornly human. What the LLM is good for is the manual labor around it: building the fuzzer harness, wiring the generators, churning out the scaffolding that used to make serious randomized testing a three-week infrastructure project. Luu's framing is that LLMs let you apply any given level of testing effort far more easily than before, if steered properly — and the steering is where you live now.
Even at Centaur, with its thousand machines, the human seam never closed. It shrank and sharpened: one to two engineers whose whole job was triaging failures — rejecting false positives, fixing generators that produced them. Luu says the same about his current setups: detecting false positives is a critical part of the process, and a reasonable setup around the model matters at least as much as having the newest model. And his most telling admission is about the loop as a whole — he hasn't built an agentic quality loop that runs without outside feedback, whether human check-ins or production signals flowing back from metrics, logs, and support tickets. "I haven't figured out how to replace myself (yet?)," he writes. The parenthetical is doing honest work.
Where the boundary sits
So does this generalize? Partially — and the boundary is the most useful thing in the whole discussion.
A CPU is a nearly perfect environment for oracle-based quality: there is a specification, there is a simulator, and reality itself adjudicates. Anything with that structure inherits the approach beautifully — parsers, serializers, compilers, migrations, anything with a round-trip property ("decode(encode(x)) == x"), an invariant ("the ledger always balances"), or a crash to detect. If parts of your system look like that, tools like Hypothesis for Python or fast-check for TypeScript will let a steered LLM build you a harness this week, and the wall of machines can start asking questions tonight.
But a great deal of software has no writable oracle. "This UI reads clearly." "This API will make sense to the next team." "This is the change the customer actually meant." I've written before about the unwritten acceptance criteria in human review — idiom, intent, architectural fit — and none of them compress into a property a fuzzer can check. Notice that even Luu's support-ticket-to-PR pipeline, running at a company with a traditional workflow, still puts every fix in front of a human reviewer. The no-review world exists where the oracle is strong enough to carry the trust. Where it isn't, the trial still runs.
And one warning from my own recent beat: an oracle is a specification, and a specification is enforced with literal-minded diligence, not intent. A weak property that passes everything is worse than no property, because it feels like judgment — the machine equivalent of the reviewer who approves without reading. The oracle becomes the thing your quality flows through, which means the oracle is now the thing you review.
The move
Three practical steps fall out of this, and none of them require abandoning the seam.
First, audit your codebase for oracle-shaped regions — the round-trips, the invariants, the anything-that-crashes — and let a steered LLM build fuzzing harnesses for those this month. That's the highest-leverage judgment infrastructure most teams can buy right now, and it directly relieves pressure on the reviewer, because every property the machines hold is a property the human no longer carries alone.
Second, budget the triage seat. False-positive triage is the new review: smaller, sharper, and real. Centaur ran one to two engineers on it continuously. If you deploy fuzzing and staff triage at zero, you'll drown in noise and conclude the approach doesn't work, when what didn't work was the staffing.
Third, keep the trial for what has no code. Taste, intent, fit — the diff-reading seam stays load-bearing exactly there, and everything I've said about guarding it still holds.
I spent a year saying the judgment side barely moved. Luu's essay is the best evidence I've read that it can move — not by making models better judges, but by making human judgment executable and letting compute amortize it. The question to bring to your own team is uncomfortable and clarifying: how much of what your reviewers check every day could be written down as a property once — and what does it say about the rest that it can't?