What the AI-native SDLC playbook gets right, and the layer it leaves out
Anthropic has published a six-stage model for building software with agents. The diagnosis is correct and the artifacts are the best version of that idea anyone has shipped. Two things are missing, and both are load-bearing.
Anthropic have published the AI-native SDLC playbook, a six-stage model for building software when agents write most of it. It is worth reading, and I want to start by agreeing with it more than is comfortable, because the parts it gets right it gets right completely.
Then I want to argue that two things are missing, that both are load-bearing, and that neither is an oversight. They follow from who wrote it.
Where it is simply correct
The central diagnosis: development life cycles were designed for an era when writing code was the constraint, and the constraint has moved to planning, testing, reviewing and deployment.
Seeing that stated plainly by a model vendor matters, because it settles something. The disagreement in the field is no longer about whether the shift is real. It is about what to do next, which is a far more useful question for anyone actually running a delivery organisation.
The artifact chain is the strongest part. Intent, then specification, then plan, as actual files under version control rather than states in a tool. intent.md captures what is wanted and why. spec.md is the requirement and design. plan.md names the affected files, the order of work, the risks and the proof.
That is better than what most organisations have, and better than the equivalents I have seen elsewhere, for one specific reason: it puts the intent in the repository. Once intent is a file, it is diffable, reviewable, and it travels with the code. Every organisation I have watched struggle with traceability was struggling because intent lived in a tracker and code lived in git and nothing reliably connected the two.
Their framing of the responsibility shift is also right, and unusually crisp. On the specification, they put it this way: “The product owner reviews that spec, but doesn’t write it.” That is the correct division, and it is uncomfortable in exactly the way true things about org design usually are.
One idea in it deserves picking up directly. They call them control bands: thresholds on a metric that trigger a response automatically, rather than waiting for somebody to notice a chart. Most teams already operate something like this informally, badly, and without a name. Naming it and setting the thresholds deliberately is a short piece of work with an immediate payoff, whatever else you take from the playbook.
The first gap: governance that covers one vendor is not governance
The playbook’s control surfaces are CLAUDE.md, Skills, Hooks and evals. Institutional knowledge the agent reads at session start. Policies as version-controlled, triggerable guidelines. Deterministic gates that block or require authorisation. Regression tests for agent configuration.
Every one of those is a good mechanism. Every one of them governs Claude Code.
That is not a criticism of the design. It is a description of what a vendor can build. Anthropic can make Claude Code’s behaviour inspectable and constrainable, and they have done a better job of it than most. What they cannot do, and have no reason to do, is govern the coding agent your platform team adopted last quarter, or the assistant three developers run in their editors, or whatever your data organisation uses that nobody has reviewed.
A development organisation in 2026 is not running one agent. It is running several, adopted at different times by different people under different assumptions. Each vendor governs itself, thoroughly, within its own boundary. Nobody governs across them, and the gap does not close as each vendor improves, because there is no vendor whose job it is to govern a competitor’s runtime.
Per-vendor governance
- Configuration in that vendor's format
- Gates that vendor's tool respects
- Logs in that vendor's shape
- Excellent, within one boundary
- Silent about every other agent
What an organisation needs
- One policy expressed once
- Enforced wherever agents act
- Evidence in one place, one format
- Answers "which agents touched this path"
- Survives adopting a second vendor
I should be direct about my interest here: this is the layer we build. Read the argument sceptically for that reason. But test it against your own estate. Count the agents actually operating in your repositories, then ask which single configuration file governs all of them. In most organisations the honest answer is none, and nobody owns finding out.
The second gap: the lifecycle stops at the repository boundary
This is the one I find more interesting, because it is less about vendors and more about where the damage accumulates.
The six stages describe the engineering lifecycle: plan, design, build, test, deploy, maintain. Within that boundary the model is sound. But it assumes something it does not examine, which is that the work item is correct when the cycle starts and stays correct while the cycle runs.
In practice that assumption fails immediately, and it fails worse the faster the engineering side gets.
A ticket says in progress. The change merged six days ago. Another says done because someone dragged it at sprint end, while the pull request that implements it is still open. A third of the merges this week reference no work item at all, because they were small follow-ups that nobody wanted to raise a ticket for. Nothing in a six-stage engineering model detects any of this, because all of it happens in the tracker, which is outside the stages.
That matters because the tracker is what non-engineers act on. Prioritisation, capacity planning, dependency coordination, escalation and the answer to “when will it be ready” are all computed from the board. Speed up the engineering lifecycle by an order of magnitude and leave the board maintained by hand, and you have not built an AI-native lifecycle. You have built a very fast engine attached to an instrument panel that updates weekly.
The fix is not another stage. It is to stop treating the tracker as a thing people maintain and start treating it as a view derived from what actually happened. The playbook already puts intent in the repository, which is most of the way there. The remaining step is to let the repository answer the status question too, and to treat disagreement between record and reality as the signal rather than an untidiness to be nagged about.
Where this breaks down
The single-vendor criticism is self-serving and you should discount it accordingly. We sell the cross-vendor layer. A team genuinely standardised on one agent, with the discipline to keep it that way, gets most of what they need from the playbook’s mechanisms and should not buy a governance layer to solve a problem they do not have.
Standardising on one vendor is a legitimate strategy. I have framed multi-vendor as the default. Plenty of organisations pick one deliberately, and the resulting simplicity is worth real money. The cost is concentration risk and switching cost, which should be priced rather than ignored, but it is a defensible trade.
The tracker criticism does not apply to everyone. A small team shipping continuously, with a shared verbal model of the work, does not have a board problem, and adding reconciliation machinery to solve a problem they do not have is waste. This argument gets stronger with organisational size and is close to irrelevant below about fifteen people.
A playbook is not obliged to cover everything. Anthropic wrote about the engineering lifecycle with their tools, which is a reasonable scope and clearly labelled. Criticising a document for not being about something else is a cheap move, and the parts it does cover it covers better than the alternatives.
And I have not run it. This is a reading, not a report from six months of practice. The stage model may hold up better or worse than it reads on the page, and anyone who tells you how a published framework performs in production three weeks after publication is guessing.
The takeaway
The diagnosis is right, the artifact chain is the best version of that idea anyone has shipped, and and the responsibility split is stated with unusual clarity. Take all of it.
Then notice the two boundaries. The governance mechanisms cover one vendor’s runtime, which is the most any vendor can offer and less than an organisation running several agents requires. And the six stages end where the repository ends, one step short of the record that everyone outside engineering actually makes decisions on.
If you take one thing into next week: count the distinct coding agents operating against your repositories, and then find the one place where a policy covering all of them is written down. The gap between those two answers is the part no playbook from a model vendor can close for you.