AI did not remove your bottleneck. It fed it.

Your team gets access to better AI coding tools. A few weeks later, the board looks busier. More branches. More pull requests. More half-finished tickets. More "ready for review". More work that is technically written but not safely shipped.

The uncomfortable question is simple: did you make delivery faster, or did you increase the amount of work waiting in the system?

This matters because many leadership conversations around AI still treat coding speed as the main constraint. If developers write code faster, delivery should improve. Sometimes it will. That only helps when coding was the bottleneck.

In many organizations, it is not.

The bottleneck is review. Or test data. Or product decisions. Or integration. Or release governance. Or one senior engineer who has to approve everything important because the system never made knowledge sharing a real practice.

AI does not cancel those constraints. It sends more work toward them.

Look at arrival rate, not enthusiasm

The useful mental model is more specific than "AI makes developers more productive." That phrase is too broad to help a delivery leader.

Treat AI as a change in the arrival rate of work into the delivery system.

If the team can generate more code per day, more items arrive at review, testing, integration, and release. If those steps have spare capacity, great. If they are already overloaded, queues grow. Lead time gets worse even while local activity rises.

That is queueing theory before it is Agile.

Donald Reinertsen's work on product development flow is helpful here: queues are not neutral. They create delay, hide problems, increase coordination load, and make priorities stale. A queue of pull requests is not "almost done". It is inventory with risk attached.

Recent AI research points in the same direction. Vella and Blincoe's 2026 longitudinal study of professional software engineers found that participants reported spending less time on code writing, but more attention shifted toward evaluating, correcting, and verifying AI output. The authors call this "supervisory engineering work". That phrase is useful because it names the work that many dashboards miss.

The work moved.

Sonar's 2026 State of Code material tells a similar story as a market signal, with strong caveats because it is vendor-published. Their survey summary reports high AI use, high AI-assisted code volume, low full trust in AI output, and a verification bottleneck. The exact percentages matter less than the mechanism: faster generation increases the need for confidence.

Confidence is not created by counting tickets.

WIP is the boring lever that still works

When leaders see more work waiting, the usual response is to add more control: more status meetings, more dashboards, more review rules, more escalation.

Often the better first move is more primitive: stop starting so much.

Work in progress is a system variable, not a moral problem. If ten items are competing for two reviewers, asking for "more ownership" will not change the math. If every team depends on the same platform group, a new prioritization ritual will not add platform capacity.

The empirical software evidence on WIP is not as thick as some Kanban slide decks imply. That matters. Sjøberg's 2018 ESEM study looked at more than 8,000 work items across five Kanban teams over four years. Lower WIP correlated with shorter lead time. That supports the basic flow argument. But the study also found mixed results on productivity, did not measure quality, and could not identify a universal optimal WIP limit.

So the honest claim is narrower.

If you care about lead time, WIP deserves attention. If you care about productivity, quality, and predictability, WIP is part of the system, not a magic dial.

A practical test for the next ten items

Do not start with a transformation program. Start with ten recently finished or currently open work items.

For each one, write down:

• When did work start?
• When did it first wait?
• What was it waiting for?
• Who had to make a decision?
• How many times did it move backward?
• How long did review take?
• Was AI used to generate, change, test, or review the code?
• What made the item safe to ship?

Then look for the queue.

If most delay sits before product decisions, engineering output is not the main constraint. If review waits dominate, adding more generated code will worsen the constraint. If release approval is the delay, AI coding speed is mostly upstream noise. If items keep reopening after review, verification quality is the work.

Now set one explicit WIP rule near the constraint.

Examples:

• No more than three items in code review per team.
• No new feature starts while a release-blocking defect waits.
• Every AI-assisted PR above a size threshold must be split or paired before review.
• One senior reviewer hour per day is reserved for clearing the oldest review queue, not for ad hoc interruptions.
• Product decisions older than 48 hours become visible in the delivery review with a named decision owner.

These are not universal rules. They are probes. A good WIP limit teaches you where the system fights back.

Use AI to improve finishing capacity

The lazy version of AI adoption generates more artifacts and hopes the system absorbs them.

The useful version applies AI where it helps work finish safely:

• Turn vague tickets into testable acceptance examples.
• Draft missing tests before implementation expands.
• Summarize risky changes for reviewers.
• Find duplicated logic before a pull request grows.
• Generate small migration scripts with clear rollback checks.
• Explain old code so review does not depend on one person.

This keeps the attention on flow.

A Delivery Manager should ask one question every week during AI adoption: where did AI reduce waiting, rework, or decision delay?

If the answer is only "we produced more code", the system has not improved yet. It has more inventory.

The leadership move

For CTOs and delivery leaders, the hard part is cultural. Starting work feels active. Finishing work feels constrained, because it forces tradeoffs. You have to say no to new starts. You have to expose overloaded reviewers. You have to admit that the bottleneck may sit in management decisions, not in developer effort.

That is why WIP limits are useful. They make the cost of too many promises visible.

AI can be a real advantage for software teams. But only when the delivery system is designed to absorb faster creation without drowning verification, integration, and release. The sharper question is whether your system can finish more.

Start there.

Sources

• Flournoy, J. C., Lee, C. S., Wu, M., & Hicks, C. M. (2025). No silver bullets: Why understanding software cycle time is messy, not magic. Empirical Software Engineering, 30(6), Article 174. doi.org/10.1007/s10664-025-10735-w
• Patzak, M. (2026, January 7). Your AI coding assistants will overwhelm your delivery pipeline: Here's how to prepare. AWS Enterprise Strategy. aws.amazon.com/blogs/enterprise-strategy/your-ai-coding-assistants-will-overwhelm-your-delivery-pipeline-heres-how-to-prepare
• Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing. search.worldcat.org/title/435994279
• Sjøberg, D. I. K. (2018). An empirical study of WIP in kanban teams. In Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM '18). ACM. doi.org/10.1145/3239235.3239238
• Sonar. (2026). State of code developer survey report. sonarsource.com/the-state-of-code/developer-survey-report/
• Vella, A., & Blincoe, K. (2026). The impact of AI coding assistants on software engineering: A longitudinal study [Preprint]. arXiv. arxiv.org/abs/2605.23135