AI coding boom shifts focus from speed to organisational resilience and robustness

Emerging research reveals that while AI accelerates code generation, the real challenge for software organisations is converting that speed into reliable, stable delivery by strengthening internal processes, reducing hand-offs, and focusing on customer impact.

The clearest pattern in the AI coding boom is no longer that software teams can produce code faster. It is that the pressure has shifted further down the pipeline. DORA’s 2024 research found that a 25% increase in AI adoption was associated with a 1.5% fall in delivery throughput and a 7.2% fall in delivery stability. By 2025, DORA was describing a more nuanced picture: AI could improve throughput, but often at the cost of greater instability unless the surrounding engineering system was sound. Thoughtworks drew the same conclusion in plainer terms, arguing that AI acts as an amplifier of whatever strengths or weaknesses an organisation already has. (dora.dev)

That helps explain why impressive code-generation demos have not translated neatly into faster releases. GitLab argues that coding itself accounts for only about 15% of the work needed to ship software, with the other 85% tied up in review, testing, security scanning, compliance and deployment. In organisations running fragmented toolchains, each hand-off introduces latency, context loss and fresh room for error. DORA’s guidance on working in small batches suggests the old delivery disciplines have become more important, not less, because AI-driven output can enlarge change sets faster than teams can safely absorb them. (about.gitlab.com)

Sonatype’s reading of the problem is that engineering leaders should spend less time celebrating faster code creation and more time identifying where work actually stalls. It points to unclear requirements, dependency delays, failed tests, security remediation, production interruptions and repeated hand-offs as the places where delivery time is really lost. An agent that halves coding time for a feature does not improve much if that feature then sits for days waiting for testing, security review, missing context or deployment approval. The practical question, Sonatype says, is where work routinely waits and where teams are repeatedly forced into rework. (sonatype.com)

That diagnosis also changes what managers should measure. CIO argues that busier repositories and rising pull request volume can create only an illusion of speed, and says leaders should move from asking “how much did we build?” to asking “how reliably does value flow to customers?” Built In makes the same point operationally: measure shipped outcomes and defect rates rather than generated code volume, and judge success through business effects such as conversion, revenue per user, fewer support tickets or lower latency, weighed against the maintenance burden the new code creates. (cio.com)

The emerging playbook is therefore less about finding a magical model and more about imposing constraints around it. Built In says teams should put automated test coverage and CI gates in place before granting agents much autonomy, reserve routine and well-specified work for machines, and keep architecture and security decisions with senior engineers. It also recommends treating verification as a first-class activity, with time explicitly allocated for review and edge-case testing against real production data. In practice, that is close to the approach now taking hold in engineering teams using AI heavily: smaller, reviewable diffs, named reviewers, explicit repository rules and model choices matched to the task rather than one assistant being asked to do everything. (builtin.com)

There is also a human cost if organisations mistake code generation for engineering judgment. Thoughtworks notes that enterprise software bears little resemblance to tightly defined contests such as the ICPC, because real projects are full of ambiguity, unstated requirements and shifting priorities. DORA’s 2024 report adds that unstable priorities reduce productivity and materially increase burnout, even where leadership and documentation are otherwise strong. That matters because AI can remove the friction of typing without building the mental models that come from debugging, design trade-offs and understanding why a system behaves as it does. Faster output can therefore coexist with weaker judgment, especially among less experienced engineers. (thoughtworks.com)

The organisations seeing the best results appear to be those with sturdy foundations already in place. DORA’s platform engineering guidance says high-quality internal platforms can make AI’s effect on organisational performance strongly positive, while low-quality platforms leave the gains negligible. Thoughtworks describes the failure mode as “localized pockets of productivity that are often lost to downstream chaos”. The implication is that the dull work matters most: clear APIs, visible workflows, dependable test suites, clean ownership boundaries and data that lets humans and tools understand the same system state. (dora.dev)

The debate, then, is no longer about whether AI can write useful code. It plainly can. The harder question is whether software organisations can convert that speed into safer, more predictable delivery. The evidence so far suggests they can, but only when they keep batch sizes small, remove blind hand-offs, modernise the toolchain around review and release, and measure customer impact rather than raw activity. Used that way, AI reduces mechanical effort. Used carelessly, it simply manufactures more code for already-constrained teams to review, test, secure and maintain. (dora.dev)