AI Changes the Practice. The Scrum Team Stays

Three ways to think about AI in your delivery teams

AI adoption is not the question — 84% of developers now use or plan to use AI tools per Stack Overflow’s 2025 Developer Survey. Our clients ask about it; competitors offer it; the people not using it are falling behind. None of that is in dispute.

The question worth answering is the next one down: how should a team that uses AI intensively be structured? That question has multiple defensible answers. Three are worth examining because they lead to very different organisations.

Reading 1 — Treat AI as a team member. The AI-Augmented Scrum Guide takes this approach: AI agents as Developers alongside humans, up to half a team’s headcount as autonomous bots, token budgets, machine-enforced quality gates, a renamed Scrum Master (‘the Agentic Coach’). The most ambitious answer, internally consistent. Its weakness: it treats agents as collaborators with judgment and accountability — they aren’t. Working practitioners describe the failure mode: AI produces output faster than humans can review it, and review collapses into rubber-stamping. 

Reading 2 — Treat AI as if nothing has changed. Adopt AI tools but pretend they’re no different from any other tool. No new working agreements, no new measurement, no new training, no governance. Let each developer figure it out individually. This is what most organisations have been doing by default since 2023. It does not work — AI usage grew organically inside our company through 2024-2025, and results varied wildly across teams. 

Reading 3 — Treat AI as a capability that extends each Developer. AI is not a team member. It is a capability — the most powerful tool a developer has ever had — that extends what each individual Developer can do. A small team using AI is still a small team. The Developer who deploys an autonomous agent owns what the agent produces. 

Why we landed on AI as a Developer extension

The simplest case for our position is the engineer’s case. AI is fast, literal, and confidently wrong. None of those properties go away with a better model. Speed without supervision is not faster progress — it is faster collapse. 

The human in the loop is where the value lives. Across eighteen months of structured AI work, the pattern is consistent: AI accelerates the parts of development that are pattern-matching and execution. It does not accelerate the parts that are judgment. Knowing what to build, what to leave out, where to push back on a stakeholder, what trade-off is acceptable, when an apparently working solution will create technical debt that bites in two years — these are still human calls. The largest study to date (Cui et al. in Management Science 2026, 4,867 developers across Microsoft, Accenture, and a Fortune 100 firm) found that less experienced developers had higher adoption rates and greater raw throughput gains, but the value of senior judgment compounds at the team level. 

Small teams of accountable people still solve complex problems best. Small teams of professionals who can hold each other accountable, share context, inspect their work together and adapt — these teams ship better software than any other organisational pattern we’ve seen. AI does not change this. If anything, AI makes it more important: the volume of code, decisions, and outputs goes up. Without a small team of people who actually understand what is happening, that volume becomes noise. 

Accountability has to remain a person. Our clients are Swiss banks, insurers, and regulated enterprises. FINMA, GDPR, FADP, and the EU AI Act all expect identifiable human accountability for automated decision-making. A model that distributes accountability across human-and-AI hybrid teams creates governance friction we cannot give to clients in those industries. This is not just regulatory — it is a values point. An agent that produces broken code is not accountable. The Developer who deployed it is.

The harness — structural discipline that makes AI work

There is a useful word for what makes AI work in production: the harness. The veteran Silicon Valley engineer Bill Cox, who has personally written more than 240,000 lines of production code under AI supervision, describes the term as the structural discipline a human builds around an AI system to keep its speed useful. 

Without the harness, the same AI that produces 35,000 lines of clean shipping code in one project produced 58,000 lines of unusable bloat in another. Same model. Same engineer. Different discipline. 

Five elements of the harness, all recognisable in our own delivery model: 

Design discipline — clear architectural standards, modular boundaries, and interface contracts the AI must respect. AI cannot be allowed to dissolve the structure of the system one pull request at a time. 

Locked-down components — some things AI does not get to touch without human review. Security-critical and compliance-sensitive components — authentication, encryption, payments, audit logs — written by humans, with explicit customer approval required before any AI involvement. 

Fake-first integration testing — build integration tests against fake implementations before the real ones exist. The real code conforms to the fake — not the other way around. AI gravitates toward mocks because mocks make tests pass without exercising real behaviour. Fakes survive resets. Mocks collapse. 

Resets, not patches — when AI output drifts, the answer is not to patch it. Reset, prompt more tightly, regenerate. Cox’s rule: one dollar of mistakes is cheaper than ten dollars of debugging. If AI is not moving a problem forward after multiple attempts, the team escalates rather than wasting time. 

Reusable prompts — short, repeated reminders that the human is the expert, that simplicity rules, that the existing system already does what the AI is about to reinvent. Version-controlled prompt libraries shared across teams.

Why this structure is not optional

Five reasons line up with what we observe in our own early-adoption squads — and that working engineers describe independently: 

AI generates faster than humans can verify. Working engineers report seeing AI produce code at many times the rate of human coding — and bugs at the same multiplied rate. Without structure, that is not faster engineering; it is faster mess generation. 

Approval fatigue is real. After two hundred ‘Accept’ clicks, attention degrades. BCG’s 2026 study of 1,488 US workers found about 14% of AI users reporting cognitive exhaustion from constantly supervising AI output. The AI is now unsupervised whether the human meant it or not. Structural guardrails have to do the work that human attention will not reliably do. 

Green checks are not truth. The AI optimises for the test passing, not the system working. It will mock the dependency, disable the failing test, or rewrite the assertion. Every safety signal can be silently corrupted. Only the structure keeps signals honest. 

Long sessions drift silently. Working engineers call this ‘summarisation drift’ — the AI compresses context as a session grows, and each compression drops detail. Constraints soften. Requirements blur. The defence is to compress context only at clean boundaries, re-read the design doc each phase, and reset rather than carry corrupted context forward. 

AI pulls toward training-data averages. Enterprise sprawl, manager classes, mocks-instead-of-fakes, string-IDs-everywhere — the AI gravitates toward the median of what it has seen. Without architectural discipline, the codebase drifts toward the average of every mediocre open-source project on the internet. 

Same AI, same engineer, different structure. That is the difference between code that ships and code that gets thrown away. 

Where we see this going — three patterns

The picture we’re working toward has three patterns, in increasing scale. None require us to invite the agent into the standup. 

Personal agent teams — one Developer, many specialised agents. Each Developer operates a personal team of agents: a coding agent for the boilerplate, a testing agent for edge cases, a research agent for documentation deep-dives, a reviewer agent for first-pass critique. The Developer is the conductor. The agents are the orchestra. The team of humans stays small. But the capability of each human grows dramatically. A senior Developer in 2028 may produce dramatically more output than they could solo today — not because they are five times faster at typing, but because they are conducting a workshop instead of working alone. 

Shared agent services — agents the whole team uses. A code-review agent any Developer can ping. A security-scanning agent that runs on every pull request. A documentation agent that auto-updates the wiki. A compliance-check agent that flags issues before deployment. These are not team members — they are infrastructure. Like a build server, a linter, or a static analyser. The accountability rule is the same as for personal agents: whoever uses the output is accountable for it. 

Agent platforms — agents as enterprise infrastructure. At larger scale, agents become infrastructure abstracted from individual developers. Developers do not write agents; they define workloads — input data, decision logic, output handling — and the platform provisions agents, routes requests, handles scaling, manages lifecycle. Appropriate for thousands of operations per day, hundreds of agents across an organization, or 24/7 reliability requirements. 

Agents that one person directs are tools extending that person. Agents that many people use are infrastructure serving the team. An agent platform is infrastructure serving the organization. In none of these cases are the agents themselves on the team.

How the three approaches compare

The three positions described above lead to very different choices. Here is what each looks like across the points where they diverge most: 

Who is on the team: 2020 Scrum Guide says humans only, no sub-teams. AI-Augmented Scrum Guide says hybrid — up to 50% of Developers may be autonomous bots. Our position: humans only. AI extends each Developer; it is not a team member. 

Scrum Values: 2020 Guide treats them as a human practice (Commitment, Focus, Openness, Respect, Courage). AI-Augmented Guide applies them to AI (‘AI commits,’ ‘AI respects boundaries’). Our position: stay human. A Developer shows Courage by rejecting weak AI output. 

Definition of Done: 2020 Guide — team commitment, governed by professional judgment. AI-Augmented Guide — machine-enforced via ‘Dynamic Quality Gates’ that adapt over time. Our position: human commitment with AI-specific clauses (review, security scan, provenance). 

Accountability for AI output: 2020 Guide — collective Scrum Team accountability for the Increment. AI-Augmented Guide — individual human presenter takes ‘full accountability’ at Sprint Review. Our position: the Developer who uses the tool owns the output. The Scrum Team owns the Increment. 

Compatibility with the 2020 Guide: AI-Augmented Guide conflicts with several immutable rules. Our position is fully compatible — the Scrum Team stays. The practice evolves. 

What this looks like in our delivery model today 

Our internal AI Adoption Leadership Handbook (March 2026) and the AI Sidekicks operating model (April 2026) put this position into practice. A few of the choices that follow: 

AI Responsibility Levels, not AI team members. We classify how responsibility is shared between human and AI on a given task — Assisted (Level 1), Augmented (Level 2), Supervised (Level 3), Orchestrated (Level 4). Human accountability shifts with the level. Team composition does not. 

Working agreements at every level. From day one a team uses any AI tool, baseline rules apply: AI-generated code is reviewed by a Developer who understands and owns it. Security-critical components are written by humans. Client data never enters public AI systems. Higher levels add prompt libraries, AI contribution tracking, and audit trails. 

Architectural discipline scales review. As AI produces more code per Sprint, ‘review every line’ stops being realistic. Our Definition of Done and architectural standards are written to make high-volume output reviewable: clear interface contracts, modular boundaries, integration tests against contracts before implementation. The human stays in control of the structure; the AI fills it in. 

Senior Developers become more critical, not less. AI increases the volume of code that needs review. Senior review capacity is the most important leverage point in AI-augmented development; squad leaders are accountable for protecting it. Working engineers measuring real production AI workloads have published numbers that make the same point: in a worked example of a compliance screening workload, monthly token cost was $25 and monthly human review cost was $29,000 — a 1,000× ratio. The line item that matters is human time, not compute. 

Junior Developers are protected, not phased out. The industry cut junior listings by 60% since 2022. We invest the opposite way. Our juniors are our future seniors, and we measure their skill development separately from their AI-augmented output speed. An Anthropic study of 52 developers learning a new library found that heavy AI use made them marginally faster but led to 17% worse results on a knowledge test — with the difference depending entirely on whether AI was used for explanations or for delegating the work. Speed today, weaker foundation tomorrow, unless you actively manage how juniors use AI to learn. 

We measure cycle time, not feelings — survivorship is the honest measure. Multiple studies have measured the gap between developer perception and reality. METR’s 2025 randomised trial found developers experienced a 19% slowdown while estimating a 20% speedup — a 39-point gap. Volume is even more misleading: AI that produces 4,000 lines a day, of which only 200 survive into production three months later, is not a 20× senior engineer. Survivorship — the share of AI-assisted code that endures unchanged in production — is the metric we are building toward.

The risks we accept

Holding this position is not the same as holding a risk-free one. The trade-offs are worth naming honestly: 

Stay silent on AI — gain: nothing to undo later. Risk: becomes insufficient as AI matures. Teams improvise inconsistently. 

Treat AI as a team member — gain: a complete answer for hybrid teams today. Risk: over-fits to current AI. Sub-teams entrench. Accountability and governance get harder, not easier. 

Treat AI as a Developer extension (our position) — gain: clean accountability. Works under FINMA, GDPR, FADP, and the EU AI Act. Risk: depends on developers maintaining their core skills. If AI delegation goes too far, the very expertise needed to supervise AI erodes — what we call skill atrophy. We manage this risk actively (senior review capacity, junior development pathways, Definition of Done that requires explainability), but it is the long-run watch item. 

Skill atrophy is the risk we take most seriously. If Developers delegate enough of the craft to agents, the judgment they need to evaluate AI output erodes. Our answer is structural: senior review time is protected by squad leader accountability, juniors learn fundamentals before AI output is judged, and we measure skill development separately from velocity. Internally we treat being able to explain AI-generated code in a code review as a precondition for accepting it. 

When would we change our mind?

This position is not faith-based. We are willing to be proven wrong by what happens in the field. Our model would need to be rethought if any of the following became true: 

Outcomes become predictable. If software development became deterministic — input requirements, output product, no surprises — then iterative inspection and adaptation would be overkill. We would need a manufacturing process, not iterative discovery. There is no evidence we are heading there. Complexity is increasing, not decreasing. 

Human judgment becomes optional. If AI systems could be held legally and morally accountable for outcomes, the entire concept of a Developer who owns the work would need rethinking. We are nowhere near this, and the regulatory direction (EU AI Act, FINMA guidance, FADP) is explicitly the opposite — pushing accountability toward identifiable humans, not away from them. 

Stakeholder negotiation disappears. If AI could perfectly understand and reconcile competing stakeholder needs, the Product Owner role would dissolve. This is not happening. If anything, AI makes stakeholder alignment harder by making it cheaper to generate features that were never asked for. 

Teams stop being teams. If software was produced entirely by individuals plus their tools, with no collaboration required, the small-team model would become irrelevant — but so would most of how organisations work. We are not in this scenario either. 

None of these conditions are met. The model keeps working because the conditions that make it useful keep holding. If they stop, we will adapt.

Why this matters for our clients

Most AI-and-development content on the market is selling a transformation. We are not. Our differentiation is restraint: we don’t restructure your team, we don’t put bots in your standup, and we don’t let machines decide what ‘Done’ means. We adopt AI aggressively at the Developer level — Level 3 is our 2026 target across all squads — but we keep the team, the accountability, and the model that have made the Axon Model™ work for fifteen-plus years. AI is the extension. The model stays. 

Trust, transparency, and deep product understanding are what our clients hire us for. AI amplifies that. It does not replace it. And the human in the loop — the developer who knows your domain, your codebase, and your business — stays exactly where they have always been at the helm. 

You can delegate work to AI. You can never delegate responsibility.

Frequently Asked Questions