Agents are confidently wrong, and reviewing every line of code is impossible. Audit at scheduled gates, then let agents fix what they find early.
Let me start by agreeing with the critics, because they're right.
Addy Osmani is right that comprehension debt is real. Dex Horthy is right that models have no training signal for maintainability; his software factory ran four months with no human reading the code, and it failed quiet and late. And the Faros AI data from 22,000 developers across 4,000 teams is real: incidents per PR up 242.7%, monthly incidents up 57.9%, bugs per developer up 54%, and 31% more PRs merging with no review at all.
So stipulate it up front: agents are confidently wrong, and they do not know it. We are not waiting for a model that raises its hand at the right moment. And one scope line, because everything depends on it: this model is for greenfield systems with no production users yet. Net-new code, nobody depending on it. Brownfield is a different article.
The industry's conclusion: review everything, turn the lights back on. The same data shows the trend running the other way. Where AI adoption is high, 31% more PRs merge with no review at all. Our read: generation has outrun human reading speed, and review capacity is falling behind. Pretending otherwise just means the unread share gets picked by deadline pressure and reviewer fatigue instead of by judgment. The real question is where the review you can actually afford should go.
Our answer: you can't read all the code, but you can audit the architecture the agents are building. And on greenfield, code quality was never the biggest risk anyway. Building the wrong thing is, and every hour reviewing diffs is an hour not spent finding that out.
We don't run a dark factory because we trust the agents. We run one because we stopped needing to catch their mistakes in real time.
Continuous review is a prevention strategy, and prevention was optimal for one reason: rework was expensive. Catching a mistake three weeks late used to cost three weeks of human rebuild. Every QA regime of the last forty years sits downstream of that fact.
Let me be precise about what agents changed, because it isn't the curve. Fixing early is still cheaper than fixing late no matter who executes the fix. Our gates exist because of it. What changed is the penalty for the interval: a structural mistake caught fifteen tasks in now costs a gate finding and a queue of refactoring tasks the factory executes before the next phase. So the question is no longer whether to catch mistakes early. It's how early is early enough. Every diff, or every ten to twenty tasks?
Horthy is the smartest version of the opposing case. His prescription keeps humans reviewing 100 to 200 line slices, which was correct arithmetic when every hour of review protected weeks of human rework. And his subtitle, "harness engineering is not enough," is right. That's why our model puts a human at the gate. The disagreement was never whether humans are needed. It's that continuous attention stopped being feasible once agents wrote most of the code, while periodic attention is more than feasible. It's the responsible allocation: the review actually happens, it lands on the decisions that matter, and the software still comes out useful.
The scope line is what makes the interval safe. With no users, a fifteen-task-old mistake is still early in every sense that matters: no production data to migrate, no consumer to break, no contract in the wild. When real users arrive, this calculus expires. Until then is the window where a startup builds almost everything.
Who checks the repairs? A gate-prescribed refactor comes with a human-written spec, so the senior reviews one bounded diff against a target they wrote, with green tests as the invariant. One caveat. The tests are agent-written too, so green alone is not proof. Green plus a senior reading the diff against their own spec is the check. The model's softest joint lives here.
Review everything was never a principle. It was a price. The price of the interval changed.
We run two cadences. Every ten to twenty completed tasks, a light architectural review inside the phase: catch drift while it's a handful of call sites instead of a hundred. At phase boundaries (end of discovery, core architecture, each major feature), the factory stops for a senior architectural audit. Not a code review. Three questions. What structural debt compounds next phase? Where have modules drifted? What refactoring is cheap now and expensive later?
The cadence is front-loaded. Foundation mistakes compound fastest, and a bad week-one call can have a hundred call sites by the first boundary. As the architecture stabilizes, the interval stretches.
Where does ten to twenty come from? Task size. Large tasks shrink the interval, tiny ones stretch it. Ours are medium, a day or two of human-engineer work each, so ten to twenty is a few engineer-weeks of foundation between looks. That's about as much fresh work as a senior can look over in one sitting. Wait longer and the light review stops being light. The outer bound is already on the record: it's how Horthy's factory died.
What does the reviewer actually read? The ledger is agent-authored, and a confidently wrong agent writes a confident ledger entry. So the ledger is the index, not the testimony. The reviewer uses it to know where to look, then reads the real artifacts: the dependency graph, the module boundaries, sampled diffs behind consequential decisions. Yes, a human reads code structure at phase boundaries. That is the model. Human attention goes to gates and structure, where it has leverage.
That's also where we part ways with Osmani. Comprehension debt is real, but comprehension of every line was never the asset. Comprehension of the structure is, and the gate rebuilds it on schedule.
A gate's output is bounded: refactoring tasks that enter the next queue before new features. The factory fixes its drift before building on it.
The gate costs something too, and I'd rather bound that honestly than wave it away. Senior attention doesn't scale with factory throughput, so phases are sized to what one senior can audit in a sitting. It's why this model favors small teams and tightly scoped projects.
The phase-gate doesn't assume the factory didn't make mistakes. It assumes it did, and that the cheapest time to find out is now, while the fix is still one phase deep.
This model concentrates engineering judgment instead of spreading it thin. Continuous review dilutes a senior across hundreds of PRs that need no judgment at all. Phase-gates ride on a handful of architectural calls, and quality depends on who makes them.
I'll say the unfashionable part directly: seniors beat juniors at this, and it isn't close. Spotting drift from a dependency graph, knowing which refactor is load-bearing, smelling the boundary that will hurt at scale. That's pattern recognition earned over years of watching architectures fail slowly. A junior reviewing every PR catches typos. A senior reviewing the phase catches the mistake that costs the quarter. Design got cheap, and taste got expensive, and the gate is where taste gets maximum leverage.
The next gate-keeper trains there too. We pair a junior with the senior at these reviews, and the junior's job is to watch the decisions: why this boundary and not that one, what the senior examined, what they ignored. An afternoon at a gate doesn't compress the years pattern recognition takes, but it's the one place judgment is visible while it's being exercised. A senior-only team is a time bomb, and the gate is where you defuse it
The factory didn't eliminate the senior engineer. It fired everything the senior was doing except judgment.
Three pieces of plumbing make the gate cheap enough to hold.
Escalation. When an agent recognizes a genuine decision boundary, it asks instead of guessing. That only catches known unknowns, though. The confidently wrong agent never escalates, and that's what the gate is for.
The ledger. Every decision, commit, and agent action recorded in order, each entry linked to the diffs it describes, which is what makes a phase auditable in an afternoon. The standup is dead; long live the ledger.
The harness. Tests, smoke tests, scanners, sandboxing. I've written about how we build it. It catches what an architecture review never will: the security hole, the locally wrong logic that's structurally fine.
The harness catches what's wrong with the code. The gate catches what's wrong with the codebase.
The industry read the Faros numbers and concluded autonomy fails. We read them and concluded unaudited autonomy fails: no gates, no grounded ledger, no scheduled detection. That's an inference, and we're accountable to it.
One concession, because in our experience it's true: gated-factory software may not match hand-coded or fully human-reviewed software. It doesn't have to. It's good enough to be useful and make money. We know because factory-built products of ours have graduated: launched into production, taken real users, held up under load. Several clients run their businesses on code we built this way, and they're happy with it. That's the handoff working. The bottleneck moved from building well to knowing what's worth building, and the factory's job is to get you through that question fast, with architecture sound enough to build on when the answer is yes.
Useful and earning is a bar, not an excuse. Revenue doesn't rule out the quiet rot that killed Horthy's factory, so the bet gets checked at the structure, not the P&L. What would falsify us: a factory run this way whose graduates still rot after launch. The status so far: every boundary audit has queued real refactors ahead of new features, the kind that would have been expensive a phase later, and the graduates are still holding. We're not going to dress that up in numbers that would be stale in a month. We'll keep running the bet, and if it breaks, we'll write that article too.
The teams that win won't be the ones who turned the lights back on. They'll be the ones who learned the difference between watching a factory and auditing one.