The Greenfield Privilege
What gets lost when you kill review
The “kill the code review” thinkpieces are coming from two kinds of places: greenfield repos where nobody is teaching anybody anything, and vendors selling the replacement. The team I review for is neither.
Two pieces to put side by side
Ryan Lopopolo, OpenAI: “Extreme Harness Engineering: 1M LOC, 1B toks/day, 0% human code or review.” The talk is good. Codex writes the code, Codex merges the PRs, humans look at code post-merge if at all, treating merge as optimistic rather than gated.
Ankit Jain, CEO of Aviator, in Latent.Space a few weeks earlier: “How to Kill the Code Review.” Cites data from Faros covering 10,000 developers: teams with high AI adoption complete 21% more tasks, merge 98% more PRs, but review time increases 91%. His conclusion: humans cannot outread the machines. Move the review upstream to specs and BDD.
Both pieces are in a lineage OpenAI started earlier with spec-driven development: align on the prompt that produces the diff, verify the system is following the paradigms you set, trust the output.
The math is not in dispute. But Lopopolo said something in his talk that almost nobody quoted:
Full recognition here that all of this activity took place in a completely greenfield repository. There should be no assurance that this applies generally.
That sentence is the piece.
What review was doing
Code review was doing three things at the same time:
Correctness. Does this actually work.
Convention and taste. “We don’t do it that way here.”
Shape, approach, and shared understanding. Is this the right way to solve it? Do you and I agree on what the change is for, and what did we learn by doing it?
The order matters. Correctness is the floor. Convention is learned. The third one is the point.
Greenfield teams at OpenAI automate job 1 with tests and verifiers. They built their way out of job 2: the codebase was written last month, everyone working on it is senior, convention drift hasn’t had time to start. Job 3 mostly happens inside a single engineer’s head, because the only thing reading the code after merge is the next agent, and the next agent was already there when it was written.
Everywhere else, you still have all three jobs, and the question is where they get done.
Where the advice is coming from
A lot of the people writing about how software development should work are doing it alongside some of the best engineers in the world, in fully supported environments, with clear missions and ample resources. That’s a narrow context. It’s not where most teams live.
Most teams have mixed skill, mixed tool adoption, mixed ambition around AI. That’s not a failure mode. It’s what happens when you hire over years, work on an existing codebase, and have actual budget constraints. The review bottleneck shows up where that mix runs into shared code.
Steve Yegge’s “Welcome to Gas Town”, published in January, lays it out in eight stages.
Stage 1: Zero or Near-Zero AI. Maybe code completions, sometimes ask Chat questions.
Stage 2: Coding agent in IDE, permissions turned on. A narrow coding agent in a sidebar asks your permission to run tools.
Stage 3: Agent in IDE, YOLO mode. Trust goes up. You turn off permissions, agent gets wider.
Stage 4: In IDE, wide agent. Your agent gradually grows to fill the screen. Code is just for diffs.
Stage 5: CLI, single agent. YOLO. Diffs scroll by. You may or may not look at them.
Stage 6: CLI, multi-agent, YOLO. You regularly use 3 to 5 parallel instances. You are very fast.
Stage 7: 10+ agents, hand-managed. You are starting to push the limits of hand-management.
Stage 8: Building your own orchestrator. You are on the frontier, automating your workflow.
Yegge’s own bar for Gas Town itself: “If you’re not at least Stage 7, or maybe Stage 6 and very brave, then you will not be able to use Gas Town.”
Now imagine a 12-person team. One person at stage 6. Two at stage 5. Nine at stage 2. Nobody at 3 or 4, because stage 3 and stage 4 are hard places to sit: you have to trust the agent enough to turn off permissions while still driving every keystroke in the IDE. Most people either stay on permissions or jump straight to CLI when they’re ready.
That’s not a skill gradient. That’s a chasm.
The chasm in the shared repo
Two kinds of work are landing in the same codebase. Careful, permission-guarded output from stage 2. Fast, diffs-scroll-by output from stage 5 and 6.
The stage 2 reviewer reads stage 5/6 output without the stage 5/6 instincts. The stage 5/6 reviewer reads stage 2 output and either rubber-stamps or rewrites. Nobody is in the middle to translate. Review is the one place where the chasm actually hits shared code, which is why it feels like the bottleneck: it’s the last human choke point.
And the chasm isn’t only tool adoption. The way people work on either side looks different: how they talk with an agent, how they test progress, what they stop to think about. Some of that is skill. A lot of it, maybe, is a reflection of what they’re actually allowed to do at work. What they have authority to decide autonomously. What needs clarification before they ship. Stage 2 isn’t only about permissions inside the IDE; it’s often a reflection of the permission envelope they have at their job.
The kill-review consensus assumes the distribution is flat. Yegge’s stage 6-8 everywhere. Most places, it’s bimodal.
What I tried
AI review has been running alongside us the whole time. It catches some of this: types align, tests pass, style holds, the obvious errors. Back then it wouldn’t tell you whether the thing should have been built the way it was built, or at all. Claude is pushier on that now, it’ll actually argue with you about approach, which helps. What it still doesn’t close is the last piece, whether you and I agree on what we’re actually trying to do. That doesn’t fit in a PR comment.
We used to ship eight to ten PRs a week between us. With agents in the mix, eight to ten a day.
Attempt one: read faster. Batch reviews in the morning and after lunch, get through them before standup the next day. What actually happened was PRs sitting for days. Branches went stale as main moved on, merge conflicts mounted, the engineer who wrote it had moved to something else and had to context-switch back, reload the problem, re-enter the state they were in when they shipped. Every day a review sits is a tax on the next day’s work. “Read faster” is not a strategy.
Attempt two: skim, trust the tests. The tests are the spec, right? If they pass, it’s fine. What gets through is the class of things tests don’t check: an error-handling pattern that worked locally but wasn’t how we’d done it elsewhere, a half-committed abstraction, an import path that resolves but points the wrong direction. The next agent-generated PR reads the repo and does what the repo does. The pattern propagates.
Attempt three: write it down. CLAUDE.md grew to cover the patterns I kept commenting on. Naming conventions, testing conventions, error handling, where to put what. Engineers didn’t read it. They asked the agent, and the agent read it selectively depending on how the task was framed. The longer the file got, the less reliably any single rule survived into output. A rule without enforcement is a suggestion.
What started working
A short call with the engineer. Every day, sometimes more than once. Not a line-by-line review. A conversation about shape.
Is this the right way to solve it? What’s the overall design? What safeguards did you put in and why? What did the agent miss that you caught, and what did you miss that we’d want to catch next time?
Because the bots handle the technical-correctness layer, I can use the call for what they can’t reach:
Something can be technically correct and the wrong idea completely.
That’s the line. The /review bot can tell me the types line up. It cannot tell me whether the engineer and I agree on what the change is for. That’s the call.
And the call is where mentorship still lives. The stage 2 engineer learns what the stage 6 person is actually looking at. The stage 6 person sees what a stage 2 engineer finds confusing about an agent-generated diff.
The redistribution
Correctness.
/reviewplugins, tests, typecheckers, deterministic verifiers.Convention and taste. The harness: linters, skills, pre-commit hooks, CLAUDE.md rules.
Shape, approach, and shared understanding. A call with the engineer.
The first two are what the kill-review consensus is talking about, and on those it’s right. The third is where the consensus has nothing to say, because on a greenfield team of seniors it’s already handled by the team’s shape.
Everywhere else, it’s the entire point.
Harness integrity
The whole argument rests on the harness actually being able to absorb the first two columns. Which means the rules it enforces have to be the ones the team actually agreed on, and breaking them has to cost more than following them.
The example that carries the most weight for the smallest effort is test integrity.
The goal isn’t “never touch a test.” Tests should change when the thing they describe changes. The rule is about distinguishing two cases:
The behavior you’re asserting has actually changed. The test needs to catch up. Change it, explain why in the commit message.
The code drifted and the test is telling you. Fix the code.
The harness doesn’t make that call. It makes the call visible. Something like this in CLAUDE.md:
Tests describe what the system should and shouldn’t do. If a test fails, the first question is whether the behavior we wanted actually changed. If yes, update the test and say so in the commit message. If no, fix the code. Never delete a failing test to make CI pass.
Then a pre-commit hook that flags any *.test.* change alongside a source change. The hook isn’t the gate; it’s a signal for the reviewer to verify the justification. This catches the most common failure: someone editing the test to match broken output because they don’t have the instinct that the test was the thing telling them they broke something.
Tests written at the behavioral level, describing what the system does rather than how, change less often. That’s a design choice upstream of the harness, and it’s what makes this rule realistic to hold.
The harness raises the floor. The call is about the ceiling.
There’s always a bottleneck
This doesn’t eliminate a bottleneck. It moves one.
If review moves to the harness and the call, what shows up next is the gap between engineering speed and business validation speed. Product, design, compliance, customer feedback: those cycles haven’t sped up the way coding has. The engineering bottleneck is the wrong one to be stuck on right now.
And the call still earns its keep after the redistribution. It buffers against scope explosion and project sprawl. It keeps the engineering team coherent with itself. It’s where junior engineers watch what senior engineers actually look at, which is the part of training that doesn’t fit into a CLAUDE.md file.
The greenfield privilege
The kill-review people are not wrong about the numbers. They are quiet about the shape of the team that produced them. Twelve people reading each other’s agent-generated code across a three-stage skill chasm is not the same problem as a greenfield repo where everyone is stage 6 and the entire codebase was written last month.
The piece of review you can kill is the piece the harness can carry. Convention, correctness. Automate the hell out of it. The piece of review you should keep is the one that was always the point: a conversation with the engineer about whether we are building the right thing and whether we both understand what we just did.
Something can be technically correct and the wrong idea completely. The call is about the idea. Everything else, push into the harness.