AI’s coding speed has improved, but the review, approval, and handover processes remain at the same pace, with efficiency gains being consumed by the workflow. Anthropic has redesigned the six stages into a closed-loop product chain: Each stage submits a file, and the next stage

From intent.md to a Closed Loop: Six Stages, One Artifact Chain, and Several Approval Gates in AI-Native Software Development

Interpreting Anthropic’s “AI-Native SDLC Playbook”

Original text: The AI-Native SDLC playbook
Author: Louis Claxton (Anthropic Applied AI Team)
Published: August 21, 2026

On August 21, 2026, Anthropic published a long-form article titled The AI-Native SDLC Playbook on the claude.com blog. The article notes a 5-minute reading time, but the actual content is nearly 10,000 words in English, accompanied by over a dozen configuration and prompt examples. It resembles an operational manual more than anything else, organizing practices accumulated by Anthropic while deploying Claude Code for enterprise customers into a set of adoptable plays, structured according to the six stages of the software development lifecycle (SDLC).

This article deserves careful reading because the issues it discusses have already emerged in many teams: the speed of AI-generated code has increased, but the surrounding processes haven’t kept up. Below, I’ll outline its arguments, methods, and implicit assumptions in the order presented in the original text, and finally offer my own assessment.

I. The Problem Lies in the Process, Not the Code

The author starts with an observation. Over the past year, the speed at which organizations use AI to generate code has changed, but approval, review, handoff, and policy processes remain the same. Efficiency gains brought by tools like Claude Code are being consumed within these processes.

The author’s explanation of the traditional SDLC is this: the reason this workflow includes documentation, sign-offs, and meetings at every step is because it was born in an era when writing code was the most expensive and slowest part. PRDs, estimation ceremonies, and security reviews exist to force-align everyone’s understanding before a development cycle that lasts weeks or even quarters. Another implicit premise is that every step is performed by humans, so all control measures are designed with people in mind.

When the build phase shrinks from weeks to hours, the author lists three consequences:

• Bottlenecks shift. Planning, review, testing, and deployment flank the build phase and still operate at human speed.
• Control measures become disconnected from reality. Line-by-line review makes sense when humans write code, but it can’t keep up when agents generate most of the diff.
• Governance costs increase. Exceptions still require a committee that meets only weekly or monthly.

The security team is used as an example in the article. Security team staffing is based on human output. When agents double the code volume, either the review queue builds up or code goes live without sufficient review. Regulated organizations can’t accept either outcome, so security and policy checks must keep pace with agent speed.

The article concludes:

Whatever transformation the implementation phase has undergone, the entire SDLC must undergo an equivalent transformation.

II. Three Mechanisms of the AI-Native SDLC

The author defines the AI-Native SDLC as: retain the original control objectives, but replace the execution methods. After reading the entire article, it can be summarized into three interrelated mechanisms:

1. Processes shift from linear to circular.
   Problems discovered during the maintenance phase are directly written as new intent files and re-enter the planning phase, instead of “file a bug and wait for someone to handle it.”

2. Each stage ends by committing an artifact.
   Each stage commits an artifact to version control, and the next stage begins by reading that artifact:

   Stage	Artifact	Trigger for Next Stage
   Plan	intent.md	Product owner acceptance
   Design	spec.md	Product owner approval
   Build	plan.md, diff, tests	Engineer accepts the plan
   Test	Test output, CI check run	Checks pass
   Deploy	PR with review records	Code owner approves merge
   Maintain	Incident report → new intent.md	Control band is breached

   Early stages use Markdown because both product owners and agents can read and edit the same file; from the build phase onward, the artifacts are code and its records. The author believes this commit chain itself serves as an audit trail, capable of answering what requirements were raised, what the agent did, and who approved it.

3. Human attention focuses on the gates.
   When an artifact is accepted, the next phase is triggered. Initially, each step requires manual prompting by humans; the target state is for each accepted artifact to automatically trigger the next gate, with humans only reviewing issues flagged by agents at the gates.

   The article includes a comparison table between traditional and AI-native approaches. The “Deploy” row best illustrates the author’s thinking:

   	Traditional SDLC	AI-Native SDLC
   Deploy	Humans review every line of code, governance occurs during the review cycle, often inconsistently	Multi-layer agent reviews, human reviews reserved for regulated and critical code; governance enforced via hooks when AI acts

   The author also notes that most organizations fall somewhere between the two columns.

III. The Six Stages

Each play is structured the same way: what changed, prerequisites, required infrastructure, execution steps, governance considerations, leading indicators, and lagging indicators. This structure itself is worth adopting—it turns experience into something verifiable and measurable. Below is a breakdown by stage, focusing on specific methods and the author’s reasoning.

Stage 1 · Plan: Capture Intent with intent.md

In the traditional process, an idea goes through backlog, user story, story points, and refinement meetings—each handoff changes the responsible person. By the time it reaches the engineering team, it’s several layers removed from the original idea.

The article’s alternative is to have the initiator discuss directly with Claude and write it in their own words as intent.md, including:

• What is desired and why
• Constraints
• Which users and systems are affected
• Outstanding questions

Several implementation details are noted. Non-engineers use Claude via claude.ai or Cowork without needing to know git; submissions are handled via GitHub connectors. The simplest approach for a single product is to place an intent/ directory in the product repository so that intent files stay close to the derived code; a separate intent repository only makes sense when intents span multiple repositories. Templates can be written as skills, built by technical staff and signed off by the owner. The product owner reviews and corrects the agent-written intent.md, then submits it, accepting or rejecting via merging or closing reviews to leave a record.

Metrics. The leading indicator is the time from the first conversation to intent.md submission—the author expects this to drop from weeks to hours. The lagging indicators are the proportion of intent files accepted into the design phase and how many times intent.md is modified after spec.md is first submitted, which observes whether the intent is stable.

Stage 2 · Design: Merge Requirements and Design into a Single Conversation

Traditionally, requirements and design are two separate teams and phases: analysts turn ideas into requirements, and designers then parse requirements into designs. The author acknowledges this separation exists for accountability but believes it is slow and lossy.

The alternative is to have Claude read the accepted intent.md and, under the organization’s brand, security, compliance, and UX skill constraints, output both requirements and design specifications in one go, marking problematic areas. The product owner only reviews, not writes.

The article outlines an evolution path:

1. First, run this prompt manually.
2. Codify it into an organization-wide slash command.
3. Let the merging of intent.md in the intent directory act as a trigger, automatically generating spec.md via non-interactive tasks and submitting it as a PR.

By the third step, the product owner’s first involvement is to review this PR.

When reviewing, address the flagged concerns first—these are the issues an analyst would have escalated—and have the product owner and relevant policy owner resolve them one by one before the engineering team sees the spec. For frontend work, the author gives a specific flow: generate a prototype in Claude Design from intent.md, iterate until satisfied, then export to Claude Code for building. High-risk items require consulting the tech lead, but decisions are made by humans; the act of accepting the spec becomes the starting point for the build phase.

Governance. Policies are read and applied when writing specs, not discovered weeks later during reviews. The spec, the prompt that generated it, and the skill version in effect at the time are all under version control.

Metrics. The leading indicator is the time difference between intent.md and spec.md submissions; the lagging indicator is requirement rework after the build starts, measured by counting how many times spec.md is submitted after plan.md is first committed—easily checked via git log.

Stage 3 · Build: No Code Without an Accepted Plan

This is the longest stage, containing six plays.

Plan mode as the default starting point.
Engineers start sessions in plan mode, give spec.md to Claude, and have Claude ask questions in return to iteratively produce an implementation plan. The author’s acceptance criteria are: an engineer who hasn’t seen the conversation can complete the task based solely on this plan.

The plan is committed as plan.md, and subsequent PR reviews check the diff against it. When implementation deviates from the plan, update plan.md in the same commit; a hook can enforce synchronization.

The governance value here is that design review happens before code generation—changing direction at that point only requires updating documentation. Plan mode itself acts as an enforcement mechanism because if the plan isn’t accepted, Claude cannot modify files.

Auto mode
Once later plays have mature guardrails—adjusted CLAUDE.md, skills encoding policies, hooks that block unsafe operations, and tests that Claude can run on its own—auto-acceptance becomes the default for daily work.

The author describes the change: instead of watching the agent edit line by line and reviewing each action, shift to reviewing the artifact after long periods of autonomous operation. This is the foundation for later parallel work and closed-loop autonomy.

Legacy systems and sources of truth
This section is very pragmatic. Jira, ServiceNow, Figma, and change boards won’t disappear just because you’re going AI-native; auditors and regulators already recognize these systems, and other teams rely on them. The author provides three configurations:

Configuration	Approach	Suitable For
Repository as source of truth	Only commit references in legacy systems	Engineering-led organizations
Legacy system as source of truth	Markdown is the working copy; Claude reads records and writes results via MCP in the same session	Organizations with existing compliance traceability systems
Bidirectional links	All artifacts record IDs, all legacy records write commit SHA, acknowledging two sources of truth	Minimum standard during transition

CLAUDE.md
Positioned as what a new person needs to know on their first day: commands, conventions, architecture, common mistakes. The working rule is: if Claude makes the same mistake twice, write the correction in. The file should stay under one page because it’s fully read in every session, and outdated content wastes context.

Skills
The author’s rule of thumb is: institutional knowledge that must be applied consistently should be written as skills; content that belongs in CLAUDE.md or prompts should not be written as skills.

The article clearly defines the nature of skills: skills are controls, but advisory controls. They make Claude likely to apply policies when writing code, but nothing forces compliance. Policies that must always hold require something deterministic behind the skill, such as a hook that blocks operations or a review that re-checks at the PR stage.

Skills reduce violations; hooks make violations nearly impossible.

Hooks as build-phase guardrails
In the build phase, Claude mostly modifies files and runs shell commands, so hooks trigger most frequently here. Uses include:

• Blocking edits to protected paths (generated classes, frozen packages)
• Automatically running formatters and linters after file changes
• Keeping credentials out of diffs

Build-phase hooks must be fast, affecting only modified files; heavier checks go in commits or PRs. The author specifically notes that hooks requiring human approval should not be in the build phase, as they would put humans back on the critical path of all parallel sessions.

Parallel sessions and sub-agents
The difference between the two:

• Parallel sessions are separate Claude Code instances running independent tasks in their own worktrees, unaware of each other, with only the operating engineer as the common point.
• Sub-agents run within a session, with their own context windows and tool restrictions, suited for repetitive tasks like verifying the app runs, cleaning up unnecessary complexity, exploring the codebase and reporting.

The author suggests starting with two or three sessions, with the upper limit based on how many workflows a person can seriously review; add more only if you can keep up. Engineers’ work becomes orchestration, eventually becoming setup and monitoring loops.

Stage 4 · Test: Each Session Checks Its Own Work First

Feedback loops for Claude
The author’s argument is: in traditional processes, signals about whether code works come late—minutes later in CI, days later with testers, weeks later in production. When agents produce code, late signals mean one person has to check all output, making that person a bottleneck. Therefore, sessions must run their own tests, builds, and screenshot comparisons, iterating until they pass, so what engineers see has already been vetted.

Several specific practices are worth noting:

• Wrap verification as a single command that exits non-zero on failure.
• Make goals quantifiable so Claude can judge completion without asking humans.
• Fix bugs by writing failing tests first. Have Claude reproduce the bug as a test, confirm it fails for the expected reason, commit this test, then let Claude make it pass without modifying the test file. A test that exists before the fix and the agent cannot alter serves as proof the bug is fixed.
• Protect the loop itself. The agent fixing code shouldn’t be able to weaken checks on that code—use hooks to prevent test file edits in fix tasks.

The author also distinguishes feedback loops from validation sub-agents. Feedback loops run repeatedly throughout the task; validation sub-agents perform final checks in a fresh context window after the session considers itself done, so conclusions aren’t influenced by assumptions made during code generation.

Continuous evaluation in CI
The author calls eval the AI-native counterpart of phase-gate QA. Eval suites run when agent configurations change—model changes, prompt changes, CLAUDE.md changes, skill changes, hook changes all count. The reason is: these configurations guide the agent and should receive the same regression testing as code.

Approach:

• Collect 20 to 50 real tasks and acceptable outcomes from recent work.
• Write them as prompts plus checks (tests pass, lint clean, behavior unchanged, policy compliance).
• Run on a schedule and when configurations change.
• Use pass rates to gate configuration change merges.
• Turn every production incident into an eval in the suite.

The author also notes that eval suites are living; as models improve, some use cases lose discriminative power and need constant supplementation.

Stage 5 · Deploy: Agents Do Everything Before the Production Gate, but Cannot Cross It

The overarching principle of this stage is: agents can do everything before the production gate, but cannot cross it.

AI enters PR review
Claude both reviews others’ PRs and responds to reviews on its own PRs. All PRs get the same set of reviews, with findings ranked by severity; human attention shifts to whether changes align with the plan’s intent and whether risks are acceptable.

Tech leads write REVIEW.md in the repository root, divided into several passes:

• Bugs and logic errors
• Security vulnerabilities
• Consistency with spec.md and plan.md

同时定义什么算 Important、什么是 Nit、什么跳过。评审发现本身不批准也不阻塞 PR，分支保护仍然要求 code owner 批准。评审发现回流到 CLAUDE.md，第二次被标记的错误就写进去。作者指出职责分离得以保留，因为写代码的 agent 没有途径批准它。

Hooks as approval gates
Build-phase hooks only allow or block; hooks can also “ask,” pausing operations until designated humans approve—exactly what release gates need.

The approach is for engineering leadership, change management, and compliance to list required human approvals (change sign-offs, release authorizations, edits to protected paths), and platform engineers implement each gate as a hook. Team-level hooks go in .claude/settings.json; non-negotiable hooks go in managed settings that engineers cannot disable. When blocking, explain the reason and how to request approval.

Managed settings for regulated enterprises
The article provides a complete managed settings example, explaining each item’s governance implications:

Configuration Item	Purpose
permissions.deny	Keeps secrets out of context, blocks tool-layer network egress
permissions.allow	Pre-approves safe inner loops, avoids prompt fatigue from too many denies
disableBypassPermissionsMode + allowManagedPermissionRulesOnly	No engineer, project file, or command-line argument can relax rules
sandbox	Covers permission gaps: tool-layer WebFetch disable doesn’t block shell access to the network; OS-level domain whitelists cut off egress
failIfUnavailable	Rejects startup if the sandbox can’t start
credentials	Covers another gap: file tool deny can’t prevent shell in the sandbox from reading ~/.ssh
allowManagedHooksOnly, disableSideloadFlags, strictKnownMarketplaces, allowManagedMcpServersOnly	All skills, agents, hooks, and MCP servers must come from organization-approved plugin marketplaces
requiredMinimumVersion	Rejects startup below evaluated versions

The author says this configuration is a starting point for tailoring; every deny comes at the cost of capability, and the balance depends on the repository’s data classification.

CI/CD integration
Claude runs non-interactively in pipelines via claude -p, handling steps that require judgment. The evolution path has two steps:

• Read-only judgment: Analyze failed builds, summarize flaky tests, draft changelogs.
• Post-gate writes: Fix lint, update generated documentation, respond to @claude comments.

Everything the agent writes goes through branch protection as a PR—there’s no direct path to push to main. Execution is sandboxed, using short-lived scoped tokens, and by default not holding production credentials.

Deployment is exposed as a tool via MCP, tiered by environment: dev environments deploy freely; production environments are prepared for release by agents, authorized by release managers, and enforced by hooks. The author emphasizes that rollbacks should be the most rehearsed path in the pipeline, because the maintenance phase’s closed loop will invoke them when metrics exceed thresholds—they must be proven usable in advance.

Stage 6 · Maintenance: Closed Loop

The first five stages all require humans to initiate; this stage discusses Claude’s autonomous operation.

Core pattern of the closed loop
A deterministic script monitors production metrics, using rolling averages, standard deviations, and Western Electric rules to detect slow drifts and spikes—detection doesn’t involve the model. Response tiers are stored in a bands.yaml under version control:

Deviation	Action
1σ	Log only
2σ	Call Claude for diagnosis in read-only mode
3σ	Claude can act, but only open PRs to review gates or trigger pre-approved runbooks

Claude writes the diagnosis as intent.md in the planning stage format, entering the normal flow from there. Service owners triage the queue—deciding to fix now, schedule, or reject (rejecting adjusts control bands and reduces noise). After the fix goes live, add an eval for this incident.

The article gives three examples:

• CI test failure rate exceeds 3σ; agent isolates flaky tests or opens a rollback PR, decided by the review gate.
• Post-deployment 5xx rate exceeds 3σ and a deployment occurred in the time window; triggers the existing rollback pipeline.
• PR cycle time triggers drift rules; agent writes a report for engineering leadership.

The third example shows this mechanism works equally well for process metrics.

Periodic codebase scans
The author’s argument is that security scans are a point-in-time judgment of the codebase under a specific model—both conditions expire: the code changes weekly, and each model generation finds vulnerabilities missed by the previous one. So scans run on a schedule without human initiation, and findings go through the same gates as other changes. Fixable in one PR? Go with suggested patches plus review gate; architecture-level? Write as intent.md and start from the planning phase.

Deterministic checks stay in CI; model scans cover context-dependent vulnerabilities that those checks aren’t good at. This section introduces Claude Security, a public beta feature of Claude Enterprise, requiring a GitHub App installation and billed by consumption.

Claude Tag on-call
Claude joins Slack incident channels under its own identity, with each new incident having a first responder. Anyone in the channel can guide and participate in the response; channel history serves as the audit log. Small fixes go as PRs through the review gate; large issues are written as intent.md.

IV. Design Principles Throughout the Article

Viewing all six stages together, several principles recur—they represent the article’s thinking more than any single play.

Advisory controls and deterministic controls in two layers. Skills, CLAUDE.md, and prompts belong to the advisory layer, making correct behavior probable; hooks, sandboxes, branch protection, and managed settings belong to the deterministic layer. Any policy that “must hold” needs a deterministic layer behind the advisory layer.

Detection uses deterministic scripts, responses are tiered, and actions are gated. The model is only called after metrics exceed thresholds; what it can do is determined by the tier, and actions can only proceed via PRs or pre-approved runbooks.

Agents cannot approve their own work, nor weaken checks on it. The coding agent has no way to approve PRs; the bug-fixing agent cannot modify tests; final checks are done by a sub-agent in a new context.

Agent-guiding configurations are treated the same as code. CLAUDE.md, skills, hooks, and REVIEW.md all go into git, go through code review, and run regression evals.

Metrics come from existing systems. Nearly all metrics are derived from git timestamps, PR metadata, CI logs, OpenTelemetry exports, and incident trackers—no new measurement system is built.

Humans are not on the critical path of parallel sessions. No human approval hooks in the build phase; human approvals focus on release gates and artifact reviews.

V. Evaluation

Strengths
This article directly addresses concerns most important to regulated enterprises: after agents write most of the code, how are accountability, auditing, separation of duties, and change management handled? Its answer maps all these control goals to git artifacts, hooks, branch protection, and managed settings—rather than removing them. For readers in compliance, security, and platform engineering, this is more persuasive than vague “efficiency gains.”

Another strength is the pragmatic evolution path: nearly every play includes a step-by-step progression from manual to codified commands to automatic triggers; the legacy systems section acknowledges Jira won’t disappear; the managed settings section explicitly states it’s a starting point, not a recommendation.

Points to note
This is a product article. The author is from Anthropic, and the entire text uses Claude Code, Claude Design, Claude Security, Claude Tag, and Cowork as vehicles—Claude Security and Claude Tag are still in public beta and limited to Enterprise subscriptions. The framework is tool-agnostic, but implementation details are tied to the Claude ecosystem. When reading, separate principles from specific products.

Prerequisites are not light. The entire system depends on a test suite runnable with a single command, reliable builds, clear code ownership, and mature CI/CD. For legacy codebases with weak tests and unstable builds, “giving Claude feedback loops” is itself a major project—this isn’t discussed much in the article.

Human review is the implicit upper limit. The article repeatedly says parallel session counts are limited by review capacity, and human attention shifts to intent and risk. But when all PRs come with agent reviews and all tests are green, whether humans can maintain critical thinking rather than just going through the motions is an organizational behavior issue the article doesn’t explore.

The maintenance cost of eval suites may be underestimated. 20 to 50 evals, run on every configuration change, added for every incident—API consumption and maintenance effort are significant. The article only mentions needing an API key with a budget.

Automating from intent.md to spec.md is highly demanding for product organizations. Brand, security, compliance, and UX policies must first be written as skills with clear owners—many organizations already have gaps at this step.

Scope of applicability
Overall, this playbook is suitable for mid-to-large engineering organizations already using agentic coding tools and feeling that processes aren’t keeping up with code—especially in regulated industries. Its contribution is providing a complete vocabulary for translating old control goals into new mechanisms: artifact chains, gates, hooks, evals, closed loops. Even without Claude, this vocabulary can be borrowed.

Small teams or early products can adopt just a few plays—such as plan mode, CLAUDE.md, feedback loops, and AI reviews—without pursuing a complete closed loop.

Recommended Resources

https://x.com/shao__meng/status/2094027833505144919

https://x.com/shao__meng/status/2093990789584236857?s=20