AI-assisted development can move the queue into review

A useful first question for an AI-assisted delivery system is: where did the queue move?

Consider a hypothetical team. Pull requests begin to arrive faster after it adopts an authoring agent. The review column grows while the number of reviewed, integrated changes barely moves. A chart of PRs opened per week looks better. Confidence in the next release does not.

That gap is worth investigating. Opening a pull request is not the unit of value; a reviewed, integrated, releasable change is. If tooling raises the first number without moving the second, the delivery system has acquired a longer queue in front of the same constraint.

The review column is a service system, not a status

Most teams treat review as a step. It behaves more like a service system with arrival rates, service times, batch sizes, and rework loops. Work arrives when PRs open. It waits until a reviewer engages. It gets serviced through reading, questioning, and approving. Some of it comes back as author revisions, second review passes, or post-merge fixes.

Introducing an AI reviewer or an AI author can change the arrival pattern and the service pattern at once. Finding a real defect is only one outcome. The wider question is what happens to waiting time and rework across the whole system.

Cihan et al. (2025) studied one multinational company rolling out a GPT-4-based review tool, available across ten projects with detailed analysis of three. Developers acted on a meaningful share of the automated comments, which is a genuine finding: the tool was not producing noise that everyone scrolled past. Overall PR closure time went up after adoption rather than down, human review comments did not consistently decrease, and the effect was not uniform. One project got faster while two got slower.

That variation matters more than the headline, and a single average would have hidden it. The authors suggest that developers may have spent extra time fixing issues raised by the tool. They also flag seasonality: the data collection covered the summer, when staff holidays may have reduced development pace. This is one company and one tool, observed rather than controlled. The study shows an association, not a causal queue mechanism.

The mechanism behind slower closure shows up in adjacent work. Aðalsteinsson et al. (2025) ran a field study at an automotive software company and found developers hitting two recurring frictions: context switching, and AI feedback that lacked the context needed to judge it. Reviewers generally welcomed AI support on large or unfamiliar changes, where the assistance offset the cost of orientation. On code they knew well, the calculus shifted. Their conclusion favored hybrid support, proactive in some situations and on demand in others, with the reviewer keeping control of when it appears.

Read those studies together and a plausible mechanism emerges. Automated comments are not free. Each one is a small unit of work someone must triage: read it, decide whether it applies, act or dismiss, sometimes discuss. On a large unfamiliar change, that triage may buy useful orientation. On a change the reviewer already understands, it may add overhead to a queue that was already the constraint. The mechanism needs to be tested locally rather than inferred from closure time alone.

There is positive evidence too. Google's AutoCommenter study reported that a large-scale system for checking coding practices was feasible and had a positive impact on developer workflow (Vijayvergiya et al., 2024). A later Atlassian evaluation reported a 30.8% decrease in PR cycle time and 35.6% fewer human-written comments for its RovoDev Code Reviewer (Tantithamthavorn et al., 2026). These are industrial evaluations of specific systems, not general causal estimates. They show why the useful question is conditional: under which review conditions does a tool remove more work than it creates?

AI-assisted authorship is a different intervention, but it changes the same queue from upstream. Watanabe et al. (2026) examined several hundred pull requests authored by an agentic coding tool across open-source projects. Many were merged, and a substantial share of the merged ones needed human revision first. The agent produces mergeable work, and that work still lands in the human queue carrying revision demand with it. This is open-source data and one agent family, and open-source review dynamics differ from enterprise ones. The evidence concerns agent-authored pull requests, not automated review quality.

Chowdhury et al. (2026) looked at the review side, comparing agent-only review against human-only review across reviewed pull requests in an open-source dataset. Agent-only review was associated with lower merge rates and more abandonment, alongside a high volume of low-signal feedback. The comparison is observational and confounded. PRs that get agent-only review are probably not a random sample; they may be lower-stakes, less owned, or from contributors with less project standing. Do not read causality into it. Read it as evidence that removing humans from review does not preserve the outcome that review was producing.

AI assistance does not remove the review constraint by default. Review automation can change service time and triage work. Authoring agents can change arrival volume and revision demand. Either intervention can shorten the queue, lengthen it, or change the work inside it.

That reframing makes the evidence actionable. If the tool converts reviewer reading time into more triage and rework, closure may get slower. If it lets a reviewer engage sooner with a large change they would otherwise have avoided, closure may get faster. Which one you get depends on the review system around the tool as much as on the tool itself.

What the evidence can and cannot support

The studies use different settings and methods: industrial case studies, a field study at a single company, and observational analyses of open-source repositories. None establishes a general causal effect on delivery throughput, and none transfers cleanly to every team.

Collectively they support something narrower and useful. Automated review changes the composition and timing of work in the review system. The direction is mixed. The evidence cannot support a general claim that AI review speeds up or slows down delivery.

That should lower your confidence in vendor throughput claims and in your own before-and-after dashboards. It should not stop you from adopting the tools. It should change what you measure afterwards.

Trace twenty pull requests

Take the last twenty AI-assisted PRs in one team, not a sample across the organization, so the context is comparable. Record whether each PR involved AI-assisted authorship, automated review, or both, along with the relevant tool and configuration state. Do not pool those intervention groups when you compare them. Then walk each PR from opening to merge or closure and record waiting time before the first meaningful human response, kept separate from total cycle time; which automated comments were acted on and which were ignored or dismissed; how many revision loops the author went through after the first review pass; change size; whether the PR was abandoned; and whether it generated post-merge rework within a couple of weeks.

You are looking for where time actually goes and which hypothesis to investigate. If waiting dominates, examine reviewer availability, assignment policy, priorities, work in progress, dependencies, and review cadence. More automated comments may not address any of those causes. If revision loops dominate, examine change size, specification quality, automated-feedback quality, contextual gaps, and review norms. If ignored comments dominate, investigate signal quality and configuration rather than assuming that every ignored comment was useless.

Then change one operating condition and hold it for four weeks. Cap PR size, make automated review on-demand for code the reviewer owns, or assign a reviewer at open time instead of leaving PRs unclaimed. Run the same trace on the next twenty and compare. Treat the result as an exploratory signal, not a causal test: two small sequential samples remain exposed to workload mix, staffing, seasonality, tool changes, and regression to the mean. A longer baseline and repeated observations are needed before attributing a change to the intervention.

Two constraints on how you use this. Do not attribute the numbers to individuals, because the moment reviewer response time becomes a performance metric, people optimize the metric and you lose the signal. And do not run three changes at once, then guess which one worked.

On Monday morning, open your board and filter to PRs merged or closed in the last three weeks. Export the twenty most recent that involved AI assistance. Put a spreadsheet next to it with a separate column for each intervention and flow field above, then fill in the first five rows yourself. The trace will not prove what caused a delay. It will show where to investigate next.

References

Aðalsteinsson, F. S., Magnússon, B. B., Milicevic, M., Davidsson, A. N., & Cheng, C. H. (2025, October 2). Rethinking Code Review Workflows with LLM Assistance: An Empirical Study. 2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 488-497. https://doi.org/10.1109/ESEM64174.2025.00013

Chowdhury, K., Banik, D., Ferdous, K. M., & Shamim, S. I. (2026, April 13). From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests. Proceedings of the 23rd International Conference on Mining Software Repositories, 984-988. https://doi.org/10.1145/3793302.3793614

Cihan, U., Haratian, V., İçöz, A., Gül, M. K., Devran, Ö., Bayendur, E. F., Uçar, B. M., & Tüzün, E. (2025, April 27). Automated Code Review in Practice. 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 425-436. https://doi.org/10.1109/ICSE-SEIP66354.2025.00043

Tantithamthavorn, K., Zou, Y., Wong, A., Gupta, M., Wang, Z., Buller, M., Jiang, R., Watson, M., Jeong, M., Chen, K., & Wu, M. (2026, April 12). RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-based Code Review Automation at Atlassian. Proceedings of the IEEE/ACM 48th International Conference on Software Engineering: Software Engineering in Practice. https://doi.org/10.1145/3786583.3786851

Vijayvergiya, M., Salawa, M. G., Budiselić, I., Zheng, D., Lamblin, P., Ivanković, M., Carin, J., Lewko, M., Andonov, J., Petrović, G., Tarlow, D., Maniatis, P., & Just, R. (2024, July 10). AI-Assisted Assessment of Coding Practices in Modern Code Review. Proceedings of the 1st ACM International Conference on AI-Powered Software. https://doi.org/10.1145/3664646.3665664

Watanabe, M., Li, H., Kashiwa, Y., Reid, B., Iida, H., & Hassan, A. E. (2026, March 6). On the Use of Agentic Coding: An Empirical Study of Pull Requests on GitHub. ACM Transactions on Software Engineering and Methodology. https://doi.org/10.1145/3798166