Producing faster is not enough.

The paradox in the figures

Adoption is a given. According to Google Cloud’s DORA 2025 report, now devoted to AI-assisted software development, around 90% of technology professionals use AI in their work, and a large majority believe they gain productivity from it.

Delivery data tell a more nuanced story. For the first time, DORA finds a positive relationship between AI adoption and delivery throughput, reversing the 2024 result. But that same adoption remains associated with greater instability: more failed changes, more rework after deployment.

CircleCI, which analyses its customers’ continuous integration pipelines, provides a direct measure. Its 2026 report, based on more than 28 million workflows, records an average 59% rise in activity, the strongest ever observed in the series. For the median team, however, activity grows by 15% on feature branches and falls by 7% on the main branch, the one that goes to production. The build success rate on that branch drops to 70.8%, its lowest level in more than five years, far from the 90% recommended by CircleCI.

So far more code is being written. Not necessarily more is being delivered.

Where the slowdown sits

A controlled study by the METR lab, published in July 2025, sheds light on the phenomenon at the individual level. Sixteen experienced open source developers carried out 246 real tasks on projects they knew well, with or without AI tools. With AI, they took on average 19% longer. Before the experiment, they expected a 24% gain. Afterwards, they still believed they had been 20% faster.

METR stresses this itself: the result does not generalise to every situation. It concerns developers very familiar with large mature projects, using early-2025 tools. It nonetheless reveals a gap between perception and measurement that appears elsewhere too. Time saved generating is partly lost again reviewing, fixing, integrating and verifying.

This verification cost concentrates downstream. Code review becomes the bottleneck, test suites are called on more often, integration conflicts multiply. Trust also remains limited: according to DORA, around 30% of respondents have little or no trust in AI output. This caution is healthy, but it has a price if the organisation has not planned for the time it requires.

AI amplifies the existing system

The most useful conclusion of the DORA report fits in one word: amplifier. AI strengthens teams that already have good practices and exposes the weaknesses of the others. DORA has also published a model of the capabilities that make AI beneficial. It includes a clear and communicated stance on AI use, healthy and accessible internal data, rigorous version control, working in small batches, a focus on users and a quality internal platform.

None of these capabilities is specific to AI. They are software engineering fundamentals. AI does not replace them. It makes their absence more costly, and more visible. DORA’s report on the return on investment of AI, published in 2026, points the same way by locating the gains in the engineering system rather than in the tools themselves.

What this means for a website or a platform

For a company or an institution, the question is not whether its provider uses AI. It very probably does. The question is what guarantees the quality of what is delivered.

An institutional website or a business platform lives for several years. Code generated quickly will have to be understood, maintained, updated and secured by other people, sometimes by other teams. An inconsistent architecture, dependencies added without thought or components that bypass the conventions of the CMS, whether TYPO3, Statamic or WordPress, create debt that is invisible at launch. It surfaces at the first version upgrade.

Accessibility and security are particularly exposed. A coding assistant readily reproduces the most common patterns, including common and flawed ones: buttons without an accessible name, forms without labels, superfluous dependencies. Without automated checks or informed review, these defects reach production.

A reasonable method

A few principles make it possible to capture the gain without paying the bill later.

• Work in small batches, so that every change stays reviewable and reversible.

• Make automated tests a condition for merging, not an optional step.

• Set explicit rules for AI use: authorised tools, shareable data, level of human review according to how critical the code is.

• Measure delivery rather than output: lead time to production, change failure rate, time to restore, main branch success rate.

• Reserve verification time in planning, instead of treating it as a loss.

These principles do not slow teams down. They keep today’s apparent speed from becoming tomorrow’s real slowness.

Frequently asked questions

Does AI make developers more productive?

The data are mixed. DORA 2025 associates AI adoption with higher throughput, but also with more instability. A controlled study by METR measured experienced developers as 19% slower on projects they knew well. The result depends heavily on the team’s context and practices.

Which indicators should you track?

The DORA metrics (deployment frequency, lead time to production, change failure rate, time to restore) and the main branch success rate, rather than code volume or the number of merge requests.

Should AI be banned from sensitive projects?

Rather, it should be governed: define the authorised tools, the data that may be shared and the level of human review required according to how critical the code is.