The agent is faster than your review process. That's the bottleneck now.

Put an agent in the authoring step and code starts showing up faster.

The pull request still waits.

Someone still has to establish what the change was supposed to do, figure out what it touches, decide which evidence matters, and determine whether it's ready to ship.

That's the bottleneck I'm more interested in.

AI can be part of that work too. It can trace dependencies, inspect integrations, run tests, compare a change with the intended outcome, look for security problems, and challenge the reasoning behind a change. A reviewing agent can work with much more than the diff. It can gather evidence from the systems around the change and tell us where that evidence stops.

The problem starts when an organization adds agents to the part of the process that produces change without rebuilding the part that establishes confidence in it.

Code shows up faster. Context still has to be gathered. Risk still has to be assessed. Evidence still has to be produced. Someone or something still has to decide whether that evidence is sufficient to ship.

That whole system is review.

Review is a system, not a person

Review is often treated as a person opening a pull request and reading the code. That's one form of it. It isn't the whole job.

The actual job is to establish enough confidence to accept a change.

What was this supposed to do? What does it touch? Which integrations depend on the behavior? What could break? Is the change reversible? What evidence do we have that it works?

None of those questions inherently requires a person.

An agent can answer many of them. Tests, telemetry, architecture records, API contracts, policies, and previous incidents can supply evidence. Deterministic controls can establish things we don't need an agent to reason about at all.

A person may still be required when the evidence is incomplete, the consequences exceed delegated limits, or the organization has decided that a particular risk requires human authority.

Review is the system that turns a generated change into an accepted one.

If that system can't operate at the speed changes are being produced, that's where the work starts to pile up.

Give the reviewing agent the system, not just the diff

A diff isn't enough context for a person either. We've simply become accustomed to making people hunt for everything else.

A useful reviewing agent needs the intended outcome and constraints. It needs to know what the code depends on, what depends on it, which policies apply, what the system looks like at runtime, and who owns the affected pieces.

Most of that context exists somewhere. Almost none of it is where an agent, or a new engineer, could find it on a Tuesday.

With that context, it can do more than say whether the code looks reasonable. It can explain what the change affects, run checks based on the actual risk, produce evidence for its conclusion, and identify where its understanding stops.

That last part matters.

If an important integration is undocumented, invisible, or outside the agent's access, the assessment will be incomplete. A human reviewer faces the same gap and usually doesn't say so either.

The useful control is to make that uncertainty visible.

What do we know? What evidence supports it? What couldn't we establish? What needs another check before this can proceed?

I'd rather have a system tell me what it doesn't know than quietly turn missing context into confidence.

Separate making the change from proving it

The process that produced the change shouldn't be the only source of evidence that the change is good.

Independent evaluation can come from another agent. It can also come from deterministic tests, policy checks, contracts, runtime evidence, and controls the authoring process doesn't get to grade for itself.

The verifier should start from the intended outcome, constraints, policies, and available evidence. It should be able to disagree with the change, request another test, identify missing context, or stop it from proceeding.

The important separation is between production and verification.

I don't need another agent because two agents are automatically better than one. I need evidence that doesn't amount to the authoring process checking its own work and declaring itself finished.

Decide what the system is allowed to decide

A copy change, a dependency update, and a migration on a core customer table don't have the same consequences.

Sending all three through an identical review path isn't rigor. It's a refusal to make a decision about risk.

Classify changes by what they can affect, how quickly a failure would be detected, and whether the change can be reversed.

A routine change with complete evidence may be approved and deployed automatically. A change with broader impact may require more dependency checks, more tests, or a controlled rollout. A change with serious consequences may still go to a person because the organization has chosen to keep that decision and its accountability human.

For some changes, the rollout itself is part of the evidence. Deploy narrowly, watch what actually happens, and decide what triggers a rollback before the change goes out.

No amount of reasoning about a diff can guarantee what production will do.

Automation needs authority boundaries just like people do. The system should know which decisions it is allowed to make, under what conditions, and where that authority ends.

People shouldn't be the default integration layer for missing context, weak controls, and undefined risk tolerance.

If a person needs to make the decision, make that an intentional boundary.

Measure time to confidence

Generation time is easy to celebrate because it's visible.

I care more about time to confidence: the time from a proposed change to having enough evidence and authority to accept it.

How long did it take to understand the intended change? Assemble the relevant context? Produce the evidence? Resolve uncertainty? Apply policy? Obtain whatever authorization remained?

Then separate the time spent doing those things from the time spent waiting between them.

If a change takes three minutes to generate and two days to become acceptable, making generation twice as fast does almost nothing for speed.

I've measured this on a real team. The agent's part of a change was under ten minutes. The change sat for most of a week, and almost none of that week was anyone doing anything. It was waiting: for someone to work out what it touched, for a test environment, for the one person who knew the integration, for an approval that didn't depend on the size of the change. The agent wasn't the bottleneck. It was the only part of the system anyone had sped up.

The constraint didn't disappear.

It moved.

Once you measure that, you can see what is actually slowing delivery down. Maybe it's test execution. Maybe nobody can determine ownership. Maybe reviewers spend hours reconstructing context that should already be available. Maybe every change waits for the same approval regardless of consequence.

Making the agent faster won't fix any of those things.

Build for the exception

An agentic delivery system shouldn't end with a larger stack of pull requests for people to read.

It should assemble the decision that's ready to make: what the change was meant to do, what it may affect, the evidence that it works, the checks that ran, the risk the system found, what it still doesn't know, and whether policy allows it to proceed.

For routine changes, the system should be able to evaluate that evidence and proceed within the authority it has been given.

For exceptions, a person should receive the decision that needs to be made, not a pile of raw material and an invitation to reconstruct the entire system.

That's where human judgment is useful.

Not as a mandatory checkpoint for every line an agent writes. As authority applied where the consequences warrant it.