AI won’t fix your bottleneck – it will move it

AI does not remove bottlenecks. It moves them.

AI does not remove bottlenecks from software development. It moves them, and increasingly it moves them outside the organization’s own sphere of influence.

According to the 2025 report by DORA, Google’s DevOps Research and Assessment program, AI use in software development is now nearly universal, but its benefits are uneven and mostly local (see note A). Where it is used, it is concentrated in development teams and their technical practices: coding, testing and CI/CD pipelines. This makes implementing software faster. On its own, it does not produce sustained business benefits, and pursued without thought it can create problems that are harder to solve than the ones it removed.

We have seen a version of this before. When agile methods entered software development over 20 years ago, the focus was, quite naturally, on individual teams. It took years of learning before organizations knew how to coordinate many teams and extend agility across the whole value stream. Scaling agile also often went wrong: frameworks imposed top-down, ceremonies copied without understanding, organizations "doing agile" without becoming agile. AI adoption is now at the same team-centric stage, and it invites the same failure modes.

The paper has three parts:

• Part I is a thought experiment that looks back from an imagined future in which implementing software has been handed over to AI.

• Part II returns to the present, shows the early signs of that future and identifies what really went wrong.

• Part III sets out the response: three lead insights for scaling AI deliberately, all the way to the customer.

What follows is a thought experiment, not a prediction. It is told in the past tense, from a future in which implementing software has been handed over to AI.

What happened?

After the first years of trial and error, organizations found out what really worked with AI. The technology was of course at the heart of it, but what really mattered was how people aligned around reimagined workflows that AI finally gave a proper push. AI stopped being an assistant and became a central element, built into the value streams the organizations had meticulously mapped and redesigned. Whole value streams, not just individual parts of them. This was the breakthrough that opened the floodgates of value creation.

With AI at the center, people saw agile ways of working in a new light. Agile had always been about focus, managing the whole in small pieces, and learning. Now they saw that it had also been about managing people's cognitive load and capacity. AI has neither limit, which raised a fundamental question: why plan two weeks ahead, let alone three months?

So organizations began to dismantle the very structures that had enabled them to deliver in the days before AI. Agents worked in succession, and the whole development process came to be seen as a hyperfast waterfall: a software factory, with AI agents on the production line. After each feature or task was completed, what was left for humans was to verify the outcomes. Fast delivery with fewer people was now the much-coveted reality.

Who thrived and who struggled

Two things decided how an organization fared: how much change its customers could absorb, and how much of its value chain it owned.

• The winners were organizations whose customers could take in change quickly and whose delivery depended on no one else, typically builders of infrastructure and platforms consumed by other systems through stable interfaces. A platform does not suffer from cognitive overload.

• The organizations that struggled built software for people, or depended on partners and vendors to deliver, and many did both. Even they gained something: fixes and quality improvements could ship as fast as AI produced them, because they asked nothing of users. New features were another matter.

Using the 2×2 today

The scenario is fiction, but the 2×2 works as a practical tool today. Place each value stream, not the whole company, in a quadrant: a platform team and a consumer product in the same organization can sit in different corners. Then place your AI bets accordingly.

Why the human-facing organizations struggled

The organizations that dismantled their cadences did so because AI does'nt get overloaded. But humans had not left the system. They had moved to its edges, and the cognitive load moved with them. 

All was not always running smoothly in the factory

There were numerous incidents when something unexpected happened, and the outcomes were not pretty. There were occasions of night-time production failures (the factories worked 24/7) that turned into frantic attempts by on-call engineers to fix problems, none of whom actually understood how the system worked. Only gradually did the organizations begin to see the crux of the problem: as the programmers were assigned as verifiers, they slowly but steadily lost their understanding of the systems they were working with, and with it the ability to diagnose what had gone wrong.

The warehouse

Some organizations found themselves with an immense number of finished features they could not release. They had cost time, money and tokens, and nothing guaranteed they would still be valuable when their moment came.

• Lean thinking has a name for this: inventory, one of the classic wastes described by Liker in The Toyota Way. The software factory had learned to produce faster than its market could take delivery, and like any factory in that position, it filled its warehouse. The warehouse was full of features, not fixes: fixes asked nothing of users and had shipped as soon as they were ready.

• Feature flags (switches that turn a feature on or off without a new deployment) and dark launches (shipping code to production while keeping it hidden from users) did not solve the problem. A feature deployed but not released is still inventory. It earns its keep only when it is used to learn something, for example in an experiment with real users. Otherwise it waits, ages, and adds to the code that has to be maintained.

What was actually learned

AI removed the bottlenecks from the development process, and moved them outside the organization's own sphere of influence.

The structures the organizations had dismantled had not only compensated for human limits inside the development team. They had also kept delivery in step with what users, partners and the organization itself could absorb. Once the cadence was gone, nothing set the pace any more except the speed of the machines.

The future in Part I is not here yet, but its early signs are. Understanding what went wrong in the story is the key to avoiding it.

The bottleneck is already moving

Product development is a system, and a system's throughput is set by its constraint. Speeding up a step that is not the constraint does not speed up the system; it only piles up work in front of the next step. This is the core lesson of Goldratt's Theory of Constraints.

When AI accelerates coding alone, the constraint first moves elsewhere inside the organization: to refinement and decisions, to review and testing, and to integration and release. Then, as Part I imagined, it moves outside, to users, partners and vendors.

The evidence so far points the same way

The 2024 DORA report found that higher AI adoption was associated with a slight decrease in delivery throughput (about 1.5% per 25% increase in adoption) and a larger decrease in delivery stability (about 7.2%). The 2025 DORA report shows a shift: AI adoption is now associated with higher delivery throughput, but still with increasing instability, and the report found no evidence that the extra speed offsets the harm. It describes AI as an amplifier: without strong foundations, AI “creates localized pockets of productivity that are often lost to downstream chaos.”

A 2025 randomized study by METR found that experienced open-source developers took about 19% longer to complete tasks with AI tools, while believing they had been faster. A follow-up published by METR in early 2026 pointed the other way: developers from the original study were about 18% faster with AI, and newly recruited developers about 4% faster.

The authors call this very weak evidence, mainly because many developers no longer wanted to work without AI at all, which they believe biases the estimate downward. AI's effect on individual task speed is real but still uncertain. And even where individuals get faster, the DORA findings show that system-level delivery does not automatically follow: faster individual output is not the same as faster value delivery.

The evidence for the internal shift is solid. For the external shift, to customers and partners, it is still emerging, which is why the scenario in Part I matters: it shows where the trend leads if nothing changes.

What really went wrong in the story

It is tempting to read Part I as a warning against building AI into value streams. That would be the wrong lesson. Integrating AI across whole value streams was the breakthrough, and it is what Part III recommends. Four other things went wrong.

1. The value streams stopped at deployment. Customer adoption, learning and everything that depended on partners and vendors were left out of the redesign.

2. The cadences were dismantled on a false assumption. They did not only manage developer capacity; they also kept delivery in step with users, partners and decision-makers.

3. Local speed was mistaken for flow. Output per team was measured, while the real constraints, the users absorbing change and the humans verifying AI's work, went unmanaged.

4. Removing humans from routine work also removed their understanding of the system. This is the software equivalent of the magenta line story in the box below, and a risk that Bainbridge and Naur described decades ago.

What agile was really for

The scenario's insight about agile deserves to be taken seriously. Agile ways of working did manage people's cognitive load and capacity. But they also served two purposes that AI does not remove: aligning work with the people who receive it, and creating short loops for learning from real users.

That gives a practical test for every ritual and cadence an organization has. If it exists only to protect developers' capacity, AI may well make it obsolete. If it aligns delivery with customers, partners and decision-makers, or creates a learning loop, it must stay, even if its form changes.

Agile's history offers a second lesson. The most common failure in scaling agile was copying structures without understanding their purpose. Dismantling them without understanding their purpose, as the organizations in Part I did, is the same mistake in reverse.

We see three lead insights in the response. Each answers a problem from Part I, and together they reframe what speed is for: the goal is faster learning and more value, not faster delivery as such. Speed is welcome wherever it gets you there.

• Lead insight 1: Slice vertically, all the way to the customer. Adopt AI one value stream at a time, and validate outcomes at the customer, not at deployment.

• Lead insight 2: Speed where it counts. Spend AI-driven speed where customers can absorb it and where it shortens the path to learning. Elsewhere, build less and decide better.

• Lead insight 3: Keep people flying. Treat verification and skills as real work, so people keep the understanding they need when the factory surprises them.

The table shows where each problem from Part I is answered.

A shared model: three layers and the full loop

Product development in any organization of meaningful size runs on three layers. The model is adapted from the Scaled Agile Framework (SAFe), but the same layers exist in LeSS, a product operating model or a home-grown setup.

The layers sit inside a larger loop, and this is where the organizations in Part I went wrong. Decisions flow down as priorities. Delivered outcomes, operational data and customer feedback flow back up to shape the next decisions. Around all of it sits the ecosystem: the customers who must absorb change, and the partners, suppliers and vendors the organization depends on. A value stream does not end at deployment. It ends when the customer has adopted the change and the organization has learned whether it created value.

All three layers, and the ecosystem around them, must work together: gains in one part are capped by the part left behind. The layers can run at different rhythms, as long as those rhythms are aligned.

A value stream does not end at deployment. It ends when the customer has adopted the change.

Do not roll AI out layer by layer, or across the whole organization at once. Adopt it one value stream at a time, through every layer that stream touches, and all the way to the customer.

The team level is a convenient and manageable starting point, much as Scrum was for agile adoptions. But a horizontal rollout, where every team adopts the same tools, runs straight into the moving bottleneck.

The real litmus test is vertical. Choose a value stream with a clear trigger and a validated outcome, and redesign it end to end with AI. The outcome is validated at the customer, not at deployment: that single rule separates this approach from the hyperfast waterfall. Working vertically also shows how processes, roles, handoffs and partner arrangements must change, not just which tools to add. The 2025 DORA report supports this: it found that value stream management, the practice of visualizing and improving the flow of work from idea to customer, acts as a force multiplier for AI, turning local productivity gains into team and product performance.

The first slice is deliberately contained; the second is the one that tests the thesis.

1. Start with a contained stream. Defect fixing is a good candidate: a defined trigger (a reported defect), a clear end (the customer confirms the fix) and flow that is easy to measure. It keeps the risk low while the organization learns.

2. Then take one idea to outcome. Follow a single opportunity from portfolio screening through delivery to measured customer adoption, including the partners it depends on. This tests whether AI improves decisions, coordination and adoption, not just implementation.

3. Expand slice by slice. Reuse what worked, retire what did not, and let each slice inform the next.

Speed is welcome, but it is not the goal. The faster AI makes delivery, the more the limit shifts to how much change customers can absorb. Cadence is how an organization stays in step with that limit, and spends its speed where it creates value.

Customers' capacity to learn, adopt and benefit from new features sets a ceiling on how often an organization can usefully release. Where customers are other systems behind stable interfaces, the ceiling is high. Where customers are people, it is much lower for new features, as it is wherever installed equipment, regulators and partners are involved. The 2×2 in Part I shows where AI-driven speed pays off and where it only fills the warehouse.

Five principles follow.

1. Keep the cadences that serve the edges. Apply the test from Part II to every cadence and ritual. Retire what only managed developer capacity. Keep, and possibly redesign, what aligns delivery with users, partners and decision-makers, and what creates learning loops.

2. Not all change costs the same to absorb. Fixes and performance improvements ask almost nothing of users and can ship at the pace AI allows. New features, and changes to how the product works, ask users to learn, and must ship at the users' cadence. Speed on quality benefits users at once; it pays the organization back more indirectly, through retention, satisfaction and lower support costs. Live-service games show a third option: they design the cadence of new content, in seasons and events, as part of the product itself.

3. Separate deployment from release, but do not mistake it for value. Customer absorption limits how often change is released, not how often it is deployed. With feature flags and progressive delivery, teams can deploy continuously and release at the pace customers can handle. But remember the warehouse: a feature deployed but not released is still inventory. Deploying early pays off only when it is used to learn, through experiments with real users, for example.

4. Optimize for speed of learning, not speed of shipping. Faster cycles mean more experiments, and more experiments mean more innovation. Speed and innovation are not alternatives; speed is worth having when it shortens the path from a hypothesis to evidence.

5. Build less, decide better. When AI makes building cheap, the main risk is no longer slow delivery but bloat: more features than customers want or can use. The scarce capabilities become deciding what to build and learning what worked. Product discipline, including the ability to say no, matters more than ever.

The organization's position on the 2×2 should guide where its AI effort goes. Where speed creates real advantage, automate as much of the delivery flow as possible. Where it does not, focus AI on quality, discovery and deciding what to build; the box “Using the 2×2 today” in Part I gives guidance for each quadrant.

In Part I, verification was what was "left for humans", and understanding quietly eroded. In practice, verification becomes one of the most demanding jobs in an AI-driven organization. The need is already visible: in the 2025 DORA report, 30% of respondents said they have little or no trust in the code AI generates. Verification, and the skills behind it, have to be designed rather than left over. The actions below fall into three groups: verifying the work, choosing the level of autonomy, and keeping skills alive.

• Plan capacity for it. If AI multiplies output, the capacity to review, test and accept that output must grow too, or it becomes the new constraint.

• Shift verification left and automate what can be automated. Clear acceptance criteria, automated tests and policy checks written before AI generates the work reduce what humans must inspect afterwards.

• Make accountability explicit. Someone must own each change that reaches customers, including changes nobody wrote by hand. Decide who that is before an incident forces the question.

• Protect the verifiers' cognitive load. Review fatigue is the cognitive overload Part I thought AI had removed, moved to a new place. Smaller batches and a sustainable pace apply to reviewers as much as they once applied to developers.

• Choose the right level of AI autonomy per task, and keep the ability to step down from it. As in aviation, avoid excessive reliance on automation, and create playbooks for the unexpected, including which level of automation to use, much like the checklists pilots follow when something abnormal happens.

• Keep skills current. Set aside time for building and debugging by hand, and run recurrent training, such as incident days where people practise handling the unexpected, and hackathons without AI.

• Grow juniors deliberately. Set up apprenticeships in which juniors write and debug real code by hand under mentoring, and review AI output alongside seniors.

Supporting practices

Three further practices make the lead insights work.

1. Apply AI at every layer

At every layer, AI is most valuable as an amplifier of human judgment, not a replacement for it.

Two cautions keep this honest.

• Public models give consensus answers: if every competitor asks the same models the same questions, they all find the same "gaps in the market", so advantage comes from combining AI with proprietary data such as customer interviews, product telemetry and support conversations.

• And AI does not make metrics accurate: sound data pipelines do, and language models remain unreliable with raw numbers.

2. Integrate partners deliberately

When the bottleneck moves outside the organization, it has to be managed as part of the value stream rather than left as someone else's problem.

• Map the external dependencies of each value stream. For every slice, name the vendors, suppliers and partners it depends on, and how fast each of them can move. This is often the first time an organization sees how much of its delivery speed it actually controls.

• Decide deliberately what to own. Value chain ownership becomes a strategic question. Bringing a critical capability in-house, or choosing partners who can work at the new pace, may create more value than any further internal acceleration.

• Help customers absorb change. Onboarding, in-product guidance and well-timed communication raise the ceiling on how much change customers can take in. AI can help here too.

With AI accelerating internal delivery, vendors like these become the pace-setters. The case illustrates a principle, vendor integration, rather than an AI result. It is the first of three levels of partner integration:

• Transparency. Shared planning and agreed practices, as in the case above, make partners' work visible but give no control over how they work internally.

• Integration. Partners become part of the organization's own system. Toyota is the classic example: as Liker and Choi describe in Harvard Business Review, it develops its suppliers over the long term and involves them in joint improvement work.

• Ownership. Critical capabilities are brought in-house, giving full control over their pace.

Each level gives more control over the pace of delivery, and each costs more than the one before. Which level is right depends on how critical the dependency is: the question of deciding deliberately what to own.

3. Build the foundations beyond tools

Scaling agile turned out to be mostly about people and organization, not practices. Scaling AI will be no different.

• Roles. Product owners, architects, Scrum Masters and managers will all see their work change, and organizations need a deliberate answer for how people grow. Reinvest the efficiency gains in people’s capabilities, such as verification, discovery and skills, rather than taking them as headcount reductions, which would remove the understanding the organization needs when the factory surprises it.

• Team structures. If AI changes how much a team can deliver, team size, team boundaries and the split of responsibilities may need rethinking too.

• Data and context. AI at the portfolio and product layers is only as good as the data and organizational knowledge it can reach. For many organizations this, not the tools, is the real blocker.

• Governance and risk. Security, intellectual property, data protection and accountability for AI-assisted decisions need clear rules. In the EU, the obligations of the AI Act are being phased in and must be factored in according to the European Commission’s implementation timeline.

• Quality, debt and legacy. More code, written faster, means more to review and maintain. Legacy systems and accumulated technical debt limit how far any vertical slice can go.

• Measurement. Track outcomes and flow, such as lead time, the DORA metrics and customer outcomes. Do not measure AI usage, the volume of AI-generated code or the number of features shipped; they say nothing about value, and in Part I they are what filled the warehouse. For each slice, agree a baseline and a few outcome measures before starting, for example lead time, change failure rate and customer adoption, so that its business case is decided by evidence.

Part I ended with organizations whose bottlenecks had escaped beyond their reach. It could have gone differently.

After the first years of trial and error, some organizations built AI into their value streams, and drew those value streams all the way to their customers. Before dismantling any structure, they asked what it was for. They retired the rituals that only managed developer capacity and kept the rhythms that kept them in step with users, partners and their own decision-makers. They mapped who set their pace, and brought those partners into the work. They treated verification as a craft, not a leftover. They measured what customers gained, not what the factory produced, and so their warehouse stayed small. And finally, they kept their people flying by hand often enough to take the controls when the factory surprised them. 

The bottleneck still moved. It always does. But these organizations saw it coming, and they followed it.

It took the software industry years to learn how to scale agile, and many learned the hard way. With AI, we have the chance to learn faster, by remembering what that experience taught: understand what your structures are for, follow the value stream all the way to the customer, and change the way of working rather than just adding tools.

For CTOs, heads of product and product development, and transformation leads, the first steps are concrete:

1. Place your organization on the 2×2 to see where AI-driven speed will pay off.

2. Choose one value stream and map it all the way to the customer, partners included.

3. .. and before automating it, decide how your people will keep the understanding they will need when the factory surprises them.

The bottleneck still moved. It always does. But these organizations saw it coming, and they followed it.

Four steps to implemenging AI

At Eficode, we approach the implementation of AI in four main steps. Before you start, place yourself on the 2×2 framework discussed above (see “Using the 2×2 today” in Part I), since this shapes where AI will benefit you most. The process, the content of each step and examples of our services in each step of the way are listed in the table below.

How the paper’s first steps map to the process: placing yourself on the 2×2 and choosing your first value stream belong to Envision. Protecting your people’s understanding of the system starts in Automate, becomes critical in Integrate as agents take over more of the lifecycle, and is built into roles, skills and training in Reinvent. The staged path maps to the same process: team-level proficiency and the first vertical slice happen in Envision and Automate, taking an idea to customer outcome is where Integrate begins, and organization-wide practice is the goal of Reinvent.

Sources

1. DORA (2025). State of AI-assisted Software Development (accessed 13.10.2026)

2. Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer. McGraw Hill. ISBN 978-0071392310.

3. Goldratt, E. M. (1990). Theory of Constraints. North River Press. ISBN 978-0884271666 (1999 edition).

4. DORA (2024). Accelerate State of DevOps Report 2024 (accessed 13.10.2026)

5. METR (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity (accessed 16.10.2026)

6. METR (2026). Uplift update, 24 February 2026 (accessed 16.10.2026)

7. Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779.

8. Naur, P. (1985). Programming as theory building. Microprocessing and Microprogramming, 15(5), 253–261.

9. FAA (2013). Safety Alert for Operators SAFO 13002: Manual Flight Operations, 4 January 2013. US Federal Aviation Administration (accessed 3.11.2026)

10. PARC/CAST (2013). Operational Use of Flight Path Management Systems, Final Report, 5 September 2013. PARC/CAST Flight Deck Automation Working Group. (accessed 3.11.2026)

11. DOT OIG (2016). Enhanced FAA Oversight Could Reduce Hazards Associated With Increased Use of Flight Deck Automation, Report AV-2016-013, 7 January 2016. US Department of Transportation, Office of Inspector General. (accessed 3.11.2026)

12. Kosmyna, N. et al. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. arXiv preprint (accessed 19.10.2026)

13. Liker, J. K. & Choi, T. Y. (2004). Building deep supplier relationships. Harvard Business Review, 82(12), 104–113.

14. European Commission (n.d.). Timeline for the implementation of the EU AI Act (accessed 16.10.2026)

15. Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley. ISBN 978-0321150783.