Why AI tools fail to speed up software delivery (and how to fix it)

Hosting recent episodes of our DevOps Sauna podcast, my colleagues and I noticed an identical pattern across enterprise engineering teams: AI will not transform your organization. It amplifies whatever already exists in your software delivery lifecycle: the goals, the handovers, the governance, and the incentives. Clear goals get amplified. So does confusion.

That means a transformation works in a particular order:

1. Start from a clear why.

2. Measure where you stand.

3. Change how work flows.

4. Only then choose the tools.

Here is what that looks like in practice.

Why are we doing this? Start with a goal, not a tool

Nobody should be aiming to just implement AI or DevOps. In our podcast episode on why digital transformations fail, Jess Fraser-Darling and I broke down why teams mistake a destination for a vehicle. Tools and frameworks are how you get somewhere. They are not the place you are trying to reach.

“Everyone else is doing it” is an understandable reaction to market pressure, but it is not a measurable goal. Jess and I advise asking what you are really after: faster feedback loops, shorter lead times, or more capacity to innovate. Scrum, SAFe, or AI must serve that specific goal.

Two things follow from a clear why:

• A baseline. If you do not measure before you change, you end up justifying results afterward with numbers nobody can back up.

• A shared definition of success. Sit down with the executive sponsors and ask: if we succeed, what does that look like in production, and how will we prove it?

It also helps to be clear about what actually changes. Technology is usually just the enabler. The harder parts are how decisions get made, who accesses which information, what gets rewarded, and how governance is structured. If you continue rewarding legacy behavior, you will not get modern delivery speed.

Finally, engineers need agency. Change is much easier to accept when it is not something that happens to you from the top down. A visible senior sponsor combined with teams that actively shape the rollout decides whether adoption actually sticks.

Where do we stand? Implementation is not value

When organizations tell me their AI maturity is high, they usually mean their licenses are provisioned. Our CTO, Marko Klemetti, sees this mix-up constantly. Token consumption tells you almost nothing about the business value you extract.

Every three months since March 2025, we have surveyed our enterprise customers about practical AI adoption across regulated industries. The shift is accelerating:

• In March 2025, 50% of surveyed engineering teams were not using AI for code generation at all. By March 2026, that dropped to 20%, and by June 2026, it reached roughly 12%.

• In requirements management, the share not using AI fell from 80% to below 40% over the exact same period.

Two patterns stand out:

• The gap is widening. Organizations that embed AI practices in one part of delivery quickly expand them into automated testing, security, compliance, and operations. Teams that isolate AI to individual code completion fall behind exponentially.

• The ends of the flow lag. Product management and operational service teams adopt far more slowly. When AI usage remains an isolated personal assistant rather than a pipeline enhancement, delivery speed stays flat.

The critical divider is not how many developer seats you pay for. It is whether your organization is merely speeding up individual tasks or actively dismantling handovers and review gates. The first gives you tiny local gains. The second changes how fast you ship.

A simple test: can your leadership team explain what AI will change in lead time and quality, rather than quoting how many licenses are active? When Marko and I talk with enterprise leaders, the real maturity level surfaces in minutes.

How high should we aim? Optimizing parts won't make you better

Marko often points out that in most enterprise R&D setups, only about 5% of total lead time goes into writing code. Automate all of it and you improve the delivery pipeline by roughly 5%. The remaining 95% is swallowed by prioritization meetings, architectural reviews, manual handovers, compliance gates, and ticket queues.

That is why Marko advocates for the five-minute loop: moving an idea to validated customer value in minutes instead of quarters. It is an operational aspiration, not an overnight mandate. Many of our customers in regulated sectors release quarterly because customer appetite or audit constraints require it. But when you anchor your engineering ambition at five minutes, you start asking sharper questions: Why does security approval take three weeks? Why are routine deployments held for manual change advisory boards? Which steps are compliance mandates, and which are pure habit?

Delivery and release are two different disciplines. With continuous deployment, code reaches production safely behind feature flags without being exposed to end users, turning release into an autonomous business decision.

The threat landscape certainly is not waiting. Marko tracks the Zero Day Clock, which monitors the window between a public vulnerability disclosure and an active exploit. In 2023, that window averaged 53 days. In 2026, it is down to roughly eight hours. If your security approval gate takes weeks, generating code faster simply piles up security risk.

In practice, the biggest bottlenecks sit at the boundaries:

• Security and compliance. Create a shared automated policy between R&D and InfoSec so checks run continuously in the CI pipeline. The final gate becomes an automated pass/fail signal, not a multi-week audit.

• Change approval. Our Field CTO, Kalle Sirkesalo, regularly encounters boards reviewing complex pull requests they cannot evaluate. A modern decision model classifies low-risk automated changes as standard, routing only architectural shifts to human reviewers.

The trap is what Marko calls "legacy AI": bolting generative tools onto broken, siloed processes. Real leverage comes from redesigning the flow of work itself.

You do not need to overhaul your entire enterprise at once. When Volkswagen tackled this, they launched CARIAD to build software for ID vehicles without legacy corporate constraints before feeding those practices back inward. You can do the same on a contained scale: take one service, target a five-minute feedback loop, and run a value stream assessment to see where work stalls.

What should we buy? Needs first, tools last

Only after mapping the workflow does the tool question make sense. Kalle Sirkesalo has guided platform procurement for over a decade, and his sequence is straightforward: identify concrete use cases and non-functional requirements (including data residency and sovereign governance), define necessary capabilities, and evaluate vendor tools against that exact rubric.

Measure before signing contracts. In Kalle’s experience, organizations track tool uptime and seat utilization, but rarely delivery throughput. When AI token usage hits 100%, leadership assumes success, yet cycle times remain identical.

We saw this firsthand with a customer whose metrics revealed that pull requests took two days to resolve. Generating more lines of code with AI assistants would only worsen that backlog, because review was the true bottleneck. Instead of buying more developer seats, they defined baseline metrics first and targeted the bottleneck by piloting an automated code-review agent across beta teams to shorten feedback loops before scaling.

A tooling decision is broader than license counts:

• You buy an entire ecosystem. Maximizing tools like GitHub Copilot requires GitHub Enterprise, identity federation, audit logs, and data governance. That is an enterprise platform choice.

• Lock-in is a conscious trade-off. Deep integration into a single ecosystem offers velocity, while multi-vendor architectures preserve flexibility. Align your tooling with enterprise architecture, not departmental credit cards.

• Change management costs eclipse software costs. If 1,000 developers spend a full day navigating an unplanned tool rollout, that is 1,000 working days burned on friction.

Who makes the call? The CIO manages vendor costs, developers test user experience, and security audits exposure. Kalle recommends that the product or business owner lead the ultimate capability decision, escalating strategic platform consolidations to executive leadership.

Three questions to ask your leadership team

AI will amplify whatever delivery culture already exists. If your handovers are slow and your architecture is coupled, AI simply accelerates the accumulation of unreviewed work.

Take these three questions into your next technical leadership meeting:

1. What is our why? Which business metric (lead time, deployment frequency, failure rate) are we trying to impact, and who sponsors the outcome?

2. Where do we stand, backed by data? What is our baseline cycle time today, and how will we verify that AI tooling moved the needle?

3. Which flow are we modernizing? Where are the manual approvals, ticket handoffs, and compliance checkpoints that AI will expose?

If you need an objective baseline of your pipeline before adding more tooling seats, our AI maturity assessment benchmarks your delivery flow and gives you a concrete roadmap for what to fix first.