Most enterprises have already added AI to their engineering workflows, but only few can explain what it’s actually doing for them. That gap between AI adoption and AI impact is the defining challenge of software delivery in 2026 and beyond. And closing it requires a data-driven approach.
The adoption trap
When AI tools become available, the default move of many companies is to roll them out broadly and let teams self-organise. The logic behind it is that engineers who have powerful tools will inevitably achieve better productivity.
But that assumption breaks down quickly in practice. Teams pick up tools differently. While some workflows achieve meaningful gains, others see friction. And without a structured approach to measuring impact, organisations end up with a patchwork of adoption – some teams winning, others spinning their wheels, and nobody is sure which is which.
This is not just an internal observation. Gartner warns that rolling out AI across the software delivery lifecycle doesn’t automatically translate into results. The Magic Quadrant for AI Code Assistants report claims that adoption can stall quickly, with often less than half, and sometimes fewer than a third, of purchased licenses seeing active use after several months. The same report finds that outcomes are frequently incremental: 42% of engineering staff report productivity gains of only 1%-10% from AI tools, while 12% report no gains at all.
A structured investigation* we’ve conducted across a large enterprise retailer’s engineering organisation exposed exactly this pattern. The client had already introduced AI tools into their software delivery lifecycle (SDLC) but the results were inconsistent and difficult to measure. Leadership couldn’t answer basic questions: Where is AI actually working? Which tools are delivering value? And how much efficiency are we leaving on the table? Analysing data is essential to find the answers.
AI impact is not universal
The first thing rigorous measurement reveals is that AI doesn’t deliver evenly across the SDLC. Different stages respond very differently to AI assistance, and the distribution of gains is not what most organisations expect.
In our research – covering requirements, system design, development, and testing and QA – the variance across stages was dramatic:
- Testing and QA showed the single largest performance gap between advanced AI tooling and the client’s existing tools: an 8x difference in relative impact.
- Development had the highest raw efficiency gain from advanced tools: 22.6% improvement on targeted tasks.
- Requirements remained the least impacted stage, showing modest returns regardless of tooling.[Text Wrapping Break]
Task-level findings were equally striking. Requirements analysis became 50% faster with the right tools. Test planning and release validation accelerated by 70%. Feature development improved by 30%, code generation by 40%.
These gains only became visible – and actionable – because the investigation was designed to find them. Without that structure, they would have stayed buried in anecdotal feedback and gut estimates.
Tools make a difference
The second major finding is that the tools themselves matter far more than organisations typically acknowledge.
When we compared the client’s existing AI tools against a set of advanced, externally validated alternatives, the performance gap was significant. Advanced tools delivered 20–30% overall efficiency improvement across the SDLC. The client’s existing toolset produced 11.43%.
That’s a 1.7x to 2.6x difference in outcomes from tooling choices alone — not from process changes, not from retraining teams or restructuring workflows. Just from using more capable tools in the right places.
Independent research confirms that AI tool selection is a critical driver of these outcomes. Gartner’s Magic Quadrant for AI Code Assistants report claims that organisations cannot treat AI tooling as interchangeable. The specific tools chosen, and how they are applied across the SDLC, directly shape the results an organisation achieves.
This has direct implications for how technology leaders think about AI investment. The question isn’t whether to invest in AI; most organisations have already answered that. The question is whether the specific tools being used have been validated against real delivery data or just adopted because they were available, familiar, or already licensed.
Bottlenecks kill gains you never see
Perhaps the most counterintuitive insight from this work is about how SDLC efficiency actually compounds. It’s tempting to add up efficiency improvements step by step: 30% faster development here, 40% faster testing there, total gains equal the sum. That maths is wrong.
SDLC performance is a system, and systems are governed by their weakest links. A 22% gain in development means less if requirements are slow, because fast-moving dev teams will queue up waiting for inputs. Strong testing automation matters less if code review is a bottleneck upstream.
This is why isolated efficiency metrics mislead. Organisations can report impressive task-level gains while overall delivery velocity barely moves because the gains are concentrated in stages that weren’t the real constraint.
A system-wide view changes how you prioritise AI investment. Instead of asking “where can AI help most in theory?”, the right question becomes “which stage is currently constraining our end-to-end throughput and can AI address that specifically?”
That’s a harder question to answer. It requires instrumentation, honest baseline measurement, and cross-functional visibility into the full delivery chain. It’s also the question that leads to real outcomes.
The case for measuring first
What we can say for sure so far is that AI will keep developing, new tools will keep emerging, and the competitive pressure will keep intensifying. But it’s important to remember that the speed of adoption is a different variable than quality of adoption. Organisations that rush to scale AI without measuring its impact first will scale inefficiency as readily as they scale productivity.
The smarter move is to treat AI implementation the same way high-performing engineering organisations treat any other system change: instrument it, measure it, understand what’s actually happening, and then scale what works.
The data on where AI helps most already exists inside your own delivery workflows. You just have to go looking for it.
*The findings discussed in this article are drawn from a structured AI efficiency investigation Intellias conducted for a large enterprise retailer in the UK, spanning the full software development lifecycle across frontend, backend, QA, DevOps, and management teams.
