Ai on Mike's Blog

Take Us To Your Leader!

Fri, 24 Jul 2026 09:00:00 +0000

Engineering teams are running a different operating model to before. It isn’t a bunch of engineers any more. It’s a bunch of engineers, each orchestrating a handful of agents. The tooling for this arrived faster than the thinking did, and now we’re all trying to catch up.

Here’s a summary of opinion pieces and academic studies into this brave new world, and where I think the gap still is:

What the evidence says

DORA, State of AI-assisted Software Development 2025 — still the best-grounded starting point despite being from 2025. Nearly 5,000 respondents, and one finding that reframes everything: AI is an amplifier. It magnifies whatever your organisation already is. DORA identified seven capabilities that determine whether that amplification helps or hurts, and the platform one is still the greatest piece of guidance for AI readiness that I have seen anywhere ever — where internal platform quality is high, AI’s effect on organisational performance is strong and positive; where it’s low, the effect is negligible.

Anthropic — the 2026 Agentic Coding Trends Report and the Claude Code documentation — the vendor view (I count Claude as the incumbent in this case). Its Trend 2, “single agents evolve into coordinated teams”, predicts 2026 is the year the single chat thread gives way to one orchestrator coordinating specialised sub-agents — and it states that users require new skills in task decomposition, agent specialisation and coordination protocols, plus version control that can handle simultaneous agent-generated contributions. The docs then say that one human as “team lead” coordinating three to five agent teammates inside a single session, work sized so each teammate owns a different set of files because “two teammates editing the same file leads to overwrites” (for keeping sessions fully apart, they point to a separate technique, git worktrees). All of it, though, is orchestration inside one owner’s control: one team per session, one developer, no sharing a team across sessions. The guidance for running an agent team is genuinely good. There is no guidance on a whole team of developers each running their own agentic robo squad.

Faros AI, The Acceleration Whiplash (2026) — telemetry from 22,000 developers across more than 4,000 teams. Faros state that even though throughput genuinely rose, so did bugs per developer (up 54%), incidents per pull request (up 242.7%), median review time (up 441.5%), and pull requests merging with no review at all (up 31.3%)! Their direct challenge to DORA is that mature DevOps organisations showed the same degradation as everyone else — because their review processes were sized for a lower-throughput world. One caveat I have against their reactive piece to DORA’s approach is that the report doesn’t state how they ensure the teams were definitively “high-performing”. Also “high DORA metrics” scores are not a thing. DORA metrics are not targets. I keep saying **this! That said, they clearly have uncovered an issue in delivery that is still yet to reveal itself. I think I may have some clue to it so keep reading.

HAIF: A Human–AI Integration Framework (Bara, Feb 2026) — the most operationally useful thing I’ve read albeit from a post-deployment perspective. Four rules: every AI output has a named human owner, delegation is a governed and reversible decision, validation is budgeted capacity rather than an afterthought, and human competence is actively maintained through scheduled human-only work. It adds trust tiers where promotion is slow and evidence-based but demotion is instant and anyone can trigger it. Its review principle is three words: “Verify, don’t read.” My reservation is that HAIF is output governance. It’s excellent at checking AI’s homework but doesn’t hit upon guidance and flow. It could even be argued that it hinders flow as we add extra process upon process. But it’s worth reading.

Agile in the Age of AI (Kanban Zone, June 2026) — makes the case that our coordination rituals were tuned for human cadence, and argues for leaning harder on flow: visible work, WIP limits, explicit policies on what “good” means for generated output. It also contains the line I keep coming back to. Humans move from doing the work to deciding, guiding and validating it — and that is “not a reduction in importance, but an elevation of responsibility.”

Where are you now…

So I went looking again for guidance on the part I actually care about: a whole team using AI, not one developer with a fleet of agents. It still isn’t there. What’s online is impressive — orchestration tools like Claude Squad and Conductor, “living specs” that keep agents aligned, branch isolation so parallel agents don’t collide — but every bit of it is engineer-centric. One person conducting many agents. None of it tells a delivery lead how to run a team of humans who each do this against the same trunk.

Which lands me somewhere that might sound old-fashioned: the traditional team disciplines — DevOps and Agile — matter more now, not less. The act of delegating work is the same act it always was. Story points may shrink and sprints get busier; teams may get smaller or their skills shift. But someone still has to own the boundaries, hold the intent, and make the calls no agent can be accountable for. That is delivery leadership and creativity, and no tool ships it.

And that’s why I keep pushing back on treating agents as team members. They aren’t. They don’t self-organise, they can’t change their behaviour after a retro, and they can’t hold accountability. They are capable, fast, occasionally wrong tools working entirely at the direction of the engineers running them — and they break, drift, and get repriced or repositioned by vendors and by our own organisations on timelines nobody on the team controls.

A lot of this was confirmed for me at an “Enabled Day” at Enablis, where we were handed a brief and a single day to turn them into working apps with the help of our old buddy Claude and friends. Nothing highlights issues like a blank page and a deadline. And yes. My team won! Just like Spain.

Are You Actually Ready for AI? Measure to Adopt

Fri, 17 Jul 2026 09:00:00 +0000

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:

Measure. Run the DORA Quick Check and a DevOps Maturity Model assessment. Get an honest baseline.
Find your weakest foundation. Usually it is testing, feedback speed, or coupling. Fix that before you scale AI.
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