If Agile were
invented after AI
The manifesto isn't obsolete. But it was written to coordinate people who produce software, and that is no longer the scarce thing. Here is what changes when the unit of management becomes judgment, execution, and bounded autonomy.
What would we have built instead?
If Agile were designed in 2026 rather than 2001, knowing what we now know about agentic coding, what would actually be different?
Not the values layer. Customer value, working software, collaboration, adaptation, technical excellence, sustainable pace: all of it survives contact with agents intact. The Scrum Guide never mandated story points, planning poker, or velocity anyway. It asks only that backlog items be sized.
What changes is the unit of management. Classic Agile coordinates people who produce software. An AI-native Agile would coordinate human judgment, machine execution, evidence generation, and controlled autonomy, because the scarce resource stops being coding capacity and becomes problem framing, contextual knowledge, review attention, assurance capacity, and accountable decision-making.
decide carefully,
verify independently,
release reversibly,
learn continuously.
Nobody has found the multiplier.
The single most useful thing in the literature is a contradiction. Two credible studies, opposite signs.
METR's 2026 follow-up found possible speedups with confidence intervals wide enough that no stable universal effect could be claimed. DORA's 2025 synthesis offers the reconciliation: AI is an amplifier of the surrounding system. Strong platforms, tests, architecture, documentation and feedback loops get amplified. So do weak ones.
The conclusion is not that AI is oversold. It is that you cannot assume a universal productivity multiplier, and any methodology that quietly assumes one will mis-plan.
We stopped quoting a speedup number internally. What we track instead is where a task class actually lands: some are near-free, some cost more in review than they ever saved in typing. Averaging those into one figure destroyed the only signal worth having.
The amplifier finding matched our experience exactly. The areas where agents help most are the ones that were already well tested and well documented. In the weakest corner of the codebase they mostly generate more of the problem.
From user story to outcome contract.
A story describes what someone wants. An outcome contract describes what would make the result trustworthy, and how much authority may be spent getting there.
Verified customer outcomes. Not code volume, agent activity, or nominal task completion.
An outcome contract: intent, constraints, evidence requirements, autonomy limits, escalation rules.
Humans, always. Agents may be assigned work but never own product, architectural, ethical, security, or release accountability.
Product clarity, architecture, context quality, review bandwidth, evaluation quality, governance latency.
Expands from "implemented and tested" to specified, independently evidenced, secure, operable, traceable, releasable.
That last row is the load-bearing one. When the same system generates both an implementation and its proof, passing tests stop being independent evidence. An agent reproduces the same misunderstanding twice: once in the code, again in the test meant to catch it.
This is the finding we acted on first, and it cost us the least to adopt. Our agents no longer verify their own work. Generation and judgment are split across separate runs, with provenance linking a result back to the run that produced it.
The thing that made it stick wasn't a policy document. It was making the verification gate a command. A change to data access isn't done until bun test:tenancy passes, and nothing ships without bun test:critical. Agents can run those. They cannot grade themselves on them.
Govern authority, not access.
The useful mental model is a ladder. An agent that can edit files, run commands, use external tools and trigger workflows has a far larger blast radius than an inline completion, and the control that matters is how far up the ladder it is allowed to climb.
Reads approved context, produces explanations and suggestions.
Edits a local workspace or isolated branch, but cannot publish.
Creates branches, runs approved commands, opens draft pull requests.
Merges low-risk changes that pass specified independent controls.
Deploys reversible, low-impact changes inside a bounded environment.
Safety-critical logic, irreversible data changes, regulated decisions, secrets, legal commitments, high-impact access control.
Teams get the assignment rule wrong. A tier is chosen by impact and recoverability, never by how impressive the model seems. A documentation change can be fully autonomous. A one-line authorization change may not be.
We learned the containment lesson the expensive way. Ten agent branches finished in parallel and we batch-merged them at the end. Every single one conflicted. The fix was a hard cap of three concurrent agent worktrees, with each unit merging back the moment it completes.
We also wrote a literal escalation contract into the repo instructions. An agent that hits an unknown root cause, needs an architecture decision, or would have to touch files outside its assigned scope must stop and return a message starting with ESCALATE:, stating what it completed, where it got stuck, and what decision is needed. Guessing in order to "finish" is the failure mode. A clean stop is the success case.
One number stops being honest.
Estimation changes more profoundly than any other Agile practice, because AI breaks the assumption underneath it: that effort to produce code is a stable proxy for effort to deliver value.
A single backlog item can now behave in at least seven distinct ways. The agent nails it but specification and review dominate. The agent produces many plausible approaches and review balloons. Implementation is trivial but migration and rollout are not. The agent succeeds where a human would have needed a week of exploration. An experienced maintainer would have been faster than prompting. Runtime is long but unattended, so elapsed time rises while human-touch time falls. Parallel attempts cut uncertainty but burn verification capacity.
A single scalar covering all seven will mislead.
E[H] = Hframing + Hsteering + Hreview + P(rework) × Hrework + Hrelease
Report P50 and P85, never a single date. The gap between them is not estimation failure. It is the uncertainty reserve, and it is actionable: a wide gap should trigger a spike, a smaller task boundary, better acceptance criteria, or a more conservative autonomy tier.
Story points can survive, but only redefined as relative delivery complexity: ambiguity, integration, verification, risk. They must answer "how hard is it to move this from understood intent to verified, operable outcome?" and never "how much code will a person type?" Do not compare point velocity across teams. Do not rate individuals by completed points. Do not convert points into commercial commitments.
The estimate that changed our planning was not a duration. It was the split between elapsed time and human-touch time. An agent run can take forty minutes of wall clock and four minutes of a person's attention, and those two numbers belong in different columns of the plan.
Once we separated them, the real constraint became obvious: we were never short on agent capacity. We were short on review attention, which is why we cap concurrent work rather than concurrent agents.
Typing becomes the smallest slice.
Here is a planning hypothesis for a mature AI-native team: less direct coding, more specification, review, assurance and system improvement.
The unsettling number is not the 10%. It is the 42% in review, integration, quality and security: work that grows precisely because generation got cheap. Cheap generation creates review queues, duplicate abstractions, and maintenance burden. Optimise accepted value and small batches, not output.
We stopped treating repository instructions as documentation and started treating them as source code. Context lives in versioned, code-reviewed files scoped per domain, because that is what actually shapes agent behaviour, and a stale instruction file is a defect that reproduces itself across every future run.
The signal we watch is not throughput. It is whether a correction had to be made twice. A repeated prompt fix means the system is wrong rather than the agent, and it gets promoted into an instruction, a test, or tooling.
Every improvement needs a counter-metric.
AI adoption is a sociotechnical transformation, not a software-licence rollout. If AI amplifies the existing system, then improving the system comes first: platform reliability, test quality, documentation, architecture, feedback speed, product clarity. Putting an agent on top of a dysfunctional process amplifies the dysfunction.
must be read against change failure rate and escaped defects
against human review time and discarded-output rate
against production regressions and later rework
against policy exceptions and autonomous-action incidents
against codebase growth, duplication, and maintainability
Avoid mandatory usage targets. They push people to use AI where it increases effort or risk, and push failures out of sight. Pilot with skeptical senior engineers, not only enthusiasts: the 2025 Stack Overflow survey found more developers distrusted AI output accuracy than trusted it. That skepticism is data, not resistance.
Scale the bounded, reversible, mechanically verifiable work first: test generation followed by independent review, documentation updates, codebase exploration, low-risk refactoring, dependency analysis, migration preparation, draft pull requests. High-risk autonomy comes last, if at all.
Four things that stay human.
An AI-native Agile would be more automated than classic Agile, but also far more explicit about evidence, provenance, risk, decision rights and uncertainty. Fewer reasons to estimate typing effort. More reasons to forecast scarce human attention. It would move faster where work is well specified, testable, reversible and supported by strong platforms, and deliberately slower where ambiguity, irreversibility, sensitive data, security exposure or societal impact make judgment the central task.
The original insight survives: complex work should be organised through transparency, inspection, adaptation, collaboration and frequent delivery. The AI-era extension is that autonomy itself must become transparent, inspectable, and adaptable.
Want this kind of thinking on your team?
I build software that ships and write about how the work actually changes. If the questions in this piece are live at your company — what to delegate, what evidence to demand, who stays accountable — I'd like to hear about it.