For most of my career, code review has been a fairly simple idea.
One engineer writes some code, opens a pull request, and another engineer reviews it before it gets merged. The second engineer looks for bugs, questions design decisions, suggests improvements, and ultimately gives the team another level of confidence that the change is safe to ship.
It is such a normal part of software development that we rarely stop to question the assumptions behind it.
One of those assumptions is that another engineer wrote the code.
That assumption is becoming less reliable.
Today, a coding agent can implement an entire feature, run the tests, fix failures, refactor the implementation, and prepare a pull request. The engineer who opens that pull request may have spent most of their time reviewing and directing the agent rather than writing the code themselves.
This makes me wonder whether our traditional code review process still makes sense.
Not because I think code review is obsolete. I think the opposite is true: we need verification more than ever.
But I think we need to change how we think about code review.
What was code review actually for?
Before we decide what should happen to code review, it is worth asking what problem it was solving in the first place.
When one engineer writes a change and another engineer reviews it, we get a second set of eyes. The reviewer might catch a bug the author missed, notice that an abstraction is wrong, identify an edge case, question an architectural decision, or simply ask why something was implemented in a particular way.
There is also a social dimension to code review. It creates shared ownership and knowledge across a team. The code does not belong exclusively to the person who wrote it.
All of that remains valuable.
But not every part of the traditional process is equally valuable when the author is an AI agent.
I have started thinking about coding agents as something like flawed peers.
Imagine that you are a seasoned engineer and you have a very fast colleague who is capable of producing an enormous amount of code. They can work tirelessly, know an impressive amount about software development, and solve many problems very well. At the same time, they are inexperienced in your particular system and can occasionally make mistakes that seem obvious in hindsight.
You would not blindly merge their work.
You would review it.
You would give them clear constraints.
You would run automated checks.
You might ask another specialist to look at particularly important changes.
That sounds quite a lot like the agentic development workflow we are building now.
The engineer opening the PR is already a reviewer
This is where I think our traditional PR rules start to become interesting.
Suppose a team has historically required one human review for every pull request.
The traditional workflow looks something like this:
Engineer A writes the code → Engineer B reviews the code → merge.
Now consider an agentic workflow:
Agent writes the code → Engineer A reviews the code → Engineer A opens the PR → merge.
If Engineer A has genuinely reviewed the implementation, understands the change, and is willing to take ownership of it, what exactly are we gaining from requiring another human to perform a second generic review?
The PR being opened does not magically make the code more trustworthy.
The meaningful event happened before that: an engineer examined the work and decided that they were prepared to own it.
This is why I think we should be careful about treating approval counts as a proxy for quality.
If your previous process required one review, I think there is a reasonable argument that an agent-generated change which has been thoroughly reviewed by the engineer opening the PR may not need another generic human approval.
If your process required two human reviews, then perhaps the agent-generated change gets one human review by the owner and one additional human review after the PR is opened.
The exact policy will depend on the risk of the system and the kind of change being made.
The important part is the principle:
The number of approval buttons pressed is not the same thing as the amount of verification performed.
Trust the engineer, get ownership in return
There is also a cultural issue here.
If an experienced engineer reviews an agent-generated change, opens the PR, and says "I am happy to own this", I think we should take that statement seriously.
We often say that we want engineers to have ownership.
But ownership without trust is difficult to achieve.
If we tell engineers that they are responsible for the code but then require another person to validate every decision they make, we are creating a system where responsibility and authority do not quite match.
I would rather move toward a model where we say:
You reviewed it. You understand it. You own it.
In return, we should expect engineers to take that responsibility seriously.
This does not mean trusting every change equally. A production database migration, authentication change, or financial transaction workflow deserves a different verification strategy from a small UI change.
It means that our process should respond to risk and uncertainty, rather than blindly applying the same number of reviewers to every pull request.
The bigger problem is code volume
There is another problem that I think is even more important.
Coding agents make producing code dramatically cheaper.
That is fantastic.
It also creates a problem.
If generating code becomes cheap enough, the amount of code produced can increase much faster than the amount of human attention available to review it.
We cannot solve that problem simply by adding more reviewers.
If an agent produces ten times more code and our answer is to have humans manually inspect ten times more code, we have simply moved the bottleneck from writing software to verifying software.
Human attention is scarce.
So we need to become much more selective about where we spend it.
Don't review what you can make unrepresentable
This is where architecture becomes a much more important part of code review.
There are many classes of bugs where I would rather not depend on a reviewer noticing the problem.
I would rather design the system so that the incorrect implementation is difficult or impossible to represent.
Consider a database schema.
If the database requires a value to satisfy a particular constraint, we don't need to rely entirely on every application developer remembering to validate that constraint correctly. The database can enforce it.
Or consider a business workflow.
If a process can only move from Pending to Approved or Rejected, we can represent those states explicitly rather than allowing arbitrary strings and hoping that every piece of application code handles them correctly.
Finite state machines are a good example of this approach. The architecture itself describes which transitions are valid and which are not.
The same idea applies to types, contracts, API boundaries, validation, generated code, static analysis, automated tests, and many other forms of explicitness.
The goal is not to make developers more careful.
The goal is to make certain mistakes impossible.
That changes the economics of code review.
Instead of asking a human to inspect every line and think about every possible failure mode, we can move some classes of verification into the system itself.
The reviewer can then spend their limited cognitive capacity on the things that actually require human judgment.
Verification becomes a layered system
This suggests a different model for reviewing agent-generated code.
At the bottom, we have constraints and architecture that prevent entire classes of incorrect implementations.
Above that, we have automated verification: type checking, tests, static analysis, security scanners, contract tests, database constraints, CI checks, and whatever else is appropriate for the system.
Then we have the engineer who reviews the change and takes ownership.
And for changes where we want additional confidence, we can add another layer.
Adversarial agents.
What if the reviewers were agents too?
We don't necessarily have to choose between one human review and three human reviews.
We can introduce specialized agents whose job is not to approve the code, but to try to find reasons why we should not trust it.
Imagine an agent whose only responsibility is security.
It reviews the change and asks questions such as: "Can this input be manipulated? Did we introduce an authorization bypass? Are there new injection opportunities? Did this change expose something that should remain private?"
Another agent might specialize in performance.
It could look for expensive queries, unnecessary allocations, N+1 database access, contention, excessive network calls, or other performance problems.
We could have agents specializing in reliability, backwards compatibility, API design, testing, accessibility, architecture, or whatever concerns are particularly important to a given system.
The important part is that these agents have specialized responsibilities.
I don't want ten generic agents saying "LGTM."
I want adversarial agents trying to break my confidence in the implementation.
The security agent should be trying to find a security problem. The performance agent should be trying to find a performance problem. The architecture agent should be trying to find an architectural violation.
And, just like the coding agent, we should remember that these are flawed peers.
A security agent does not prove that our application is secure. A performance agent does not prove that the system is fast.
They provide another independent attempt to find problems.
That can still be extremely valuable.
More verification without a longer delivery cycle
This gives us an interesting alternative to the traditional approach.
Today, if a change is considered important, we might respond by adding more human reviewers.
That increases the amount of human attention required and can increase the time it takes to get the change through the development process.
In an agentic workflow, we have another option.
We can increase the amount of verification without necessarily increasing the number of humans involved.
For example:
Coding Agent
|
v
Engineer reviews and takes ownership
|
+------> Security Agent
|
+------> Performance Agent
|
+------> Architecture Agent
|
+------> Testing Agent
|
v
Automated verification
|
v
Merge
Not every change needs every agent.
A documentation change probably does not need a performance review. A database migration probably deserves more scrutiny than changing a button label.
The important thing is that verification can become composable.
We can assemble the verification pipeline according to the risk of the change.
Code review at scale
This leads me to a slightly different way of thinking about code review.
The answer to having more generated code is not necessarily to review more code.
It is to make less code require human review.
We can do that in several ways.
We can use architecture and constraints to make certain incorrect implementations unrepresentable.
We can use automation to verify things that machines are better at checking than humans.
We can use specialized adversarial agents to search for specific categories of problems.
And then we can use human engineers for the decisions where human judgment actually matters.
Does this solve the right problem?
Is this the right abstraction?
Does this fit the architecture?
Are the trade-offs appropriate?
Does this behavior make sense for the business?
Is this something we actually want to own and operate?
Those are difficult questions to reduce to a simple automated check.
Checking whether a database column is nullable is not.
Checking whether an API contract is backwards compatible is often automatable.
Checking whether every state transition is valid can be encoded into a state machine.
The more of these things we can move out of human cognition, the more effectively humans can review the things that remain.
The PR isn't dead
I don't think code reviews are going away.
I think the meaning of a code review is changing.
When humans wrote most of the code, the natural workflow was for another human to inspect the author's work.
When agents write most of the code, the engineer's role becomes less about being the person who typed the implementation and more about being the person who understands it, verifies it, and takes responsibility for it.
That doesn't mean we should blindly trust agents.
Quite the opposite.
It means we should build better verification systems around them.
Some verification should happen through architecture. Some through constraints. Some through automation. Some through specialized adversarial agents. And some through experienced engineers exercising judgment.
The goal shouldn't be to remove verification in order to move faster.
The goal should be to increase verification while reducing the amount of expensive human attention required for it.
Maybe the question for the agentic era isn't:
"How many engineers need to review this PR?"
Maybe it is:
"What is the cheapest reliable way to gain confidence in this change?"
Sometimes the answer will still be another human.
Sometimes it will be an agent.
Sometimes it will be a test, a type, a database constraint, or an architectural decision that makes the bug impossible.
And sometimes, if an experienced engineer has already reviewed the work and is willing to own it, perhaps the answer is simply to trust them.
