Since the advent of advanced Artificial Intelligence (AI) tools, a prevailing narrative suggests that the primary bottleneck in software development has shifted from the act of coding to the process of code review. This perspective, however, overlooks a more fundamental truth: neither coding nor code review has historically been the singular bottleneck. Instead, the perception of these as constraints often masks a deeper, more systemic issue – a collective failure to recognize and address the true choke points in the software delivery pipeline. This phenomenon is akin to focusing on a small hill directly in one’s path while ignoring the vast mountain range that looms beyond.
To illustrate this point, consider a straightforward diagnostic test for any software application or service. How many changes, having successfully passed through code review, remain un-deployed and unavailable to end-users? For the vast majority of organizations, the answer is rarely zero or one. Typically, multiple such changes accumulate, signaling that the true bottleneck lies not in the review itself, but in the subsequent stages of the development lifecycle. This indicates a broader industry-wide visibility gap, where the focus on AI’s impact on coding and review obscures the critical processes that follow.
Original research conducted in this domain reveals a stark reality: half of all development teams currently manage between two and ten changes in a single deployment batch, while a quarter of teams contend with batches ranging from eleven to fifty changes. Alarmingly, over 90% of teams consistently ship software in batches rather than deploying individual changes one at a time. This pervasive practice of batching, deeply ingrained in industry workflows, has become so normalized that it is often overlooked as a potential impediment to efficiency and agility. When searching for ways to accelerate software delivery, this ingrained habit appears not as a problem, but as simply "the way things have always been done."
The arrival of AI-powered coding assistants like GitHub Copilot, Claude Code, and Cursor has undoubtedly accelerated the pace at which code is written and, consequently, the volume of code entering the review process. This increased throughput naturally puts additional pressure on code review. Research by Faros AI, analyzing data from 10,000 developers, found that teams with high AI adoption merge 98% more pull requests. However, this increased velocity comes at a cost: review time for these changes escalates by 91%, and the average pull request size inflates by a staggering 154%. Similarly, a study by Cursor, in collaboration with an economist from the University of Chicago, indicated that companies using its coding agent as their default merge 39% more pull requests.
Despite these findings, the assertion that code review has become the primary bottleneck is a misinterpretation. The critical flaw in this reasoning lies in the assumption that faster code generation and review directly translate to faster value delivery. If changes, even after expedited review, are held up in subsequent stages, then the bottleneck is merely being shifted, not eliminated. The increased pressure on code review, while real, exacerbates the underlying problem of inefficient downstream processes.
The Accumulation Effect: When AI Floods the Batch
The true impact of AI on the software development value stream is not uniform. While AI tools significantly enhance the speed of coding and can even assist in code review, their benefits are diluted if the subsequent stages of the pipeline are not optimized. The value stream, which begins with an identified opportunity and culminates in a user receiving that value, is a complex chain. AI’s influence is felt most acutely in the early stages, but its end-to-end benefit is contingent upon identifying and addressing where work accumulates.
A significant portion of the industry appears to be misinterpreting the signals. GitLab’s 2026 AI Accountability Report found that 85% of respondents believe AI has shifted the bottleneck from coding to review. However, the data on deployment batch sizes suggests that this perception is likely inaccurate for a substantial majority. If changes are piling up after the code review, it unequivocally means that code review is not the ultimate constraint. In fact, accelerating reviews in such a scenario would only serve to amplify the pressure on the true bottleneck.
The core issue is that approving changes faster is only beneficial if those changes can then flow smoothly into production. In most organizations, this is not the case. Instead, approved changes often enter a queue for further processing, such as extensive testing, integration, and deployment. When the rate and size of changes passing through the review stage are artificially inflated, the pressure is simply transferred to these less visible, but ultimately more critical, downstream processes. The pipeline’s primary function should be to deliver changes to production where they can be utilized by users, not to act as a holding pen for "pending deployment" items. As these unreleased changes languish, the associated risks inevitably escalate.
Batches as Signposts to True Bottlenecks
The question of batch size serves as a crucial diagnostic tool, pointing directly to what truly constrains the value stream. The identified bottlenecks are rarely related to coding or code review themselves. Instead, they are more likely to be found in areas such as:
- Manual Verification Steps: Inefficient or time-consuming manual checks that must be performed before a change can proceed.
- Cumbersome Change Approval Processes: Bureaucratic or overly complex procedures for granting final approval for releases.
- Limited Deployment Capabilities: Lack of robust automation or infrastructure that restricts the frequency or ease of deploying changes to production.
- Ineffective Release Train Mechanisms: Rigid release schedules that prevent smaller, more frequent deployments.
Most organizations were already operating with substantial deployment batches prior to their AI initiatives. The introduction of AI, by accelerating code generation, naturally tends to increase these batch sizes. Simply improving the throughput of code reviews does not resolve this fundamental issue; it merely funnels more changes towards the real bottleneck.
By accurately identifying the true constraint in the value stream, organizations can strategically invest resources to address the most impactful problem. When retrospectives consistently fail to yield noticeable improvements, it is often a sign that the pervasive "batch problem" is being overlooked. This is precisely why some AI initiatives deliver significant returns, while others falter.
The Limitations of Current Research
While existing research on the impact of AI in software development provides valuable insights, it often falls short by terminating its analysis at the point where code is merged. These studies typically focus on metrics such as the number of open and merged pull requests, and the time spent on code reviews. Crucially, they seldom investigate the duration changes wait after review, nor do they quantify how many changes are bundled together before reaching production. Without this post-review data, identifying the genuine constraint becomes impossible.
Organizations that have invested in AI to accelerate coding may feel compelled to address code review next, or even abandon code reviews altogether in pursuit of speed. However, if the organization is still operating with large deployment batches, neither of these approaches will significantly improve the speed at which risk is mitigated or value is delivered to end-users. The fundamental resistance within an organization to address and fix the "batch problem" is, in essence, the core issue that requires resolution.
A Deeper Dive into the Accumulation Problem
The phenomenon of accumulating changes post-code review is not a new problem exacerbated by AI; rather, AI’s impact has amplified its visibility. Historically, manual processes, legacy systems, and a general lack of robust CI/CD (Continuous Integration/Continuous Deployment) pipelines have been the silent culprits behind slow delivery cycles. These underlying issues often manifest as lengthy testing phases, complex integration procedures, and infrequent, high-risk deployment windows.
Consider a typical scenario: a developer writes code, submits it for review, and it passes. The change is then merged into the main branch. However, instead of being automatically deployed, it enters a queue for integration testing, followed by user acceptance testing (UAT), and finally, a scheduled release. If the testing cycles are lengthy, or if UAT requires significant manual intervention, or if releases are only performed bi-weekly, the time from code merge to user availability can stretch into days or even weeks. AI’s ability to speed up the initial coding and review stages simply means that more changes will be waiting in these subsequent queues, intensifying the bottleneck.
The data presented by Octopus Deploy, showing a significant number of changes per deployment batch, underscores this reality. When a team is shipping in batches of 10, 20, or even 50 changes, the risk associated with each deployment increases proportionally. If a single problematic change is introduced within a large batch, it can necessitate rolling back the entire deployment, impacting all the other successfully reviewed and integrated changes within that batch. This creates a disincentive for frequent, smaller deployments, reinforcing the cycle of large batching.
Re-evaluating the Role of AI and Automation
The promise of AI in software development is not to eliminate human oversight or critical processes like code review, but to augment them and streamline the overall workflow. The goal should be to ensure that every step in the value stream operates at an optimal pace, with no single step becoming a disproportionate impediment.
For organizations struggling with this issue, the focus should shift from optimizing individual stages in isolation to optimizing the flow across the entire pipeline. This involves:
- Implementing Robust CI/CD Pipelines: Automating the build, test, and deployment processes to enable frequent, small releases. This reduces the size of deployment batches and minimizes the risk associated with each deployment.
- Investing in Automated Testing: Expanding the scope and sophistication of automated tests, including unit tests, integration tests, and end-to-end tests, to reduce reliance on manual verification.
- Streamlining Approval Workflows: Re-evaluating and simplifying change approval processes, potentially by implementing policies that allow for automatic promotion to production based on comprehensive automated testing and quality gates.
- Monitoring the Entire Value Stream: Utilizing application performance monitoring (APM) tools and value stream management platforms to gain end-to-end visibility into the flow of work, identifying and quantifying bottlenecks at each stage.
The narrative that AI has simply shifted the bottleneck to code review is a convenient but ultimately misleading simplification. The true challenge lies in recognizing and dismantling the deeply entrenched practices of batch processing that prevent the full realization of efficiency gains from AI and automation. By focusing on the entire value stream and systematically addressing the true constraints, organizations can move beyond incremental improvements and achieve transformative leaps in software delivery speed, quality, and agility. The "mossy hill" of batch processing is not an insurmountable obstacle, but a critical area ripe for reform, offering the most significant opportunity for improvement in the modern software development landscape.
