Are you ready?

Every organisation right now wants the same darn thing! To get AI into the hands of engineers and watch productivity climb. As it was put in a recent Yorkshire DevOps meetup - the managers want “AI AI AI”! But sometimes the engineers are pushing back. The pressure is real! But there is a hard truth buried in the research that most people skip past.

AI does not fix a struggling team. It amplifies whatever is already there.

See? That single line is the headline of the 2025 DORA report, Google’s study of software delivery, based on roughly 5,000 respondents and over 100 hours of interviews. Really strong teams get stronger with AI. Teams with a weak foundation get faster at producing the wrong things, less safely. So before you buy Claude licences for everyone, you need to answer one question: where does my team actually stand today?

The uncomfortable finding: speed without stability

The 2025 DORA data shows:

• 90% of respondents now use AI at work, and over 80% say it has boosted their productivity.
• Yet 30% still report little or no trust in AI-generated code.
• AI adoption shows a positive relationship with throughput and product performance, but a negative relationship with software delivery stability.

Teams are shipping more, faster, and breaking more while they do it! The report shows that acceleration exposes weaknesses that were already there. If your automated testing is thin, your version control is loose, or your feedback loops are slow, AI will help you fail sooner. Which is ironically also a DevOps principle borrowed from Lean but we’re not going down that road today!

In The DevOps Handbook, the same argument is made about automation in general: automating a broken process only lets you make mistakes faster and more reliably. AI is automation in full beast mode, so the risk is larger, not smaller.

Two ways to get your baseline

1. The DORA Quick Check

DORA publishes a free Quick Check that scores your team on the four key delivery metrics (deployment frequency, lead time for changes, change failure rate, and failed-deployment recovery time) and shows how you compare to others. It takes a few minutes and gives you an immediate, industry-benchmarked read on your delivery performance. Start here if you want a fast, external reference point.

Those four metrics are not arbitrary. They come out of the years of research written up in Accelerate, which found that these measures reliably separate high performers from the rest. That is the whole reason to start with them: they are the closest thing our industry has to an objective baseline.

2. A DevOps Maturity Model (my tool!)

The Quick Check tells you how fast and safe your delivery is. It does not tell you why, or what to fix first. That gap is exactly why I built the DevOps Maturity Model (DMM).

The DMM is a small, self-hosted web tool that:

• Scores your team across dimensions like Automation, Infrastructure and Culture
• Tracks your progress over time on a graph
• Generates the start of a gap-analysis report so you can plan improvements
• Is fully customisable to your team’s own language and priorities

It runs locally via Docker or NPM, so your data stays with you, and it deliberately avoids the discouraging language of formal performance tiers. The point is to make even basic adoption feel like progress. I wrote about the thinking behind it in more detail in my DevOps Maturity Model post.

One caveat! Accelerate actually argues against maturity models. Forsgren writes that “maturity models are not the appropriate tool to use or mindset to have”, and recommend capability models instead: multidimensional, outcome-focused, and never “finished”. I built the DMM anyway! The reason is practical. During my MSc research I could not find a single practising engineer who used capability modelling in the real world, whereas maturity models were something teams instantly recognised and would actually sit down and engage with. The DMM is my attempt to keep the approachability of a maturity model while still pointing people at the capabilities they need to improve.

Used together, the Quick Check gives you the outcome level and the DMM tells you which practices to work on to move on. That is your readiness baseline.

Turning the baseline into an action list

Your scores point at weak spots. Here is what to do about them. Most of this is ordinary good engineering, not AI.

Secure these foundations first. These are the practices DORA’s research ties to high-performing teams, with fuller explanations at dora.dev/capabilities. Treat the list as a checklist and score yourself honestly. Any item you cannot tick, AI will expose it! Not improve. For example:

• Version control — every change to code and settings is recorded, and any of it can be undone.
• Automated testing — the system checks its own work on every change, so mistakes show up in minutes instead of reaching customers.
• Fast feedback — a broken change is flagged within minutes of being made, not days later.
• Small, frequent releases — teams ship small changes often, rather than large risky ones now and then.
• Automated release and rollback — putting a change live, and pulling it back out, is quick and routine.
• Independent teams — a team can deliver its own work without waiting on several others.

Then two AI-specific moves:

• Write and enforce an AI policy — short, clear rules on what is allowed, what tools are available (via SSO) and block the rest at network level. AI-written code must be reviewed exactly like human-written code. A policy no one enforces is just a suggestion.
• Give AI your own context — connect it to your codebase, documents, knowledge base and standards. Generic AI gives generic answers; your own context is where the value lies.

And one that never changes: product direction stays human. AI speeds up building things. It does not tell you which things are worth building. Oh no no. That still comes from you and your users.

None of this is really about AI anyway. Getting ready for AI and getting good at delivering software are the same job. Fix the weak spots you have flagged, and readiness follows.

Where to start?

If you take one thing from this, let it be the order of operations:

1. Measure. Run the DORA Quick Check and a DevOps Maturity Model assessment. Get an honest baseline.
2. Find your weakest foundation. Usually it is testing, feedback speed, or coupling. Fix that before you scale AI.
3. Write the policy, connect the context, then roll out. In that order.

AI is not a shortcut past the hard work of good engineering. It is a multiplier on top of it. Measure first, and you will know whether that multiplier is working for you or against you.

References and further reading

• 2025 DORA Report — Google Cloud, Announcing the 2025 DORA Report. cloud.google.com and the full report at dora.dev
• Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble, Gene Kim. Amazon
• The DevOps Handbook — Gene Kim, Jez Humble, Patrick Debois, John Willis. Amazon
• Wiring the Winning Organization — Gene Kim, Steven J. Spear. Amazon
• Continuous Delivery — Jez Humble, David Farley. Amazon
• Team Topologies — Matthew Skelton, Manuel Pais. Amazon
• Platform Engineering — Camille Fournier. Amazon
• Strategic Management of Technological Innovation — Melissa A. Schilling. McGraw-Hill. Amazon
• DevOps Maturity Model (DMM) — my open-source assessment tool: gitlab.com/devops-maturity-model
• DORA Quick Check — dora.dev/quickcheck