AI-Native SDLC: Where Does Intent Come From?

Start by agreeing

Anthropic published a playbook for an AI-native software development lifecycle. Six stages: plan, design, build, test, deploy, maintain. Intent is captured as a versioned file. Specifications are generated from that intent. Acceptance criteria are applied as constraints before implementation starts, not discovered in review afterwards. A human approves the plan before any code is written.

We agree with nearly all of it, and it is worth saying plainly rather than hedging. The line that matters most is the one about accountability: "Humans remain accountable for every decision that requires judgment." That is the whole argument. AI removed the typing. It did not remove the deciding.

It is also notable who is saying it. This is the company that makes the coding agent, telling you the agent is not the part that needs the most care.

The question the playbook leaves open

The playbook starts with intent already written down. A file exists. It says what is wanted, why, and under which constraints. Everything downstream flows from it, and flows well.

But nothing upstream is specified. Who wrote that file? What evidence were they working from? How does it stay consistent with the twenty other intents written before it, in other repositories, by other people?

That is not a criticism of the playbook. It is a lifecycle for software development, and it does that job. It is just that the hardest and most expensive decisions in a product happen before the first line of that file exists.

Two layers, not one

It helps to separate them.

• The repository layer. How does this intent become correct code? Conventions, patterns, acceptance criteria, tests, review gates. This lives next to the code, changes with the code, and is read mostly by engineers and agents. The playbook covers this well.
• The product layer. What market are we serving, who is the user, what is the business trying to do, which capability does this feature belong to, what did we learn last time we touched it. This spans repositories, outlives features, and is read by people who do not open the codebase.

A file in a repository is a good home for the first. It is a poor home for the second, for three reasons that have nothing to do with tooling preference.

It spans repositories. Product decisions rarely respect service boundaries. A decision that lives in one repo is invisible to the next.

It outlives the feature. The reasoning behind a decision matters most two quarters later, when someone asks why the thing works this way. Feature branches get merged and forgotten. The reasoning should not.

Its authors do not live in the codebase. Founders, product managers, support, sales. Ask them to open a pull request to record a product decision and the decision simply will not get recorded.

Why this matters more now, not less

When building was the expensive part, a thin specification was survivable. A developer with months of context filled the gaps from memory, and asked a colleague when they could not.

That safety net is gone. An agent has no accumulated context and no judgment about what to ask. It fills gaps by guessing, confidently, at speed.

We watched a junior developer own a piece she knew almost nothing about, because the feature, the user stories and the acceptance criteria were written before she started. Her estimate afterwards was that the coding agent asked her about 90% fewer questions than usual. It is an estimate, not an instrumented measurement, but the direction is the point.

How many questions a coding agent asks tells you how much you left undecided. That is a usable metric, and it points upstream every time.

Where the playbook is ahead of us

Being straight about this is more useful than pretending otherwise. Of the six stages, we are strong on the first three and thin on the last three.

• Test. The playbook treats evaluation as continuous and woven into implementation. We produce acceptance criteria that make verification possible, but a human still does most of the verifying.
• Deploy. Layered agentic review with human approval gates is further than we take it today.
• Maintain. The strongest idea in the playbook, and the one we are watching most closely: monitoring findings re-entering the loop as new intents. That closes the circle back to the product layer, which is exactly where we think the interesting work is.

If you are adopting the playbook and it is working, keep going. Nothing here argues against it.

What we would put where

A practical split, if you are setting this up:

• In the repository: conventions, patterns, the shape of a good pull request, security and compliance constraints, test policy. Things that change when the code changes.
• Above the repository: market and audience, business goals, the capability map, why past decisions went the way they did, and the acceptance criteria that came out of those decisions. Things that change when the business changes.

Then generate downwards. The specification an agent implements should inherit from the product decision, not be invented next to the code and reconciled later.

The short version

The playbook is right that intent has to be written down before implementation. We would go one step further: the quality of that intent is set by a layer the playbook does not describe, and that layer does not belong in a repository.

We build Feature1, which is a tool for that layer, so discount accordingly. The test is independent of us. Look at the questions your coding agents ask this week. Every one is a decision that was in someone's head instead of on the page.