The AI-native SDLC, with the part it leaves out
Agents build. Humans verify. Intent has to come from somewhere.
The AI-native software development lifecycle starts with intent written down and lets coding agents build from it. It is right about almost everything, and it starts at the repository. The product decisions that produce the intent live one layer above. Feature1 is that layer.
What the AI-native SDLC is
In the old lifecycle, writing code was the slow, expensive step, so everything was organised around it. In the AI-native lifecycle, code is generated. The expensive steps move: to writing down what should exist and why, to acceptance criteria that say what done means, and to verifying that what the agent built is what was meant. Anthropic's playbook puts it in one line: you write the intent first. The agent does the typing. People decide and check.
The steps did not become optional. They became faster, and they moved to the front.
The question it leaves open
The playbook starts with intent already written. Where did it come from? Which customer was it for, which capability does it change, why this feature and not the twenty others in the backlog? Those decisions are made before the first file in the repository exists, and they do not belong in a repository. That is the product layer, and it is where most teams shipping with agents are now waiting.
What we saw: a team serving enterprise customers moved to AI-assisted development. Delivery got faster and, within months, there was always something waiting on a product decision. They hired a second product manager, not a third developer.
The whole loop, with the intent layer in it
Direction
A one-page product strategy: where you win, for whom, the strengths to build on. Written, so it can be checked against.
Product reality
What the product can already do, read from the repository capability by capability, and kept current as the code changes.
The gap, as initiatives
The difference between the direction and the product, bundled into bets with an objective and a measure each.
Features, stories, acceptance criteria
Each initiative planned into features and user stories with acceptance criteria, written before anyone opens an editor. This is the intent the playbook starts from.
Agents build
Claude Code, Codex or any MCP client reads the stories and acceptance criteria from Feature1 and builds what was meant, with far fewer product questions.
Humans verify, reality updates
The pull request is reviewed and tested by a person. When it merges, the picture of the product updates and the next decision starts from what is true now.
What it looks like in a small team
At a scaleup, a couple of days went into the feature, the user stories and the acceptance criteria for an MCP layer. Then a junior developer who started with almost no context on the feature built it in one day, and it passed end-to-end testing. She reported far fewer product questions from the coding agent than usual. Same tools. The difference was that the intent existed before the build.
We wrote up the reasoning in Where does intent come from?, and the failure modes when intent is missing in problems with AI-assisted development.
Questions people ask
What is the AI-native SDLC?
A software development lifecycle in which code is generated by agents from written intent, and the expensive human work moves to deciding what should exist, writing acceptance criteria that say what done means, and verifying what was built. The steps of the old lifecycle got faster; they did not become optional.
How is it different from the traditional SDLC?
The traditional lifecycle is organised around writing code, because that was the slow step. The AI-native lifecycle is organised around intent and verification, because generation is fast. Deciding what to build becomes the constraint.
Where does the intent come from?
From the product layer, above the repository: the product strategy, what the product can already do, the gap between them, and the features and stories with acceptance criteria that close the gap. Feature1 holds that layer and exposes it to coding agents through MCP.
Do you still need product managers in an AI-native SDLC?
More than before. In the teams we work with, faster delivery moved the bottleneck onto product decisions. One team hired a second product manager when deciding became the constraint.
What does the developer do when the agent writes the code?
Owns whether it ships. Reviews it against the acceptance criteria, tests it, and moves it to done. Mistakes got cheap to make and stayed expensive to find, so the review is the job.
Which coding agents does this work with?
Claude Code, Codex, Cursor and any MCP-compatible agent. They read the features, stories and acceptance criteria from Feature1 through its MCP endpoint.
Give your agents intent worth building from.
Thirty minutes to write the direction down. Then connect the product and let the loop run.