The debate about whether AI belongs in software delivery is over, whether or not anyone formally ended it. Surveys cited in Thoughtworks’ recent perspective on AI-first software engineering put developer adoption above 90% — and in our experience the surveys undercount, because even in teams with no official AI policy, the tools are there. Quietly.
Which makes one number from Gartner’s June 2025 survey of software engineering leaders genuinely striking. Asked whether their software delivery processes were ready for AI, 16% said yes. Workforce readiness: 14%. Architecture: 12%. Sit with those figures for a moment. The tools arrived years ahead of the operating model that is supposed to govern them, and the leaders running these organisations know it.
Amplification isn’t improvement
Thoughtworks has a phrase for this that we keep coming back to: generative AI “amplifies indiscriminately”. A well-run delivery organisation — clear requirements, disciplined testing, sane architecture — gets its strengths amplified. A messy one gets its mess amplified, at exactly the same speed.
And the early evidence is not subtle. In a Harness study, around 70% of developers said AI-generated code has increased the time they spend debugging and chasing security issues, and roughly 60% of organisations admitted they have no way of telling whether their AI tools are working at all. GitClear’s analysis of code “churn” — new code that gets reworked almost immediately — shows the same quiet trend. Thoughtworks calls it “death by a thousand paper cuts”, which feels about right. No single AI shortcut hurts you. Ten thousand unreviewed ones will.
None of this argues against AI-first delivery. It argues that the operating model — how work gets specified, reviewed, released, measured and governed — has become the deciding variable. We have watched the same tool compress a task from days to hours in one organisation and quietly generate rework in another. The tool wasn’t the difference.
What “ready” actually looks like
When we sit down with delivery organisations that are getting this right, four things keep showing up. None of them comes in a box.
1. Specification discipline
AI turns vague intent into confident code. Teams that write things down properly before generating get the amplification working for them. Teams that prompt loosely get plausible software that solves the wrong problem, fast.
2. Review that matches the new volume
Your review process was sized for human output. When output multiplies, review has to become risk-based and partly automated. Redesigned, in other words — not abandoned, which is the tempting shortcut.
3. Measurement that sees the whole system
If you cannot see cycle time, rework, defect escape and cost in one view, you genuinely cannot tell whether AI is compounding value or compounding problems. People will bring you anecdotes either way.
4. Boundaries and governance
Clear rules about where AI can act on its own and where a human decision is mandatory — money, personal information, production changes. Here in South Africa, with POPIA in force and financial regulators now surveying AI adoption directly, this has stopped being good practice and started being an expectation.
A delivery programme, not a procurement exercise
Closing the readiness gap is unglamorous work. Baseline honestly, redesign the workflows that will carry the new volume, instrument the results, expand from the evidence. Next to a shiny tool rollout it looks slow — which probably explains why fewer than one in six leaders can claim it’s done. It also explains the opportunity, because the majority bought the tools and skipped the model.
This is, as it happens, the problem OnTrack AI™ was built around: embedding governed AI and delivery intelligence into how teams already plan, build, test and release, so the operating model matures alongside the technology rather than years behind it. If you’re wondering where your own organisation sits relative to that 16%, it’s a useful place to start the conversation.
%402x.svg){kind=icon}
%402x.svg){kind=icon}
