Will AI Transform the PR?

2025 saw unprecedented growth in the adoption of and impact from AI coding tools. AI’s impact on the SDLC went from ancillary to essential – it’s no longer a “nice to have”, it’s an essential component of how software is built today.

But we also saw that adding coding tools alone can only get you so far. Teams need to look at the overall engineering system and processes to avoid bottlenecks and realize the greatest gains from AI.

Unsurprisingly, many of these potential bottlenecks in the overall SDLC arise from the core assumption that these systems were designed for people, not AI agents. Human engineers represent precious and finite resources, and we need to optimize their limited time and attention. Agents, on the other hand, can be quickly scaled up or scaled down based on real-time demand, and can jump on any task at any time of day. In an AI-first world, we need different systems and processes to accommodate that radically different style of work. And of course the future of engineering is hybrid, so we need to maintain an effective environment for the humans!

Perhaps the most fundamental building block of the modern human-centric engineering workflow is the Pull Request (PR). Pull Requests, which grew out of the traditional code review practices, were designed to optimize for how humans collaborate on software tasks.

At the most basic level, PRs were designed around the assumption of asynchronous collaboration. Let’s say you have a code change that you need to get reviewed. Even if that change is very important, except in extreme cases you would want to avoid interrupting a colleague who is in the flow state and cranking! In distributed environments that colleague might be in a different timezone and might not even be awake when you want a review.

Given this, PRs assume asynchrony and queuing. You post your PR, tag desired reviewers, and wait until they have cycles to dig in and respond. In high performing environments, colleagues are responsive and prioritize reviews. But the expectation simply cannot be around realtime / any time response!

This asynchronous collaboration model then has knock-on effects on the way PRs are scoped. Even in super high performing and responsive environments, there’s some minimum wait time that gets added onto every PR. Given that, you of course want to make each PR “count.” For understandability and reviewability, you of course want to keep your PR as tightly scoped as possible. But to obtain a reasonable level of throughput, you want to bundle up reasonably complete changes. And for human reviewers, seeing the “right” scope of changes in one coherent bundle can make things easier to understand.

PRs are at the heart of the SDLC for most organizations, but given these historical assumptions, it’s increasingly clear that they don’t totally fit in a world of AI agents.

How will we need to re-orient the SDLC for the AI era, and what will this mean for the PR as we know it? The answer to these questions is closely related to the adoption of autonomous AI agents for software delivery tasks. Despite lots of buzz, agents have not been widely adopted yet, and even for those experimenting with agents, the actual results have been a bit limited.

So far, much of the improvement we’ve seen in software delivery due to AI has been based on assistants for humans, such as Copilot or IDE based AI coding tools. It’s no surprise that these tools were able to deliver quick wins, since it’s basically playing on “easy mode” in terms of how they cleanly fit into existing software development processes. But you can only speed up a human working in a linear fashion so much. The next wave of advancement will need to come from handing off more and larger tasks to AI agents operating independently from humans.

One basic requirement of this agent-oriented environment will be that we must optimize our processes for smaller units of work. This requirement derives from a number of sources, not the least of which is the emerging / immature nature of agents. Until we develop much more advanced and capable agents, we need to create an environment that is amenable to human supervision and adjustments. Working in small units means that we can quickly observe when things are off track and make corrections before burning tons of time and tokens on the wrong approach.

But even if these issues of trust and oversight resolve in the future as agents become more capable, and as humans get better at working with them, there are still compelling drivers to working in small units. For one thing, smaller changes are easier to work with. Everything from debugging an issue, resolving conflicts from a separate change, reviewing code for quality, and more, is easier and flows better in smaller units. This helps both AI agents and human developers.

Agents offer the promise of scaling capacity on demand to accommodate real-time demand. Of course, to reap the benefits of this type of elastic scaling, we can’t have the output of surged capacity blocked by bottlenecks elsewhere in the process. With traditional PRs, work that depends on changes in the PR is mostly blocked, limiting flow and ability to parallelize work. Our processes will need to avoid these kinds of pipeline stalls.

As described, PRs fundamentally evolved to support asynchronous collaboration. But with agents, there’s no time like the present to pick up any and all work. In fact, the sooner the better in terms of both unblocking any dependent work, and also making incremental results inspectable by human oversight as soon as possible.

So what might a re-imagined PR model and git workflow look like for the AI agent era? It’s safe to say that a final consensus answer has not yet emerged, but there are some approaches we can look at that provide some hints at very promising directions.

One clear example in this space is the idea of Stacked PRs as supported by Graphite. In the standard “feature branch” git workflow, we create a new branch off of our main branch to work on a feature or project, make multiple commits to that branch, and then post a PR to merge the overall branch. This tends to block work that depends on these changes. But on the “stacked PRs” model, we create a small single-commit change and post a PR based on that. And if we need to proceed with dependent changes, we make a branch off of that branch, proceeding in a tree-like pattern.

To avoid the challenge of then re-basing upstream changes into a potentially deep stack of dependent branches, which would make for a lot of repeat work using standard git, Graphite provides tools to automate this type of change propagation and re-basing. Along with features like a PR agent and a unified inbox to manage PR activity, this provides a foundation for working with stacked PRs.

Working with stacked PRs can unlock big benefits for flow. Unlike in the standard git workflow, you (or an agent) are never blocked. You can simply keep building on unmerged code. And the model bakes in the idea of working in small changes, and all of the benefits that this provides. Of course, the idea of stacked PRs is not new, but its benefits are amplified in an AI-powered development environment, especially one with agents across the SDLC including posting and reviewing PRs.

CircleCI has recently released capabilities that drive directly at the idea of better flow for PRs. They bundle these ideas under the label of Autonomous Validation, fundamentally looking at how to intelligently apply AI and automation to achieving faster throughput on code reviews. Of course, many autonomous code review agents have come onto the scene in the past year or so, offering the ability to automatically pick up PRs and post reviews. How is Autonomous Validation different?

For one thing, Autonomous Validation looks at the challenges related to the connection between CI and PRs. Of course, before we merge a PR, and as we make changes to it, we want to ensure that our tests are clean. But this can impose delays on merging, which hurt throughput and flow. One core idea of Autonomous Validation is around employing AI to run only the “right” tests, and to learn this relationship between changes, files, and tests over time.

By targeting tests to the change in question, the system can maintain pace while preserving quality safeguards. This capability encourages and rewards working in small units. The more focused the change, the more effective the system should be at targeting a narrow but sufficient set of tests, resulting in faster test times and better overall throughput.

Beyond testing changes, Autonomous Validation looks at improving the overall system to enhance flow. In particular, the CircleCI Chunk agent proactively looks for test issues such as flaky tests and proposes changes to improve these issues. Better, faster CI should improve flow for both humans and agents.

While the final form factor of the next generation of PRs is not yet fully resolved, we can expect lots of activity in this area in the months ahead. Examples like Graphite and CircleCI give us some hints at what that might look like, especially around the drive towards working in small units, avoiding pipeline stalls in the development flow, and generally adding more and smarter automation to the process.

And beyond mechanics of the process, we will need to confront some basic questions about how we work. For example, I’ve strongly believed that all AI generated code will continue to require human review. But is that really the case? As LLMs get better, and our frameworks and approaches for managing agents advance, might we grow comfortable with at least some changes being fully autonomous? The answer to this question will make a huge difference in terms of the productivity gains that will be possible before hitting the very basic limits imposed by your team size.

It’s likely that we’ll continue to see changes to our software processes in basic areas such as PR workflow. One clear implication of this change is that Engineering leaders will need to evolve their metrics and measurement approaches in conjunction with changes to process. It’s fairly common to look at metrics like PR throughput and cycle time, both generally as engineering productivity metrics, and also as measures of AI impact.

Generally, this turbulence in the SDLC is an argument for working with an Engineering Metrics platform like Jellyfish or DX, as these platforms intrinsically seek to buffer their customers from the heterogeneity and ongoing changes in the underlying engineering tools environment. And AI powered development has certainly brought heterogeneity and change!

The AI Impact capability from Jellyfish bakes in a solid amount of resilience to changing processes by looking at a wide variety of measures For example, as PRs evolve, there are still key measures like Issue Cycle Time or Allocation that are likely to be fairly durable. And DX provides a capability for estimating PR complexity using AI called True Throughput, which promises to provide a measure of throughput that is resilient to changes in PR granularity,

Again, what this will all look like in future steady state is still to be seen. But the pace of new ideas being explored and progress being made is genuinely exciting!