AI is rewriting DevOps faster than most pipelines can review it

On 30 September 2026, heise online published an analysis of how artificial intelligence is reshaping DevOps practice, built around the DORA AI Capabilities Model (heise online, 30 September 2026). DORA here is the DevOps Research and Assessment programme, the research body behind the annual State of DevOps report, not the EU's Digital Operational Resilience Act, though the name collision is worth sitting with for a moment, because both are about the same underlying question: can an organisation prove its systems are under control.

The heise piece makes a specific claim: AI assistance has pushed code generation ahead of code review. Teams can produce changes faster than any human reviewer, or any existing review process, can absorb them. The article frames this as a bottleneck moving from "shift left" security gates to the review step itself, and it treats the DORA framework as the tool for working out which AI-era practices actually improve delivery performance and which just move the backlog somewhere less visible (heise online, 30 September 2026).

This is not a one-off observation

The review bottleneck shows up wherever anyone has measured it. GitClear's 2025 study of 211 million changed lines of code at major technology companies found that refactoring activity, the work of cleaning up and consolidating code after it is written, fell from roughly 25% of changed lines in 2021 to under 10% by 2024, while duplicated code rose from 8.3% to 12.3% of changed lines over the same period (GitClear, 2025). Code that moved to a better location in the codebase, a proxy for genuine restructuring, is now outnumbered by code that was simply copied and pasted. The volume of code is going up. The housekeeping that used to accompany it is not.

That volume has an obvious driver. The Stack Overflow 2024 Developer Survey found that 63% of professional developers were already using AI tools in their daily work, with a further 14% planning to start (Stack Overflow Developer Survey, 2024; via GitClear, 2025). Adoption at that scale, arriving faster than review processes can adapt, is exactly the gap the DORA AI Capabilities Model was built to measure: not whether teams use AI, but whether using it correlates with faster, safer delivery or just faster delivery (dora.dev, 2026).

Put together, the pattern is not "AI makes DevOps better" or "AI makes DevOps worse." It is that AI decouples the rate of change from the rate of verification, and most pipelines were built assuming those two rates stayed roughly in step.

What it means for a regulated enterprise

For an ordinary software team, a widening gap between code produced and code reviewed is a quality problem. For a financial entity, it is also a legal one, because of the other DORA: the EU's Digital Operational Resilience Act, in force since 17 January 2025, which requires in-scope financial entities to manage ICT risk across their full technology estate, including change management and third-party ICT services. A DevOps pipeline that ships AI-assisted changes faster than it can demonstrate review, testing, and sign-off is not a process shortcut. It is a gap in exactly the ICT risk management record the regulation expects a firm to maintain.

The same exposure reaches outside financial services. The EU AI Act's record-keeping obligations assume an organisation can state what an AI-assisted system did and when. A pipeline where AI tooling writes, suggests, or auto-merges changes faster than anyone logs the decision behind them cannot answer that question when asked, regardless of sector.

What actually addresses it

The DORA research programme's own answer is not to slow adoption but to measure it properly: treat AI-assisted delivery as a capability to be instrumented, not a convenience to be assumed (dora.dev, 2026). That means two things have to be true simultaneously, and most organisations currently only have the first.

The first is throughput: how much AI-assisted change moves through the pipeline. Most teams can already report this, because it shows up as commits, pull requests, and deploy counts.

The second is provenance: for each change, which tool or model proposed it, who reviewed it, what that review actually checked, and what happened after it shipped. This is the part GitClear's data suggests is quietly eroding, refactoring and consolidation are the visible symptom of review effort going down even as volume goes up. Provenance is not a reporting dashboard bolted on afterwards. It has to be a record that exists because the pipeline produced it as a by-product of running, the same way an append-only ledger exists because every action was logged at the point it happened, not reconstructed later from memory.

What to check on Monday

Pick one pipeline where AI-assisted code generation is already in use and ask three questions that do not require buying anything.

First, for the last ten merged changes, can anyone name which were AI-suggested, which human reviewed them, and what the reviewer actually looked at, as opposed to clicking approve. Second, has the team's refactoring or code-consolidation activity moved in the last two quarters, up or down, and does anyone track that metric at all. Third, if a change shipped by an AI-assisted pipeline caused an incident tomorrow, how long would it take to produce the full trail: prompt or tool, suggestion, reviewer, approval, deploy.

If the honest answer to any of these is "we'd have to go and look," that is the gap the heise analysis and the DORA framework are both pointing at. It is cheaper to close before a regulator, an auditor, or an incident forces the question.