You bought the AI tool. Developers are using it. Velocity is up. So why isn't AI improving software delivery the way it's supposed to?
AI doesn't fix a software delivery system on its own. It amplifies whatever process it's already part of. Most organizations adopt AI without redesigning the workflow around it, so the same bottlenecks remain - except now they're hit at AI speed, and the debt accumulates faster too.
The PRs pile up. Review time climbs. Something breaks in a module nobody fully understands. And the question that surfaces isn't "did we pick the wrong tool?" It's something more uncomfortable: did we change anything other than the tool?
McKinsey's 2025 State of AI research makes this structural. Only 21% of organizations using generative AI have redesigned their workflows end-to-end. The other 79% are layering AI on top of processes built for humans. And workflow redesign - not tool selection, not headcount reduction, not prompt engineering - is one of the strongest contributors to real business impact from AI. McKinsey tests dozens of factors. This one consistently sits at the top.
That gap between 21% and 79% isn't about awareness. Most organizations know redesign is needed. Something else is making it undoable.
Why Adding Feels Safer Than Removing
When something goes wrong in a delivery system, the instinctive response is to add a control. A new approval step. An extra review stage. A checklist before the checklist.
Adding is a decision nobody gets fired for. Removing is.
The person responsible for the existing SDLC isn't usually the person who built it. They inherited it, adapted to it, and their teams built around it. The approval gates, the review sequences, the phase checkpoints - they exist for reasons that aren't always visible or documented. Some of those reasons are compliance. Some are risk mitigation. Some are unwritten organizational memory that lives in a process rather than in any person. And some are quieter than that: a pull request review is not just a quality check. It is also where context gets shared - the reviewer learns how the system changed and carries that understanding into the next change. We went deep on what each of those controls was originally designed to prevent in a previous post.
When AI enters that system, the instinct is the same: add a layer around it. Don't disturb the existing structure. Just bolt AI onto the side of the process and see what happens.
The cost of not redesigning is invisible until it isn't. You don't see the operability debt accumulating. You don't see the bottleneck moving. You see it in month three, when the numbers stop making sense.
There's also a genuine fear that removing controls opens the organization to the failures those controls were built to prevent. That fear is legitimate. The answer isn't to remove controls - it's to move them. But that requires understanding the system well enough to know which controls are doing real work and which are artifacts of a different era.
Most organizations haven't done that analysis. So they default to keeping everything and adding more.
A Fool With a Tool
Pick the best AI coding platform. Deploy it to the engineering team. Call it done.
This is the most common version of AI adoption in software delivery right now. The tool selection decision gets made - often at the leadership level, often with genuine care. But the operating model underneath it stays entirely unchanged. Organizations that treat AI as business transformation rather than an IT project achieve a 61% success rate. Those that don't: 18%. And when AI projects do fail, only 23% of failures trace back to the technology itself - the rest are strategy, governance, and change management. The tool gets deployed either way. The transformation only happens in one of those scenarios.
The assumption is that AI works like a new hire. You slot it into an existing role, give it access, and gradually it does the job faster than the person it replaced. The SDLC stays the same. The review stages stay the same. The definition of done stays the same.
But AI agents don't work like new hires. They don't carry context between sessions. They don't absorb the frustrations of the developer three desks over who's been fighting a particular module for two weeks. They don't pick up signals from the hallway conversation about the upcoming architecture decision. Every session starts fresh. What they need to operate well is fundamentally different from what humans need. Most SDLC designs assume human inputs.
When you drop an AI agent into a human-designed process without changing that process, you don't get AI-speed delivery. You get faster code generation feeding into the same bottlenecks - except now the bottlenecks are worse because the volume has increased. We've written about where that bottleneck moves when the top of the pipeline speeds up. The pattern is consistent.
The other piece is that no one has truly solved end-to-end AI-native delivery yet. The tools have focused intensely on a narrow slice of the SDLC: generating and validating code. Everything around that still varies enormously across organizations. How a concept becomes a spec. How a spec becomes a ticket. How a deployed feature gets operated and modified. The tool solved the part that wasn't really the bottleneck. The rest of the system is untouched.
What the 21% Do Differently
The organizations seeing real returns from AI asked a harder question before they started. If this tool works the way it's supposed to, where does our bottleneck move?
That's a systems question. It treats the SDLC not as a fixed sequence of steps but as a system with flows, constraints, and leverage points. When you introduce something that dramatically increases throughput in one part of the system, the whole system responds. The constraint shifts. If you haven't anticipated where it shifts to, you end up surprised by the wrong thing.
The organizations that got this right did the work before the surprise. They looked at their existing SDLC and asked which controls were doing real protective work versus which had grown up around how humans work. They automated the former. They redesigned the latter.
They also changed what "done" means. Instead of measuring velocity - lines of code shipped, PRs merged, tickets closed - they started measuring whether their team could actually own what it had built. That question - can your team own the code AI generated? - turns out to be the right diagnostic.
There's also a correlation worth naming. The organizations navigating AI adoption most successfully are often the ones that actually completed their Agile transformation - or significant parts of it. They already had practices for treating the delivery system as something changeable, for looking at constraints and asking how to relieve them. Introducing AI into a system that's already been examined from the outside is fundamentally different. Introducing it into a system that's never been questioned is a different problem entirely.
The 21% aren't doing something exotic. They're doing what Agile always said to do: treat the process as a system, make it visible, and change it when the work changes. AI just made it impossible to ignore.
Why Isn't AI Improving Software Delivery Yet?
Because the tool changed and the system underneath it didn't. The approval gates, the review sequences, the phase checkpoints - they're all still there, just hit at AI speed now. The 21% who get real returns didn't find a better tool. They found their system's real constraint and redesigned around it.
The Question Before the Next Tool Decision
If your organization is in the 79% - and statistically, it probably is - the issue isn't which AI tool to buy next. It's whether the system those tools will operate in has been designed for what they produce.
The good news is that redesign doesn't have to start with a blank page. It starts with one question: where is the real constraint in our SDLC right now, with AI in the loop? Not in the abstract. In practice. Where is work actually waiting?
Once you can answer that, you can start building a system designed to relieve it. Next week: the four structural shifts that separate teams shipping sustainably from teams accumulating invisible debt - and the order that changes them.
Still in the 79%? The hardest part isn't knowing redesign is needed - it's knowing where to start. In a 30-minute call, we'll help you identify where your SDLC's real constraint sits right now and what one change would have the most impact.
Part of Xodiac's Week 5 series on SDLC Redesign. ← Read Week 4: The four development risks every SDLC was built to prevent