The Review Is Automated — the Decision Isn't

I no longer spend my day reading pull requests line by line.

That version of review made sense when code was expensive to produce and manual diff-reading was still the backbone of inspection. In 2026, agents can generate, inspect, compare, and explain code faster than I can move through a diff. Pretending otherwise doesn't make the process rigorous — it makes it slow.

But the opposite reaction — letting everything merge to main because an agent wrote it — is equally unserious.

The old review is dead — but its purpose isn't

Code review still has a job. It catches incorrect assumptions, missing cases, accidental complexity, security problems, and changes that technically work while making the system worse. It also draws an explicit line between "an implementation exists" and "we're willing to own it." The ritual is outdated. The responsibility is not.

A lot of teams are stuck between those two facts: AI is producing more code, but the review process still depends on a human eventually finding forty uninterrupted minutes to inspect it. More output enters the system; the same narrow human gate sits at the end. The predictable result is a bigger queue.

The brutal version: the bottleneck was never the review. It was waiting for the reviewer.

My workflow removes that wait without removing the review. I use agents for what they're good at — breadth, consistency, speed, tireless inspection — and reserve human attention for decisions where judgment actually changes the outcome.

The double-agent review

I have a PR-review skill that takes a pull request number or link. That's the entire interface.

Behind it, the skill runs both Claude and Codex against the PR, locally and internally. Each reviews the same change. Their findings are consolidated into one clean comment and posted on the PR. The author doesn't get two rambling reports and a small archaeology project — they get one review. Under the hood, it's a two-model review.

One clean comment can hide two models arguing.

That disagreement is the point. Different models notice different things — one catches a broken assumption across files, another a subtle edge case or an unnecessary abstraction. This is the direction the field is converging on: multi-agent review is now shipping inside the coding tools themselves, and the broader pattern — several independent passes, then an aggregation step — is being explored in both tools and research. Running two models gives me more surface area than asking one system to critique its own style of reasoning.

The consolidation step matters as much as the two reviews. Raw agent output is cheap; reviewer attention is not. If every model dumps its full response into the PR, AI review just becomes another source of noise — long comments, repeated findings, twenty minor suggestions burying the one that matters. A useful review merges the overlap, separates real problems from weak suspicions, and lands as one coherent comment. The goal isn't to show how much analysis happened. It's to help the engineer decide what to change.

It's also why I don't treat model agreement as proof. Two agents can share blind spots, misread the intent, and confidently reinforce the same bad premise. Multi-model review increases diversity; it doesn't manufacture certainty. The workflow is built to produce a stronger review, not an oracle.

Batch it, then schedule it

Reviewing one PR with two agents is useful. Reviewing every ready PR that way is where the workflow changes. I give the system one prompt:

The same process runs for every matching PR: Claude reviews it, Codex reviews it, the findings are consolidated, one clean comment is posted. PRs I've already reviewed are excluded; drafts stay out of the batch. This turns review from a sequence of interruptions into a fleet operation — the unit of work is no longer "review this diff," it's "bring the review state of the whole estate up to date."

With cloud compute, the same workflow runs on a schedule — hourly is an obvious interval. The industry is already heading here: "autonomous maintenance PRs" — dependency and security PRs opened and merged with no human initiation are already common, and broader agent-initiated maintenance (dead code, coverage) is the emerging direction; the most-deployed of these tools already reports running on over a hundred thousand repositories. The exact frequency matters less than the behavior change: review no longer waits for me to notice that someone is waiting.

That's a bigger win than making an individual review twice as fast. Queue time usually dominates execution time — a ten-minute review that sits untouched for half a day is still a half-day process. Scheduling also changes the social dynamics: engineers don't have to ask whether I've seen their PR, and I don't turn into a notification router. The system keeps checking, and ready work gets reviewed.

The last row matters most. Every workflow becomes dangerous the moment people stop seeing it as a workflow and start treating it as a guarantee.

Different engineers, different lenses

On a team, I don't want one centralized review agent producing the official machine opinion. Each engineer runs their own setup — different agents, models, prompts, priorities. One leans hard on security boundaries; another on maintainability, failure handling, or unnecessary complexity. That variation is a feature.

Traditional review already benefits from different human perspectives — a database engineer and a frontend engineer don't read the same change the same way. Standardizing everyone onto one model with one prompt would erase that diversity exactly when automation lets us increase it. The useful comparison isn't human review versus AI review; it's a narrow review monoculture versus several independent lenses.

Of course, five differently configured agents can produce five versions of nonsense. Variety alone isn't quality. The engineer running the setup stays responsible for what context it gets, what it's told to prioritize, and whether low-value output is allowed to pollute the PR. This is where review becomes an engineering system, not a feature toggle — prompts need maintenance, model behavior drifts, and a good reviewer for an application service may be badly calibrated for infra code or a migration. Evaluate review setups like any other machinery: by the defects they catch, the noise they make, and the decisions they improve.

Where humans still belong: put the human on the spec, not the diff

For critical work — new architecture, important features, changes with consequences beyond a local implementation — I move the human checkpoint upstream. I use spec-driven development, and at that stage the "PR" is a single Markdown file.

That file describes what we're building, why it should exist, how the major pieces fit, the constraints that matter, and the decisions that will be expensive to reverse. I like to pair it with a PDF — SVG diagrams and a roughly five-page TL;DR/ELI5 version. The short companion isn't decorative documentation; it's an attention interface. A reviewer should be able to grasp the proposal fast enough to challenge the big decisions: are we solving the right problem? Is the boundary in the right place? What happens operationally? Which complexity are we choosing to own?

Finding a wrong architectural assumption in a five-page explanation is cheap. Finding it after agents have generated a polished implementation across dozens of files is still possible — but the organization has already built momentum in the wrong direction. So we iterate on the spec, align, and merge it. Only then do I autoship the implementation from the approved spec. Agents handle the implementation and the detailed code review; humans stay where their judgment has the highest return — and for the highest-risk or irreversible changes, a human still reads the implementation too.

Put the human on the spec, not the diff.

This isn't an argument that code stops mattering — it's about where scarce attention belongs. Humans aren't valuable because they can spot a repeated conditional on line 418. They're valuable because they can say "this entire direction is wrong" before line 418 exists. Spec-first development went mainstream in 2026 as a response to "vibe coding" drift — agents are brilliant at writing code and terrible at guessing what you meant — and the major coding tools now ship a flavor of it, from dedicated systems like GitHub Spec Kit and AWS Kiro to the spec workflows in tools like Cursor and Claude Code. The specification becomes the control surface: a stable target for the agents, something coherent for reviewers to approve, and a record of why the system was built this way.

The review is automated; the decision isn't

The industry debate usually frames human involvement as a percentage: should a human review all AI-generated code, some, or none? That framing is too crude. The real question is which decisions require human judgment, and when they should happen.

Agents win at persistent, repeatable inspection — every ready PR, without getting tired or distracted by a meeting in twelve minutes. Humans win where the answer depends on priorities, product judgment, acceptable risk, or taste — things you can't reliably recover from a diff, because they're rarely fully captured in the code. Keeping a human "in the loop" is meaningless if the loop puts them at the least valuable point. A tired engineer clicking approve after skimming 1,800 generated lines is technically oversight. It isn't control.

Real control means giving people a compact, legible decision at the right altitude — and enough time to disagree before implementation becomes a sunk cost. That's why my process has two paths: routine implementation gets fast double-agent review that runs across repos and on a schedule; critical work starts with a human-readable spec, diagrams, and a short explanation built for high-level feedback. The code still gets reviewed. The architecture gets reviewed first.

Where this goes: the autonomous software factory

The direction from here is a fully autonomous software factory — not one giant agent handed "build the product" that vanishes for the afternoon (that's a demo, not a production system), but a factory with stages, state, feedback, quality controls, and escalation points. It knows what's ready, what's already processed, what failed, what needs another pass, and what needs a decision. Different agents do different jobs; their outputs get compared and consolidated; work advances automatically when its conditions are met.

Eventually even the "ask a human here" steps get automated at the right points: the system notices a decision exceeds its authority or confidence, packages the context, presents the trade-off clearly, and routes it to the right person. The human provides judgment; the factory handles the interruption. That's the future I'm building toward — not removing humans from software, but removing humans from the machinery around every decision.

The review can be automated. The queue can disappear. The implementation can autoship from an approved spec. But the decisions that shape the system still need an owner.