Your Agents Can Write More Code. Can Your Organization Absorb It?

A coding agent can finish an implementation and open a pull request before an engineer has finished reviewing the previous one. That can be a productivity gain, but the pull request is still a proposed change. Someone has to decide whether it belongs in the product, works with the existing system and meets the conditions for acceptance.

Research into agent-authored pull requests suggests that people stay involved when agents write the code, though the kind of work they do shifts. Engineers may intervene less often, but some of those interventions involve substantial rework, guidance and integration decisions.

That raises a question worth investigating: when agents produce more changes, does the organization have the capacity to evaluate and integrate them?

What Happens After an Agent Opens a Pull Request?

A 2026 study presented at the Mining Software Repositories conference, Behind Agentic Pull Requests, compared human interventions in agent-authored pull requests with those in human-authored ones. Humans intervened less often on agent-authored work (52.17% of pull requests against 83.59%). When they did intervene, it took more review effort, with larger code churn and longer durations. Most of that effort went to guidance, such as restricting what the agent did and enforcing project conventions. The authors describe developer work as shifting from implementation to supervision, guidance and quality control.

A lower intervention rate could mean agent work needed less help, or that it got less attention, and the study doesn't establish which. It also doesn't show whether agents add or remove engineering work overall. What it does show is that the work takes a different form, with engineers guiding agents, fixing integration problems and deciding whether a proposed change belongs in the codebase.

Another 2026 study, Where Do AI Coding Agents Fail?, looked at about 33,000 agent-authored pull requests and read a sample of 600 rejected ones in detail. The most common pattern, in about 38% of that sample, was reviewer abandonment: the pull request got little or no human attention before it was closed. Duplicate changes and CI or test failures came next, and unmerged pull requests tended to be larger and more likely to fail CI.

Both studies draw on public open-source projects and both are observational. Enterprise teams with different review practices may look different, and neither study measures review queues directly. What they show is that a generated pull request still has to be understood, validated and accepted before it counts as delivered software, and that among the rejected pull requests in the second study, the most common pattern was that nobody looked.

A Simple Queue Gets Long Fast

Here's a hypothetical: a team opens about 40 pull requests a week and has enough review and integration capacity for about 40. With agents in the mix it starts opening 70, and its capacity stays at 40.

That's 30 extra changes a week. After four weeks there could be 120 waiting, assuming nothing gets withdrawn and the rates hold. That's a backlog equivalent to three weeks of review and integration capacity, before accounting for any new work arriving. The numbers are invented, and the arithmetic is the point: whenever changes arrive faster than the team can process them, the backlog grows until the team processes more than arrives or reduces what comes in.

Teams may respond by prioritizing newer or more urgent changes. Older work can go stale and need rebasing against a codebase that moved underneath it, and some changes may be closed without review, which is the same pattern the rejection study found. That distorts measurement, because a queue can look stable while work is being abandoned and less proposed work is making it through.

Why Review Capacity Doesn't Grow on Its Own

Agents may also free engineers to review more work, and review agents can help with repeatable checks. But time saved writing code doesn't automatically become capacity for validation or integration. Engineers may spend it checking output, guiding an agent, reworking a change that missed the point or starting another implementation. The intervention study found that most of that effort went to guidance and decisions, and both take judgment about how the system is supposed to work.

Adding reviewers can help with the backlog, though it won't help with every change. A pull request that touches an API contract, changes database behavior and adds application logic might need three different people, and the conversation about whether it's the right design takes as long as it always did.

Changing what arrives in the queue probably helps more. Smaller changes are easier to pick up, although breaking a feature into twenty fragments creates its own coordination work. An agent can also run the integration tests and check interface contracts before it opens a pull request, so a reviewer isn't the first one to find out a contract broke.

Measure the Path From Change to Production

A count of generated code or opened pull requests won't tell you much about whether agents are helping. A team can double the pull requests it opens and still merge fewer of them.

I'd look at a handful of measures together, and where the data allows I'd split each one by unassisted, AI-assisted and agent-authored work, because combining them hides the differences.

• Pickup time. How long a change waits before anyone starts reviewing it. If pickup time goes up while coding time goes down, work is probably piling up at review.
• Review-to-merge time. Track the elapsed time from review start to merge separately from pickup. That interval can include waiting and rework, so it isn't a measure of active reviewer effort.
• Open pull requests and age. Track the queue size, how long changes have been waiting and the work assigned to available reviewers. A raw count per reviewer can hide differences in complexity.
• Human intervention effort. How much people do to correct, guide or integrate an agent's change: review rounds, follow-up commits and time spent.
• Merge rate, abandonment and reasons for rejection. How much proposed work gets merged within a set window, how much gets closed unmerged, and why: duplicate, failed CI, unwanted, or nobody looked. Read it next to what the work was for, since experiments are supposed to get thrown away.
• Rework. How much a change gets rewritten after it's opened, and how often it needs a rebase while it waits.
• Deployment and reliability. Cycle time, deployment frequency and change failure rate show whether more changes are actually reaching production, and whether they hold up once they're there.

No single one of these tells you much on its own. A shorter review time isn't good news if change failure rate goes up, and a higher merge rate might just mean the team stopped proposing hard changes.

What to Look for in Your Own Data

Start with the pull request data you have. Separate unassisted, AI-assisted and agent-authored work where you can, then compare similar changes: the same kind of task, a similar size, the same priority. For each group, look at pickup time, review rounds, intervention effort, outcomes and what actually reached production.

If code generation got faster while pickup time, open pull requests and abandoned changes went up and deployment frequency stayed flat, the tools may be increasing output without improving delivery throughput. If agent work consistently waits longer or gets rejected more often, find out why before buying more coding capacity. The next improvement may be in how work is scoped, verified or integrated.

None of this shows that agents slow delivery down. It does mean the capacity to evaluate and accept changes can become the constraint, and that's worth measuring before you assume it isn't.