A guide for engineering leaders, delivery managers, product owners and transformation sponsors. Why AI adoption made work in progress limits more useful rather than less, what the 2025 DORA research actually found, and the six changes worth making to a Kanban system when a machine writes the first draft.
The short answer
This is a different answer from the one most teams expect. The intuition is that AI makes Kanban obsolete: if work gets produced in minutes, why bother constraining it? The evidence points the other way. Google's DORA programme found in 2025 that AI adoption is associated with higher software delivery throughput and, at the same time, with lower delivery stability. More work comes out. More of it comes back.
That combination is the definition of a flow problem, and it is what Kanban was built to expose.
What Kanban actually is
Kanban is a method for managing knowledge work by making it visible, limiting how much is in progress at once, and improving the system based on what that reveals. It is not a project management tool, a board layout, or a software product, though it is often confused with all three.
The word comes from Toyota, where the industrial engineer Taiichi Ohno developed a card based signalling system in the late 1940s and early 1950s, drawing on how American supermarkets restocked shelves in response to what customers actually took rather than to a forecast. The application to knowledge work is much more recent. David Anderson built a pull system for a Microsoft engineering team in 2004 and formalised the approach in his 2010 book, which is where the version practised in software and business teams today originates.
The method is usually described as six general practices. They are worth listing precisely, because the rest of this article is about how each one behaves differently once AI is producing work.
| Practice | What it means |
|---|---|
| Visualise | Make the work, the workflow and the risks visible, normally on a board with columns representing real states |
| Limit work in progress | Cap how many items may be in a given state at once, so that work is pulled when there is capacity rather than pushed when it arrives |
| Manage flow | Watch how work moves, and act on where it stops rather than on how busy people look |
| Make policies explicit | Write down the rules: what "done" means for each column, what may be pulled, who decides |
| Implement feedback loops | Hold regular reviews at the item, team and service level |
| Improve collaboratively, evolve experimentally | Change the system in small steps and check whether each change helped |
Two things follow from this list that matter for the question at hand. Kanban never specifies who or what does the work, which is why it applies unchanged to a team whose first drafts arrive from a model. And limiting work in progress is a constraint on the system, not on the individual. That distinction is the whole argument.
What the 2025 evidence shows
The most reliable public evidence comes from DORA's 2025 research programme, based on survey responses from nearly 5,000 technology professionals worldwide plus more than 100 hours of qualitative interviews. Its headline finding is that AI acts as an amplifier: it magnifies the strengths of organisations that already have good delivery systems, and magnifies the dysfunctions of those that do not.
| Finding | Figure | Why it matters for flow |
|---|---|---|
| AI adoption among technology professionals | About 90%, up sharply on 2024 | This is no longer a pilot population. Whatever AI does to flow, it is doing it to most teams |
| Median daily time spent working with AI tools | Two hours | Substantial, but far from the whole day. Most of the working day is still spent on everything that happens after generation |
| Report AI increased their productivity | More than 80% | Perceived individual gain is close to universal, which is why organisational results are so often assumed rather than measured |
| Report little or no trust in AI generated code | 30%, against 24% reporting high trust | Low trust is not an attitude problem. It converts directly into review time, which is capacity |
| Effect on software delivery throughput | Positive relationship | More work reaches the end of the pipeline |
| Effect on software delivery stability | Negative relationship | More of that work fails or needs rework, which re-enters the system as unplanned demand |
Read those last two rows together, because separately each is misleading. Throughput rising while stability falls does not describe a faster system. It describes a system producing more work and more rework at the same time, where the second quietly consumes the capacity gained from the first.
One related finding is worth citing carefully, because it is now widely cited wrongly. A randomised controlled trial published by METR in July 2025 followed 16 experienced open source developers across 246 tasks in repositories they knew well. Those given access to AI tools took 19% longer, while estimating afterwards that the tools had made them roughly 20% faster. METR then ran a follow-up with more developers and newer tools, and reported in February 2026 that selection effects had made it an unreliable measure of the current productivity effect: developers declined to take part without AI access, and between 30% and 50% said they had withheld tasks they did not want to attempt without it. The follow-up's raw data pointed towards a speedup rather than a slowdown.
So the 19% should not be quoted as evidence that AI makes developers slower, and anyone still quoting it that way is working from a superseded reading. What survives is the finding that matters more for planning: in the original trial, self assessment and measured completion time pointed in opposite directions. Perception was not a reliable proxy for performance, which is why it is a poor basis on which to size capacity.
The work changed shape
The single most useful sentence in DORA's 2025 material is not about speed at all. Describing what happens when teams work in small batches with AI, the research notes that the focus shifts from raw code generation to decomposition, prompting and verification.
That is a description of a different job. The task is no longer principally to produce the artefact. It is to break the problem down well enough to be delegated, to specify it clearly enough to be executed, and then to establish that what came back is correct. Only the first and last of those are constrained by human capacity, and the last one is the expensive part.
DORA offers a specific mechanism for why this is harder than it looks. Reviewing a small piece of unfamiliar, machine generated code may carry a higher cognitive load per line than reviewing the equivalent code written by a colleague whose habits and intentions you already know. Reviewers normally rely on context they do not consciously notice: who wrote this, what they were working on, what they tend to get wrong. Generated work arrives without any of that, so more of it has to be reconstructed from the artefact itself.
This generalises well beyond software. The same shift appears wherever AI drafts a first version: contract review, credit memos, marketing copy, policy documents, financial analysis. Generation gets cheap, verification does not, and accountability stays exactly where it was.
Where the constraint moved
On a conventional board, the widest column and the tightest limit sit around building. That reflected a real constraint for thirty years: making the thing was the slow part.
It is now common for that assumption to be wrong. When generation accelerates and verification does not, the constraint moves downstream to review, testing and approval. A board that still limits work in progress at the build step is regulating a step that is no longer the bottleneck, which means the limit does nothing except let work accumulate in front of the step that is.
The symptom is recognisable before the diagnosis is. Throughput charts look healthy because items keep entering. Individual developers report being faster, and they are not lying. Yet nothing reaches production noticeably sooner, review queues lengthen, and the oldest item in flight keeps getting older. That last signal, work item age measured against the review column, is normally the first hard evidence, and it is the one most default board views do not display. The four Kanban flow metrics cover how to instrument this properly, and DevOps metrics in 2026 covers the delivery measures that sit alongside them.
What to change on the board
DORA's 2025 work identifies seven capabilities that determine whether AI adoption produces organisational results, and two of them are Kanban practices in all but name. Working in small batches is batch size control, described by DORA as a critical countermeasure to the risks of AI assisted development, on the grounds that large generated changes are difficult to review, test and integrate safely. A clear and communicated AI stance is Kanban's make policies explicit practice, applied to what AI may be used for and by whom. DORA found that where this stance is unclear, developers either act too conservatively or too permissively, and neither produces value.
This is not an analogy we are imposing on the research. Setting out how to implement small batches, DORA's own recommendation is to use Kanban-style boards with explicit work in progress limits, on the grounds that doing so makes bottlenecks visible and forces a team to focus on getting work to done. Its guidance also warns specifically against local optimisation, where a team completes its own work quickly and hands it to the next step, causing work to pile up and creating a bottleneck that slows the whole system. That is a description of the pattern above, in the research's own terms.
So the method is not in question. What remains is the design work, which is where the research stops and practitioner judgement starts. Six changes are worth making, one per practice.
| Practice | What to change |
|---|---|
| Visualise | Split the review or verification step into its real states. Most boards collapse "waiting for a reviewer", "being reviewed" and "changes requested" into one column, which hides the queue precisely where it now forms. Mark on each card whether the first draft was generated, so that review effort can be seen against provenance rather than guessed at |
| Limit work in progress | Set the binding limit against review and verification capacity, not generation capacity. The practical test is simple: if a team can start more items in a week than it can honestly verify in a week, the limit is in the wrong column |
| Manage flow | Track work item age against the review states specifically. Rising age there, while throughput holds steady, is the clearest early signal that generation has outrun verification |
| Make policies explicit | Write the AI stance into the board's own policies rather than leaving it in a separate governance document: which tools are approved for which work, what disclosure is expected on a card, and what a reviewer is accountable for when they approve generated work. DORA's evidence is that clarity here, not permissiveness or restriction, is what correlates with results |
| Implement feedback loops | Add rework and change failures back onto the board as visible demand. If defects return through a separate channel, the board will keep reporting a healthy system while the stability cost accumulates out of sight |
| Improve collaboratively, evolve experimentally | Change one limit at a time and measure for a few weeks before the next change. This is ordinary Kanban discipline, and it matters more than usual here because the tools themselves are changing underneath the experiment |
One entry policy is worth adding alongside these, because it comes straight from the evidence. DORA's guidance is that a unit of work should be completable in hours to a couple of days, and that anything taking more than a week is too big. That is a defensible explicit policy for what may be pulled onto a board, and it directly counteracts the tendency of generated changes to arrive large.
One measure is worth borrowing too. DORA's value stream mapping guidance uses percent complete and accurate: the share of work arriving at a step that the step can use without sending it back. If six of ten changes reaching review are accepted without rework, that step is running at 60%. Tracked over time against the proportion of work that was AI generated, it answers the question a throughput chart cannot, which is whether the work arriving at the constraint is getting better or worse.
Expect one uncomfortable result. DORA found that small batch discipline slightly reduces the perceived individual effectiveness gains from AI, while channelling the work into a more stable delivery process. Constraining the system will make some people feel slower, at the point where the organisation starts getting faster. That trade needs to be named in advance by whoever sponsors the change, or it will be reversed the first time someone senior asks why the tools are being held back.
When Kanban is not the answer
Kanban regulates flow through an existing system. It does not fix problems that sit outside it, and it is worth being clear about the three cases where reaching for it is a mistake.
The verification capability does not exist. If there is no meaningful automated test coverage, limiting work in progress will slow generation down without making anything safer, because the review step is not actually verifying much. DORA's finding on version control practices points the same way: the safety net has to exist before the speed is useful. Build the capability first.
The work is genuinely unpredictable research. Flow management assumes work items are broadly comparable units moving through repeatable states. Exploratory work where the next step depends on what the last one revealed does not fit that shape, and forcing it onto a board produces theatre.
The real constraint is a decision, not a step. If work stalls because an approval sits with someone who is unavailable, or because two functions disagree about priority, no column limit will help. The board will make the delay visible, which is useful, but the fix belongs to the operating model, not to the workflow.
Work with MASSIVUE
MASSIVUE works with enterprises on AI transformation and AI workforce transformation, where this pattern recurs with unusual consistency: tools are deployed, individual satisfaction rises, and delivery to the customer does not measurably improve. The cause is rarely the tooling. It is that the delivery system was designed around a constraint that has since moved, and no one has re-drawn it.
Two MASSIVUE Academy micro-credentials cover this ground directly. AI-Powered Program & Delivery Management covers using AI in delivery without fooling yourself about the productivity gains, which is exactly the gap between perceived and measured speed described above. Pragmatic Product Ownership is aimed at the managers and sponsors who set the authority boundary product owners work inside, which matters here because a work in progress limit fails wherever work can be injected around it.
Related reading: Kanban Metrics: The Four Flow Metrics That Predict Delivery, DevOps Metrics in 2026, and What Is an AI Operating Model?.
Frequently asked questions
Does Kanban still work when AI writes the code?
Yes. Kanban manages the flow of work through a system, and AI changed the speed of one step in that system rather than removing the need to manage it. DORA's 2025 research found AI adoption is associated with higher delivery throughput and lower delivery stability at the same time, which is a flow problem rather than a tooling problem. DORA's own guidance on working in small batches, one of the seven capabilities it identifies as amplifying AI's impact, recommends using Kanban-style boards with explicit work in progress limits to make bottlenecks visible. What needs to change is the placement of those limits, which usually belong on review and verification rather than on building.
Do work in progress limits still make sense if AI can produce work instantly?
They make more sense, not less. A work in progress limit constrains the system, not the individual, and its purpose is to stop work accumulating in front of the slowest step. When generation gets faster and review does not, unlimited starting simply builds a longer queue before review. The limit should be set against the capacity to verify work, since that is what determines how much can genuinely be finished.
Which column should carry the tightest limit?
Whichever step is currently the constraint, which for teams using AI heavily is usually review, testing or approval rather than building. A practical test is to compare how many items the team can start in a week against how many it can honestly verify in a week. If the first number is larger, the binding limit is in the wrong column.
Is Kanban or Scrum better suited to AI assisted delivery?
Neither is inherently better, but they fail differently. Scrum's sprint boundary provides a natural batch limit, which is useful given that generated changes tend to arrive large. Kanban gives finer control over where work accumulates, which matters when the constraint sits inside the workflow rather than at its boundary. Both depend on the same underlying disciplines: small batches, explicit policies and real verification capacity.
How do we know review has become the bottleneck?
Measure work item age separately for each review state and watch whether it trends upward while throughput stays flat or rises. That combination means items are entering faster than they are being cleared. Individual reports of feeling faster while delivery dates do not improve is a supporting signal, though a soft one, since DORA found more than 80% of professionals believe AI has increased their productivity regardless of measured delivery outcomes.
Does this apply outside software teams?
The published evidence is strongest for software delivery, since that is what DORA measures. The underlying mechanism is not software specific: wherever AI produces a first draft that a human remains accountable for, generation gets cheaper while verification and accountability do not, and the constraint moves downstream. Teams doing contract review, credit assessment, reporting or analysis encounter the same pattern, though they should treat the cross-domain claim as a reasonable inference rather than a measured finding.