On August 21, 2026, Anthropic published The AI-Native SDLC Playbook. It is worth reading. It describes how the software development lifecycle changes when agents write most of the code. The core message: code is no longer the bottleneck. The bottlenecks now sit to the left and right of the build, in planning, review, testing, and deployment.

I agree with that. But something struck me while reading. Requirements engineering barely appears in the playbook. And where it does appear, it is reduced to a prompt.

What the Playbook Says

The playbook describes six stages: Plan, Design, Build, Test, Deploy, Maintain. Each stage ends by committing an artifact that the next stage reads: intent.md, spec.md, plan.md, the diff, the PR with its review findings, the incident record. I like the idea of versioned artifacts as an audit trail. It matches what I have been advocating with the AI Unified Process (AIUP) for a while: specifications belong in the repository, next to the code.

Two stages are relevant for requirements.

In Stage 1 (Plan), a person describes their idea in their own words. Claude asks the questions an analyst would ask: scope, users, constraints, success criteria. The result is an intent.md. The product owner corrects it and commits it.

In Stage 2 (Design), requirements and design collapse into a single session. Claude reads the intent.md, applies the organization’s skills (brand, security, compliance, UX), and writes a spec.md. The product owner no longer writes the spec. They only review it.

The table “The shifts” says it clearly. Traditional: requirements are gathered in workshops and written up by analysts. AI-native: requirements and design are compressed into one session with an agent.

What Is Missing

Anyone who knows requirements engineering will miss a few things here.

There is only one stakeholder. The playbook talks about the “originator”, a single person with an idea. Real projects have several departments with different and often conflicting interests. Finding and resolving these conflicts is the actual work of requirements engineering. A brainstorming session with an agent does not replace it.

There is no analysis. The step from “what someone wants” to “what the system must do” is a single prompt in the playbook. Completeness, consistency, and testability are not treated as activities of their own. The playbook trusts the model to ask these questions by itself.

There is no structure. The spec.md is a prose document. No use case, no domain model, no business rules. What it contains depends on the prompt and the company’s skills. For a small feature, that is enough. For an order management system with 40 use cases and a data model with 60 entities, it is not.

Non-functional requirements only appear indirectly. They are hidden in skills (security, compliance). Performance, availability, and data protection as explicit, measurable requirements do not appear at all.

Traceability is reduced to Git timestamps. The playbook measures how fast an intent.md becomes a spec.md, and how often the spec changes after the build has started. That measures speed and rework. It does not measure whether the spec covers the requirements or whether a test belongs to a requirement.

The metrics give it away. The leading indicator for Stage 1 is the time until a committed intent.md. The expectation: from weeks to hours. That is a goal for speed, not for quality.

Why This Is a Problem

To be fair, the playbook is written for large enterprises. There, requirements engineering often means a PRD travels through three committees and in the end nobody remembers what the business actually wanted. Compared to that, “one person, one agent, versioned on day one” is real progress.

But the basic assumption of the playbook is wrong, or at least incomplete. It says: code is no longer the bottleneck, so everything before it can be compressed.

I would say the opposite. When code becomes cheap, only one lever remains: the quality of the requirements. An agent that generates 5,000 lines of code from a bad spec in one hour produces 5,000 lines of wrong code in one hour. And the product owner, who according to the playbook only reviews the spec, does not see the gaps because they never thought the spec through themselves.

The playbook delivers the proof itself. The lagging indicator for Stage 2 counts spec changes after the build has started. If that number is relevant enough to be measured, Anthropic knows the problem exists.

What Instead

My answer is the AI Unified Process (AIUP). AIUP puts requirements engineering at the center and makes it usable for agents:

  • Use cases instead of prose. Every use case has actors, preconditions, a main success scenario, alternative flows, postconditions, and business rules. An agent can derive code and tests from it. A human can review it because it has a known structure.
  • An entity model before the code. Entities, relationships, data types, validation rules. The data model is the foundation of every business application, and it should not be a by-product of a prompt.
  • Explicit non-functional requirements and constraints. Measurable, versioned, in the repository.
  • Traceability from requirement to test. A @UseCase("UC-007") on a test is worth more than a commit SHA in Jira.

The AI Unified Process takes from the playbook what is good: artifacts in the repository, skills as institutional knowledge, plan mode before the build, hooks as guardrails. But it does not skip the step between idea and code. It makes it explicit.

Conclusion

The AI-Native SDLC Playbook is a good text about Build, Test, Deploy, and Maintain. For Plan and Design, it is thin. Anthropic did not forget requirements engineering. But they reduced it to what an agent can do in one session.

That is enough for a feature. It is not enough for a system.

More about AI Unified Process at unifiedprocess.ai.