What Comes After the Pull Request?

We’ve spent plenty of time figuring out how to fit agents into the existing software development lifecycle. But the pull request was designed for humans to coordinate with other humans. If agents can generate, review, and validate changes continuously as they work, why do we need a separate interaction point at all?

I’m not convinced the pull request has a particularly long lifespan in its current form.

We’ve Asked the Pull Request to Do Too Much

At its core, the PR serves two purposes: knowledge sharing and change management. It helps a team understand how the codebase is evolving and provides a checkpoint before changes become part of the system.

Over time, we’ve attached more responsibilities to that checkpoint. We use it to enforce standards, satisfy compliance requirements, catch security issues, teach teammates, and decide whether code is safe to ship. One mechanism has become the place where we solve several different problems.

That made sense when humans were writing code and relying on other humans to evaluate it. But agents can now generate changes, evaluate their own work, and iterate on feedback continuously. Review shouldn’t be a separate step that happens after the work is done. It should be part of the same development loop, with validation and feedback happening as the code takes shape.

Knowledge sharing, compliance, quality assurance, and change management are all important. Why do they need to happen in the same interaction?

Review Was Always a Proxy for Confidence

When we ask an engineer to review a PR, we’re really asking whether they trust the change enough to ship it. Having another person read the code has been a useful way to answer that question, but it was never a consistent one.

Give the same PR to the same engineer on two different days and you might get different feedback depending on their attention, context, or familiarity with the system. Human review can surface a critical architectural concern. It can also amount to a quick approval from someone who doesn’t fully understand the change.

We already have other ways to establish confidence. Tests verify expected behavior. Static analysis and security scanning catch known classes of problems. Automated review can flag suspicious patterns and potential conceptual errors.

But there’s another complication when agents write both the code and its tests. A passing test suite doesn’t necessarily mean much if the tests themselves aren’t meaningful. At CircleCI, we’ve been experimenting with mutation testing, deliberately introducing faults into code to see whether existing tests catch them. It’s one way to evaluate the quality of our validation rather than simply trusting a green checkmark.

We can also draw on previous incidents, architectural decisions, and team conversations to evaluate whether an implementation fits what the organization intended. Progressive delivery, observability, and rollback mechanisms provide further evidence about how changes behave in production.

None of these signals is perfect, and none makes human judgment irrelevant. But together they suggest that confidence could be established throughout delivery rather than concentrated in a single approval step.

What Would We Build Instead?

If we designed software delivery from scratch today, would we create one interaction responsible for knowledge sharing, quality assurance, compliance, and change management? I’m not convinced we would.

Knowledge sharing might come from automatically maintained records of decisions and changes. Compliance could rely on enforced policies and auditable evidence. Validation could run continuously as agents work, rather than waiting for a PR to be opened. And risk could determine when a human needs to step in.

We’ve also been looking at ways to capture the feedback our most experienced reviewers consistently give and make it available earlier in development. If a staff engineer is making the same comment on every PR, why wait until review to apply that knowledge? We can incorporate it into the agent’s workflow so those issues are addressed before the change is even pushed.

Imagine an agent makes a substantial change. Instead of handing an engineer a diff and asking them to find the problems, the system explains what the agent intended, which checks passed, what remains uncertain, and where the risk is concentrated.

Maybe 1,950 lines of a 2,000-line change follow established patterns, but the remaining 50 introduce a meaningful architectural decision or a change to critical business logic. Rather than expecting someone to read the entire diff with equal attention, we could direct them to the part that actually warrants scrutiny.

The goal is to move human judgment to a higher level, and eventually eliminate the need for human intervention in decisions the system can reliably make on its own. We’re not there yet, but every time a human needs to step in, we have an opportunity to understand what the system was missing and make that intervention less necessary next time.

When someone catches an issue the system missed, was the missing ingredient historical context, an undocumented constraint, or a gap in validation? That knowledge should become part of the system, rather than something we rely on the same person to catch again. Over time, humans can spend less time evaluating individual changes and more time defining the intent, constraints, and architecture that guide the work.

Does the Pull Request Still Have a Place?

I don’t think PRs disappear tomorrow. Different teams have different risk tolerances and obligations. A financial institution may need explicit approvals that a low-risk consumer application doesn’t. Teams also need a durable record of what changed, why, and how it was validated.

But a record of a change doesn’t require a workflow built around human review.

Maybe the PR becomes a lightweight artifact documenting intent and evidence. Maybe it’s an exception path for changes that require human judgment.

I don’t know which model wins. What I do know is that we have an opportunity to revisit assumptions that were reasonable when humans were the primary authors and reviewers of code.

The goal isn’t to make humans read AI-generated code faster. It’s to build a delivery process that can understand intent, assess risk, and establish confidence continuously, without requiring a human checkpoint for every change. The pull request has been a useful answer to those needs for a long time. That doesn’t mean it has to remain the answer.