A faster coding tool can leave delivery unchanged

The AI adoption review starts with a convincing demo. A developer turns a short prompt into a working implementation. Another shows how an agent handled a routine change across several files. The room sees less typing, quicker first drafts, and fewer minutes spent searching for syntax.

Then the delivery review starts.

A change has waited two days for review. Another is back with Product because its acceptance criteria left a policy decision open. A third passed its tests but cannot enter the next release window. The coding step moved faster. The delivery date did not.

Both observations can be true. They describe different parts of the system.

The system receives work faster than it can finish

A coding assistant changes local production capacity. It may reduce the touch time needed to write a test, understand an unfamiliar API, draft documentation, or produce a first implementation. That matters. It is also only one stage in the path from an idea to a useful change in production.

After code exists, someone still has to understand it, review it, test it in context, resolve open decisions, integrate it, release it, and watch what happens. Some of that work can also be automated. Some depends on scarce attention, judgment, or authority.

If code arrives at those stages faster while their capacity stays the same, the queue grows. The team may complete more coding tasks while work items spend longer waiting for review or release. Local throughput rises, but end-to-end lead time barely moves. Variation may grow as routine changes pass quickly and uncertain changes age in the tail.

This is the distinction many AI dashboards miss. They measure suggestions accepted, tasks completed, commits, or lines changed. Those measures describe activity near code production. A Delivery Manager needs to know whether useful, verified changes reach users sooner and with acceptable risk.

Task evidence is not delivery evidence

The research on coding assistants gives leaders a reason for interest and a reason for restraint.

Mohamed et al. (2026) reviewed 39 peer-reviewed studies of large-language-model assistants in software development. Most reported some benefit, often through faster work on coding, testing, documentation, or search. Yet the results for code quality were contradictory, and the evidence rarely followed teams over time or examined communication and coordination across the delivery path.

That gap changes what you can claim. The review supports “this tool may help with this development task.” It does not support “our product area will now deliver faster.” The second statement requires evidence about the whole work system.

Agarwal et al. (2026) offer a more direct look at coding agents in open-source repositories. Their longitudinal comparison found an early increase in development activity for some adopters, but the gain depended on whether projects had already used AI tools. The study also found persistent increases in static-analysis warnings and cognitive complexity. That does not prove that AI-generated code is generally worse. It shows that acceleration and downstream quality burden can coexist in one real-world setting.

The study measures repositories, not enterprise delivery commitments. Architecture reviews, product decisions, security approvals, release governance, and customer validation sit largely outside its frame. Still, the mechanism is useful: faster production at one stage can create more work at another.

Automation can improve a stage without shortening the path

This pattern predates generative AI.

Bernardo et al. (2023) studied continuous-integration adoption across a large set of open-source pull requests and complemented the repository data with developer surveys. The automation did not necessarily shorten the time needed to deliver merged changes. Its clearer benefit was better decision support around pull requests, without simply shifting an unmanageable load onto reviewers.

Continuous integration and coding agents are different technologies. The study is not evidence about AI. It is a useful counterexample to a common management assumption: automating a development activity does not guarantee a shorter end-to-end path.

The result depends on which constraint the automation changes. Faster feedback may help reviewers decide. Better tests may reduce rework. Automated policy checks may remove a governance wait. But producing more change sets for the same review queue raises demand without raising service capacity.

That is why an AI rollout needs a delivery hypothesis, not only a tool hypothesis. “Developers will write routine code faster” is a tool hypothesis. “Smaller batches and faster test feedback will reduce the time from active work to production” is a delivery hypothesis. It names the part of the path that should change.

Find the constraint AI moved

Imagine a team that previously opened ten meaningful changes in a week and could review about the same number. An assistant helps it open more. Unless review capacity, batch size, or review effort changes as well, open pull requests accumulate. Reviewers start switching more often. Feedback arrives later. Authors reload context before applying it. Some changes need another review because the surrounding code has moved.

The exact numbers do not matter. The imbalance does.

The same logic applies beyond code review. AI may move the constraint into:

• product decisions, because more implementation options expose more unresolved choices;

• integration, because larger or more frequent changes meet shared environments and coupled components;

• security and governance, because reviewers must evaluate unfamiliar generated code or new dependencies;

• release capacity, because production exposure still follows fixed windows or manual controls;

• rework, because locally plausible code fails when it meets system context.

Do not respond by asking every downstream function to “use AI too.” That may help, but it repeats the same local-optimization bet. Start with the queue. Decide whether it should exist, whether demand can fall, whether batches can shrink, whether authority can move, or whether automation can remove a real waiting state.

Keep work in progress in the discussion. When AI reduces coding touch time, teams can start more work before they notice that finishing capacity has not changed. A tighter WIP limit may look conservative in an adoption dashboard. In the delivery system, it protects attention and makes the new constraint visible sooner.

Run an AI flow trace on Monday

Take the last 20 AI-assisted work items that reached production. Choose items from one product area and a similar class of work. For each item, mark these moments:

• first active work;

• pull request opened and merged;

• time waiting for review and the number of review loops;

• time waiting for product, architecture, security, or governance decisions;

• integration completed;

• production release;

• any reopen, revert, escaped defect, or substantial rework.

Separate touch time from queue time. Then compare the pattern with similar work before adoption, or with comparable work where AI was not used. This is not a ranking of developers. It is a trace of the system they work in.

Look at the longest waits, not only the average. Ask where AI removed effort, where it created extra arrival rate, and where elapsed time merely moved. Pick one operating change at the binding stage: reduce WIP, protect review capacity, shrink change batches, move a decision right, improve test feedback, or make release capacity explicit.

Run that change for four weeks. Watch finished work, queue age, rework, and the spread of cycle times.

Only then decide whether the delivery system needs more coding capacity.

References

Agarwal, S., He, H., & Vasilescu, B. (2026). AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development. Proceedings of the 23rd International Conference on Mining Software Repositories, 857–862. https://doi.org/10.1145/3793302.3793589

Bernardo, J. H., da Costa, D. A., Kulesza, U., & Treude, C. (2023). The impact of a continuous integration service on the delivery time of merged pull requests. Empirical Software Engineering, 28(4). https://doi.org/10.1007/s10664-023-10327-6

Mohamed, A., Assi, M., & Guizani, M. (2026). The Impact of LLM-Assistants on Software Developer Productivity: A Systematic Review and Mapping Study. ACM Transactions on Software Engineering and Methodology. https://doi.org/10.1145/3809494