Humans try to humanize everything: we dress up our pets, we give our cars names… and now, inevitably, it’s AI’s turn. I don’t mean being extra polite to it (on the theory that, if the machines ever rise up, they’ll take pity on us). I mean that we ask it to replicate our workflows exactly as we do them, without stopping to ask whether that’s the right way to do the work.
As humans, we specialize, we get tired, we forget things, and we need mechanisms that help us stay organized. That’s where pull requests, code reviews, roles, Scrum, sprints and dailies come from: tools and practices designed to coordinate teams and compensate for our own limitations.
Yet when agents started writing code, we simply handed them the same tools and processes we had designed for ourselves.
Agents have limitations too; they just aren’t ours. They don’t get tired or need a job title, but they remember nothing between sessions and they produce more than we can read. The mistake is giving them the remedies for our flaws instead of the remedies for theirs.
Let’s start by looking at what happens when we humanize AI in two paradigms that are common in development teams with advanced adoption.
The org chart mirage: agents that emulate human roles
You’ve probably seen or heard of multi-agent development systems in tools like Claude Code or OpenCode, where you can set up several subagents to generate code. Some organizations tend to design these subagents so that each one emulates a role: one for frontend, one for backend, a QA, a UI/UX designer, an architect, and so on. At first glance it feels intuitive, but is it the best way to do it?
Replicating this human structure among machines creates two big problems: a very high operating cost, and a harness (the technical scaffolding that orchestrates the agents) that sometimes ends up harder to maintain than the code itself.
On cost, Anthropic measured that its multi-agent systems use about 15 times more tokens than a chat conversation. The company also acknowledges that coding is less parallelizable than research, so the benefit of splitting work across several agents is smaller precisely in our field (Anthropic, 2025).
On complexity, the problem isn’t limited to “harness code”: it translates into more failures. The MAST study (University of California, Berkeley) analyzed systems such as ChatDev and MetaGPT, which simulate a software company with job titles (CEO, CPO, programmer, tester…). Failure rates ranged from 41% to 86.7% depending on the system and model evaluated, and they aren’t comparable with each other. In one of the observed failures, the “CPO” agent ends the conversation without consulting the “CEO” (Cemri et al., 2025, NeurIPS).
So we should ask ourselves: does my team need an agent system? What do I want to achieve with it? There are genuine reasons for one. Multi-agent systems can be very effective at improving the quality of generated code, or they can help when more elaborate context-window management is worthwhile.
Once the need is identified, what’s the alternative? How do I work with a multi-agent system effectively?
There are two paths:
- The simplest option, Evaluator-Optimizer, where one agent executes and another judges and evaluates the result. This pattern has been gaining popularity lately for its simplicity (and low cost). One example is Matt Shumer’s Gauntlet Loop: a builder agent and a critic subagent work in a loop inside an agentic harness, and it was born precisely for building software.
- Stop splitting by job title and break the work down by task, context and tools. It’s important to do this mapping so you aren’t tempted to create more agents than you need. An example of breaking work down by context: one agent implements the change, a subagent explores the repository and returns only what’s relevant (so the main agent doesn’t carry the whole codebase in its context window), and an evaluator runs the tests against the spec. Each one exists because of what it needs to see and do, not because of a job title. And if that’s enough, the right answer is a single agent with good tools. One way to proceed after this analysis is to follow the approach Anthropic sets out in “Building effective agents”: build these agents only when there’s a specific reason, and use the simplest patterns first before scaling up to the most complex one.
Scrum with agents: when the bottleneck moves
According to McKinsey’s report, the top-performing 20% of developers report an average productivity gain of 55%, compared with just 3% for the remaining 80%. It’s worth pausing to read this with caution: it’s self-reported data. A measured figure points in the same direction: according to Sonar, the PR cycle is 3.4 times shorter (Case study: AI in the product development life cycle | McKinsey). However, McKinsey notes that what sets that 20% apart isn’t the use of AI, but that the resulting operating model looks very little like Scrum. For example, it cites a bank that works in daily sprints. It also defines agents by their mandate and permissions, not by an org chart.
The key to that shift, then, is rethinking Scrum in the teams getting the best results from AI adoption. The usual management response is: “Scrum is just a framework, adapt it.” But at these productivity levels, the problem isn’t the framework’s name. It’s:
- Cadence: A two- or three-week sprint is calibrated to human speed and to the horizon over which we can be “relatively accurate” with our estimates. In teams of autonomous or semi-autonomous agents tearing through a backlog, that cadence can stop making sense.
- The bottleneck: What limits a team now isn’t the time spent writing code, but its ability to define and verify work at the speed the machine produces it.
- Context: A pull request (PR) assumes the author will be around, will remember why a decision was made and will answer for their work. An agent, by contrast, ends when its session closes, and its context disappears.
It’s worth stopping here, because a manager can easily fall into thinking that reaching such a high level of productivity is more of a blessing than a problem. More PRs don’t always mean more value delivered. If the process stays the same, human reading capacity stays flat and review wait times start being measured in weeks. The bottleneck has simply moved to review and alignment.
But are these bottlenecks exclusive to small startups working on greenfield projects with a very aggressive AI-first approach? No: giants like Salesforce have had to redesign their workflow completely. On their engineering blog, they explain how the flood of AI-generated code sent their PR cycle times soaring and overwhelmed their senior engineers. Their solution? It wasn’t to leave humans “only the critical stuff”, but to rebuild the review process: when a PR is opened, a tool analyzes the intent of the change, adds context and flags the risk, and approval remains human. And there’s a lesson here for us: Salesforce reconstructs intent after the code is written; with a spec, that intent is fixed beforehand.
Even before agents, some teams had abandoned the sprint because it didn’t fit work that changes continuously; with agents producing around the clock, that mismatch only grows. That’s the case of Oleksandr Kondratiuk, who explained in CIO how his team delivers AI platforms for Fortune 500 clients after dropping Scrum entirely. The reason wasn’t developing with AI, but that their product changes constantly (pipelines, retraining); copilots came later. Their solution was to replace the sprint ritual with continuous delivery (Kanban) based on automated validations.
Don’t settle: Measure what the data says
Questioning methodologies doesn’t mean blindly buying into every promise of acceleration. If we introduce AI processes into the same team, we need to analyze carefully what effect they’re having on it. So be careful not to measure success with, for example, satisfaction surveys alone. If you rely only on that, you fall straight into the AI productivity paradox: developers say they feel much faster, but system metrics show a different reality. Either there’s no real acceleration, or delivery is faster but with more errors.
Why does this gap between perception and reality happen? Because of a basic principle of flow management: optimizing a local task (writing code) without touching the system’s bottleneck (reviewing, aligning and validating) only creates an illusion of speed.
Here’s what some empirical data says about the impact of AI:
| Study | The Data | Takeaway |
| METR (Model Evaluation and Threat Research) 2025 | Perception: Developers believed they were faster with AI (they perceived a 20% improvement). Reality: The measurements didn’t confirm it (they took 19% longer); what matters is the gap between what’s perceived and what’s measured. | Removing the friction of the blank page feels fast, but it doesn’t reduce lead time. Don’t measure with satisfaction surveys. |
| DORA (DevOps Research and Assessment) 2025 | Perception: More than 80% report higher individual productivity (with 90% adoption). Reality: 30% don’t trust AI-generated code, and while throughput goes up, delivery instability rises too. To measure it, DORA has introduced a new official metric: Rework Rate. | Writing code faster without changing the verification mechanism only increases work in progress (WIP), shifting the risk to production. |
Ceremony versus mechanism
Ceremony serves humans, who need to stop and think before executing and to sync up with others. Mechanism serves the machine. AI doesn’t need your planning meeting; it needs good specifications to work from.
So if we want to manage agent-supported teams effectively, we have to give humans what humans need and give AI agents what AI agents need:
How to move toward AI-first without dying in the attempt
Today, evolving our software development life cycle (SDLC) into an AI-first one goes through SDD (Spec-Driven Development). There are other, less established alternatives such as Loop Engineering (agentic loops), but for a traditional SDLC the safest step is SDD. And here it’s worth being precise about how everything discussed so far fits with the use of SDD.
SDD on its own doesn’t solve the problem. In fact, there are two questions we should be asking ourselves.
Are we implementing SDD properly?
The line is set by how reversible the error is. McKinsey describes this same risk-based triage, and it translates into three levels:
- Reversible and contained (a refactor with tests, copy): the agent closes the task on its own if it passes executable acceptance.
- Reversible with impact (a feature behind a feature flag): a person validates the spec beforehand and the checks validate the code.
- Irreversible or regulated (data migrations, permissions, regulatory calculations): human review of both design and code, with named approval and evidence.
The harder an error is to undo, the earlier and more human the control.
Does this mean removing control?
Quite the opposite, especially in regulated sectors (banking, insurance, healthcare): if you lead delivery in these environments, you can’t simply “switch off” oversight. You need strict traceability and control. That’s exactly where a robust harness, a verifiable contract with deterministic evals, access surfaces declared in advance and validated server-side, and an explicit risk classification (the three levels above) provide a much stronger audit trail than relying on a tired developer to spot a bug while reading their tenth PR of the day.
It’s important to stress that this approach isn’t applied identically to every team, since not all teams have the same level of AI adoption maturity, and not all solutions are the same. A 15-year-old legacy project is not the same as a proof of concept the team started a few days ago. Before rethinking sprints, ceremonies, roles and ways of working, it’s important to understand the context that makes a transformation of this scale possible.
Conclusion: look at what you’re handing your team
For years, we’ve built tools and processes to compensate for our flaws. So before handing AI your tools and processes, ask yourself whether the machine has the same flaws, or whether you’re applying human remedies (job titles, meetings, endless manual reviews) to limitations that belong to an agent (amnesia between sessions and overproduction without context).
And if you’re already moving your team toward an AI-first approach and the volume of delivery is starting to cause problems, it’s time to ask yourself: are you designing mechanisms for the machine’s real flaws, or are you just teaching it to pretend it’s one of you?
Don’t settle for “if it works, don’t touch it.” Assess your development team’s AI maturity and don’t settle for the status quo: measure where your real bottleneck is, always look for improvement and experiment, even if that means breaking with what we’re used to doing.
