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.