6-step development process that needs to be changed before the code: analysis of AI-Native SDLC Playbook
When I first read the AI-Native SDLC Playbook released by Anthropic on August 21, 2026, the sentence that caught my attention was not about new models or new coding features.
Code is no longer the bottleneck.
This is a declaration that code is no longer a bottleneck. The speed at which agents write code has already exceeded the speed at which humans can review, approve, and deploy within existing processes. However, many organizations still maintain the same approval gates, tickets, handoffs, meetings, and manual reviews as before.
As a result, what happens is that the build stage is reduced to just a few hours, while planning and design take weeks, and review and deployment take days. Productivity hasn't increased; instead, a small automated island has been created in the middle of the pipeline.
The value of this playbook does not lie in "how to write code quickly with Claude Code." Rather, it proposes transforming the development lifecycle itself from a linear process to a loop where committable outputs automatically open the next stage.
The premise of traditional SDLC has already been broken
Traditional SDLC is generally divided into six stages: Plan, Design, Build, Test, Deploy, and Maintain. Product owners gather requirements, designers create designs, developers implement, QA verifies, release teams deploy, and operations teams monitor.
This structure was reasonable when writing code was the most expensive and time-consuming part. PRDs and estimation meetings were devices to align before development, and security reviews worked by having humans slowly read the implementation results. Each stage had its owner to clearly define responsibility.
The problem is that only the implementation speed has changed dramatically. Agents can read dozens of files, create tests, modify code, and execute commands. In contrast, the organization's approval committee still meets only once a week. The security team's review throughput is based on the amount of code written by humans. PR reviewers try to read every line of the diff manually.
Therefore, as code speeds up, the bottleneck moves left and right.
- Plan: The time it takes to agree on what to make
- Design: The time it takes to convert requirements and policies into design
- Test/Review: The time it takes to verify that the result satisfies the intention and policy
- Deploy: The time it takes to safely deploy to the production environment
Especially in regulated industries, either the security review queue becomes long or unreviewed code is deployed, leaving only two bad choices. AI-Native SDLC does not solve this problem by "removing humans." Human judgment is left, but the data that humans must read from the beginning and the mechanical checks that can be verified are moved to agents and automated gates.
AI-Native SDLC is a loop, not a line
The transition proposed by Anthropic is as follows. Traditional development moves between stages with documents, tickets, and sign-offs. AI-native development commits the results of each stage to Git, and that commit starts the next stage.
The idea is that intent.md becomes the idea. The approved intention becomes spec.md. The design is concretized into plan.md. The implementation becomes a diff and a test. The PR includes automatic review results. If an anomaly is found during operation, the diagnosis result becomes a new intent.md.
This connection is important because the file extension is Markdown, but because one output is read by both humans and agents, version-controlled, and used directly as input for the next task. The commit history becomes an audit trail that shows "who wanted what, what the agent made, and who approved it."
However, it would be problematic to misunderstand Git as an all-purpose tool. Organizations that already have Jira, ServiceNow, Figma, and regulatory requirement systems cannot abandon them overnight. The playbook does not suggest eliminating existing systems. Instead, it suggests designating one source of truth for each output and maintaining the rest as links or copies. At the very least, you can start the transition by putting issue IDs in documents and commit SHAs in issues.
1. Plan: Fixing ideas as intent.md
In the Plan stage, what's important is not to create a more refined meeting document of requirements. Rather, it's to fix the starting point of the idea in a form that the next stage can execute, losing as little of the person's language as possible.
The user describes the problem in their own words, such as "the customer calls the call center to check their billing status." Claude asks about the affected users and systems, constraints, success conditions, and unresolved questions. The result is intent.md. The product owner reviews, modifies, and commits the file.
This approach is different from the existing backlog writing flow. Previously, an idea was translated multiple times into tickets, user stories, story points, refinement meetings, and requirement documents. As the translation is repeated, the original problem awareness becomes fainter, and what is delivered to engineering is a sentence that is several steps away from the initial intention.
intent.md is not a completed requirement specification. Rather, it's close to a proto-spec that preserves the question of "why we're doing this." Therefore, a good template should not only include a list of functions.
# Intent: Billing Status Self-Service
## Problem
The customer calls the call center to check their billing status.
## Proposed outcome
Check the current status, next step, and expected processing date on the portal.
## Constraints
- Only use existing authentication.
- Do not add new PII to the browser session.
## Open questions
- Should external adjusters also have access?
The metrics to measure at this stage are also clear. How much has the time from the first conversation to the committed intent.md been reduced? What is the rate at which product owners accept the intention for the next stage? The goal is not to write good documents but to reduce the time it takes for ideas to become executable records.
2. Design: Compressing requirements and design into one session
With the approved intent.md as input, Claude creates a requirement and design specification. Here, the organization's brand rules, security policies, compliance, and UX standards are not repeatedly explained in guidelines but are injected as version-controlled Skills.
In traditional structures, analysts write requirements, and designers interpret them. This structure was necessary for responsibility separation, but it creates loss between requirements and design. In the AI-native flow, the product owner confirms the original intention, and the agent reads the codebase and policies together to create spec.md. The agent does not "solve" policy conflicts or hazardous assumptions but marks them as concerns.
The person's role becomes more important even as it decreases. The product owner does not need to write the document's sentences, but they must judge whether the specification really solves the problem, whether open questions have been answered, and who should approve the risks. It's also a point to make the judgment of whether the design is correct before the code is generated, not afterwards.
3. Build: Approving plan.md before writing code
The playbook proposes Claude Code's plan mode as the basic entry point for implementation. Before the agent modifies the code, it reads the repository and creates plan.md, which includes changed files, work order, risk factors, and verification methods. The engineer refines the plan by asking questions like "what can break," "what is the most dangerous step," and "why didn't we choose other alternatives."
This is not a story about documenting the developer's thought process. It's a device to convert the cost of finding design errors after seeing the completed diff to the cost of editing the document upfront. If the plan is wrong, it's cheap to fix because no files have been touched yet.
# Plan: Billing Status Self-Service
## Files that change
- portal/src/claims/StatusPanel.tsx
- claims-api/routes/status.py
- claims-api/tests/test_status.py
## Risks
Claims-core API is limited to 50 per second, so caching is needed for the panel.
## Proof
Test four billing statuses and compare the approved mockup and screenshot.
During implementation, if you deviate from the plan, don't just modify the code; update plan.md in the same commit. This rule must be kept to prevent the difference between the plan and actual changes from being hidden.
4. Test: Changing tests from the end sentence to continuous evaluation
In traditional QA, testing is a gate at the stage boundary. In AI-native SDLC, testing and evaluation are continuously executed during implementation. Especially when the agent's settings change, code changes should be subjected to regression testing at the same level.
Here, settings don't just mean models. CLAUDE.md, Skills, Hooks, and prompts all change the agent's behavior. Therefore, when these files are modified without running tests, it's similar to modifying core libraries without testing.
A practical starting point is to select 20-50 actual tasks from recent work, save them with prompts and pass criteria, and make them executable. The results should be judgmentable, such as test passing, lint passing, preserving existing behavior, and complying with policies. CI executes the agent non-interactively and runs the eval suite with setting change PRs and at regular intervals. When an operational failure occurs, it adds that failure as a permanent eval case.
This design is beyond the level of "AI-generated code requires more testing." It's a regression test that measures whether the organization's development capability has not deteriorated when the agent changes. Model replacement, prompt changes, and policy modifications are all changes in product quality.
5. Deploy: The agent stops in front of the production gate
In the Deploy stage, the agent can review PRs, process review comments on its own PRs, and fix failed checks. However, it should not directly write to main without human approval or proceed to operational deployment. Branch protection and code owner approval
Based on Anthropic's AI-Native SDLC Playbook, we analyze how the software development process changes from intent.md to maintenance automation in the era of agents.