As a reminder: In February 2025, Anthropic released Claude Code as a preview, an agentic CLI tool for developers. General availability followed in May, alongside Claude 4. On 16 April 2025, OpenAI Codex CLI was released as an open-source terminal tool, alongside the o3/o4-mini models. That was less than a year ago.
Since then, large companies have been under a level of pressure I have never experienced before. The tools promise enormous productivity gains, speed and profit. And the promise is not empty; the tools actually deliver. Individual developers are becoming measurably more productive. Pull requests are written faster. Code is produced in minutes rather than days.
The blind spot
Those working in large organisations dealing with standards, governance, compliance or structured process models no longer control the introduction of these tools. They merely accompany the process. The pressure from the business units is too great.
Security measures and best practices built up over years? With the use of CLI agents that work directly in the console, writing code, modifying files and executing commands, many of these measures are suddenly nothing more than a memory. The tools operate beneath the layers of protection we have introduced over the years for our existing tools.
Maintaining this balance between speed and control is a Herculean task. In my professional environment, I observe how it fails in many places.
Screws instead of nails
I know the comparison is a bit hackneyed. Nevertheless, it fits here because it gets to the heart of the problem.
Our developers and architects are handed a powerful toolset. Without sufficient experience. Without sufficient literature on best practices. Without a structured framework that they could have learnt at university, because this framework has only been around for a few months. And how are these tools being used? Exactly like a tradesperson accustomed to working with a hammer and nails uses screws for the first time.
I have followed developments in this field since the very beginning and am an avid user of precisely these tools. In my previous posts, I have highlighted individual aspects: why AI-assisted development requires more planning, who can still check the last 10%, why context is the real problem. What I described there regarding the work of the individual developer also applies to organisations, just on a different scale.
What DORA has found
A research report that I recommend to anyone interested in the topic shows that I am not alone in this assessment: Google’s DORA AI Capabilities Model 2025. Based on qualitative data and survey responses from nearly 5,000 technology professionals worldwide.
The key message, and it is surprisingly blunt in its clarity:
AI is an amplifier. It amplifies the strengths of high-performing organisations and the dysfunctions of weak ones.
“The greatest returns come not from the tools themselves, but from investing in the foundational systems that amplify AI’s benefits.”
Put simply: those who are well-organised become even better with AI. Those who work chaotically produce chaos even faster with AI. The tool alone does not improve anything. It accelerates what is already there.
Seven capabilities, not seven tools
DORA identifies seven capabilities (organisational competencies) that make the difference. None of them is a model or a tool:
Clear AI policy: Uncertainty about which tools are permitted and how they may be used paralyses organisations, either through fear or through uncontrolled proliferation. Both are bad. DORA research shows that organisations with a clear, communicated AI stance achieve measurably better results: greater individual effectiveness, higher throughput, less friction. Organisations without a clear policy? There, the effect of AI on organisational performance is not even statistically detectable.
AI-accessible internal data: Generic AI tools produce generic code. It is only the connection to internal codebases, documentation, style guides and architectural decisions that turns a chatbot into a specialised assistant. DORA describes the transition from prompt engineering to context engineering, and anyone who has read my post on context knows how pleased I am about this.
Small batches: That sounds like something straight out of a textbook. And it is. But the data makes it concrete: AI coding tools tempt developers to generate large amounts of code all at once. The DORA research shows that the discipline of working in small batches amplifies the positive impact of AI on product performance and reduces friction. For those running large batches, the effect of AI on product performance is not demonstrable. An interesting side finding: teams working in small batches report slightly lower individual effectiveness. Breaking things down into small pieces takes time and feels slower. But the products get better.
Strong version control: AI-generated code is not deterministic. Each run can produce different results. Frequent, small commits and the ability to roll back quickly act as a safety net. DORA recommends including AI prompts and agent configuration files (such as CLAUDE.md) in version control. 21% of respondents already do this.
Quality platforms, user-centredness and healthy data ecosystems are the remaining three. Each one deserves its own post. What they have in common: they are not AI-specific measures. These are the same capabilities that have distinguished high-performing teams from mediocre ones for years. AI hasn’t changed that. It has merely made it more visible.
Seven team profiles
One part of the report particularly caught my attention. DORA has identified seven team archetypes from the survey data, ranging from ‘Foundational Challenges’ (10% of respondents, survival mode, high burnout rates) to ‘Constrained by Process’ (17%, stable systems but stifling processes) to ‘Harmonious High-Achievers’ (20%, low friction, high performance across all axes).
The inconvenient truth is that only the top two clusters (Pragmatic Performers and Harmonious High-Achievers, together 40%) are truly in a position to benefit immediately from AI adoption.
My recommendation
My recommendation for companies wishing to roll out AI coding tools on a broad scale is not particularly spectacular. It can be implemented in a matter of days.
Before the tools are rolled out on a large scale, a minimum process model is required. A pragmatic framework tailored to the company’s needs. Which tools are permitted? How is AI-generated code reviewed? What security requirements apply? How large can batches be?
This can be developed in less than a week. Seriously. Not months. Days.
This framework must then be taught. Not as a barrage of PowerPoint slides, but as training in which developers and architects build a basic understanding of the methodology, the possibilities and the security measures to be observed. Even experts have only had the competence to use these tools safely for less than a year. Expecting developers to pick this up on the side is negligent.
AI adoption is not a tool procurement problem. It is an organisational transformation. Anyone who rolls out the tool without considering the processes, training and governance is actually exacerbating the very problems they set out to solve.
What cannot be delegated
The DORA Report concludes with a sentence that I want to include here because it sums up the topic better than I could:
“AI, in and of itself, is not assured to be beneficial. It must be adopted with care.”
AI can transform software development. But only for organisations that are prepared to build the systems, culture and practices in which it can operate. Those who rely on the tool and ignore the organisation will find that speed without stability is nothing more than accelerated chaos.
The DORA AI Capabilities Model Report 2025 is available free of charge. Read it. Every word in it is valuable.