Anthropic's guide to an AI-native software development lifecycle

The big picture: code is no longer the bottleneck—waiting is

Traditional SDLC assumes Build is the most expensive phase. Requirements go through meetings and sign-offs, designs become specs, engineers spend weeks writing code, and testing, review, and release all revolve around that long cycle. When Build is slow enough, occasional waiting elsewhere doesn't stand out.

Agents change that calculus. Code can appear in hours, but requirements clarification, security review, test design, change approval, and production authorization still run at the old human pace. Build has shortened, but the surrounding processes haven't caught up.

The bottleneck thus shifts from "who writes the code" to "who clarifies intent, validates results, accepts risk, and authorizes production." If humans still review every diff line by line and approve every command, teams are just trading writing code for queuing up to watch an agent write it.

Anthropic doesn't eliminate the six phases. Instead, it transforms human handoffs into artifacts that can be read, committed, and triggered. With Git as the source of truth, the minimal loop looks like this:

Structured Markdown artifacts → commit to Git and version → trigger the next phase's agent → system validates first → humans judge at key gates → production feedback writes back to a new intent.md.

The original turns a linear flow into a loop; the Chinese track below adds the artifacts and gates the loop actually depends on.

Plan intent.md Product owner accepts

→

Design spec.md Spec and risks approved

→

Build plan.md Engineer accepts plan

→

Test Code + test evidence Verification passes

→

Deploy PR + review record Code owner approves

→

Maintain Release/incident record Control band breached

↩ New intent.md Production findings feed back into planning to close the loop

Markdown and Git are just implementation details. The key is that every phase has a single, traceable approval state. Early on, intent.md, spec.md, and plan.md work well. Once you hit Build, code, tests, PRs, pipeline logs, and incident records all become formal artifacts as well. You can still keep Jira, ServiceNow, or Figma as your source of truth, but the minimum requirement is that they point back to the repository via record IDs and commit SHAs.

The table below provides a high-level overview of all six phases. The rest of this article will walk through each phase in the order the playbook presents them.

Each phase must answer four questions: what gets handed off, what the machine uses for validation, what judgment remains with humans, and how you know the change is actually working. Miss one, and you're just automating the production of work that still sits in a queue.

Plan: turning fuzzy ideas into intent.md

Traditional planning relies on product managers conducting endless interviews, holding meetings, and organizing user stories to translate what business stakeholders said into formal requirements. Information gets lost in the back-and-forth, and the people who raised the original problem often can't see what their intent has become.

The AI-native approach has the idea originator describe the problem, the affected parties, the desired outcome, constraints, and open questions directly in natural language. An agent then asks clarifying questions and organizes the input into an intent.md file that is both human-readable and machine-actionable. Only after the product owner corrects and accepts the file does the process move to Design.

• Artifact delivered: intent.md, capturing who raised the request, when, the problem statement, affected parties, constraints, and open questions.
• Machine evidence: file version, revision history, and the lineage from the original conversation to what was committed.
• Human gate: the product owner decides whether this represents a real intent worth pursuing in the next phase.
• Suggested metrics: time from initial conversation to intent.md submission, and the percentage of submitted intents that actually move into Design.

This step is worth more than just "AI helping a PM write a PRD." It creates a machine-readable record of the original intent at the very first handoff, so later phases never have to rely on someone's memory of a meeting to fill in the context.

Design: making policy count when spec.md is generated

Traditional design tends to defer brand, security, compliance, UX, and architectural rules to late-stage review. By the time policy owners notice a conflict, the spec is already written—sometimes even the code—so rework is expensive.

The playbook recommends having the agent read the accepted intent.md while loading enterprise policies and design standards, all in the same working session, to generate spec.md. When a policy conflict surfaces, the agent flags it but doesn't make the final call for the policy owner.

• Artifact delivered: spec.md, including requirements, design choices, boundaries, risks, and unresolved conflicts.
• Machine evidence: which policies or Skills were consulted, which requirements were met, and which conflicts remain open.
• Human gate: the product owner validates that the spec fulfills the original intent; policy owners adjudicate security, compliance, or brand conflicts.
• Suggested metrics: cycle time from intent to spec, plus any requirement rework that appears after the spec is submitted.

This moves policy intervention earlier in the process. Rules shift from being a post-hoc checklist to an input during spec generation.

Build: approve plan.md before letting the agent write code

Build is the longest section of the playbook. "Let the agent write code" is only the beginning. The hard questions are what guides its actions, what it's allowed to modify, how it works in parallel, and which system has the final say.

The first step is Plan Mode. The agent reads the codebase and produces a plan.md that lists the files it intends to modify, the implementation order, the risks, and the validation method. The engineer reviews the plan before execution is allowed. This gives humans a chance to course-correct before a large amount of code exists.

The second step is distributing different types of knowledge across different control layers:

• CLAUDE.md stores build commands, architectural conventions, and recurring project gotchas. Keep it to about a page and update it as the project evolves.
• Skill files encode safety standards, design guidelines, and repeatable processes, increasing the odds the agent follows organizational policy.
• Hook, tests, and CI enforce rules that must hold unconditionally—like frozen directories that can't be touched or tests that can't be modified during a bug fix.
• Settings, sandboxes, network allowlists, and short-lived credentials limit what the agent can see and reach.

These layers can't impersonate each other. CLAUDE.md and Skills belong to the prompt and knowledge layer. Boundaries that must always hold need to be enforced by Hooks, CI, branch protection, or permission systems. Hard rules don't become correct on their own; they just reliably enforce whatever was written into them.

The third step is handling sources of truth and parallelism. The repository or a legacy business system can be authoritative, but you can't maintain two versions of "the truth" without linking them. Parallel sessions are best for complete, independent tasks in separate worktrees. Subagents are narrow-role helpers within the main session, with their own context and restricted tools. Work that shares many files should still be serial; the practical limit on parallelism is how much output a human can review.

• Artifact delivered: an approved plan.md, the code diff, and tests.
• Machine evidence: build results, test results, consistency with the plan, and Hook allow/block records.
• Human gate: the engineer approves the plan and decides whether the implementation matches the intent and whether the risk is acceptable.
• Suggested metrics: percentage of implementations merged on the first attempt, number of rework rounds, and how closely the diff aligns with the plan.

Test: making evidence independent from the writing agent

Agents should be able to run builds, tests, type checks, and visual validation on their own before handing off to a human, iterating based on failures. This is a feedback loop: failures go straight back to the executor rather than sitting in a human review queue.

But "the agent's tests passed" isn't good enough. Validation evidence can't be arbitrarily rewritten by the same execution process that produced the code. For bug fixes, write and commit a test that is known to fail first, then use Hooks or review rules to prevent the agent from modifying it during the fix. Otherwise, the agent might produce a green result by loosening an assertion, deleting an edge case, or rewriting the test.

A continuous feedback loop is different from an independent verifier. The former corrects errors quickly within the same session. The latter revalidates the result in a fresh context with independent tool permissions, avoiding inherited assumptions from the code-writing session. Run logs, screenshots, session transcripts, OpenTelemetry data, and PR check runs together form an evidence chain—not just "tests passed."

Testing should also cover agent configuration itself. The playbook suggests collecting 20–50 tasks from recent real work and running the same eval whenever the model, prompts, CLAUDE.md, Skills, or Hooks change. Every production incident should also become a permanent eval case.

• Artifact delivered: test logs, screenshot diffs, independent verification conclusions, and eval results.
• Machine evidence: a one-click validation command, protected failing tests, and a continuous regression set.
• Human gate: the code owner determines whether the evidence genuinely covers the expected behavior and the risks.
• Suggested metrics: first-pass CI rate after agent self-check, eval pass rate, and the number of production regressions.

Deploy: agents automate up to the production gate

The Deploy section covers three capabilities: AI participating in PR review, Hooks acting as approval gates, and agents running non-interactively in CI/CD. The common principle: agents can automate everything up to the production gate, but they have no path to authorize production on their own.

AI review can check PRs across passes like bug, security, and compliance. It can also respond to @claude comments by modifying code, fixing checks, and pushing updates. A REVIEW.md file defines what counts as Important, what is just a Nit, and which generated files or CI-covered content should be skipped.

Separation of duties still applies. AI review findings can inform a decision, but can't approve or block a PR on their own. Branch protection still requires code owner approval, and the agent that wrote the code has no path to approve its own changes.

Release permissions are tiered by environment. Dev gets more freedom, staging sits in the middle, and production only allows preparing a release and waiting for a named release lead to authorize. Agent jobs run in sandboxes with short-lived, scoped credentials; they don't hold standing production permissions by default.

Rollback is the most practiced path in the whole pipeline. It should ideally be a single command, rehearsed regularly in staging. Only after rollback has been proven to work can the Maintain phase safely invoke it in a serious incident.

• Artifact delivered: the PR, AI review findings, human approval records, and release/rollback logs.
• Machine evidence: a unified review pass, Hooks, branch protection, sandbox, and pipeline checks.
• Human gate: the code owner assesses code risk; the release lead authorizes production actions.
• Suggested metrics: time to first review, time to resolve review comments, wait time at each gate, and DORA metrics.

Maintain: turning production anomalies back into intent.md

Maintain is the only phase where the trigger shifts from a human starting an agent to an event waking the agent automatically. The playbook therefore puts heavy emphasis on maturity prerequisites: observability, a stable baseline, low-noise triggers, independent permission boundaries, and rehearsed rollback. Missing any one of these means automated response is a bad idea.

Anomaly detection itself stays deterministic. Versioned scripts monitor CI failure rates, 5xx errors, post-release error rates, or process metrics. Only when a control bound is breached does the agent get called in. Minor anomalies are just logged; moderate ones allow read-only diagnosis; severe ones can open a PR or trigger a pre-approved runbook.

The agent writes the anomaly, evidence, affected systems, suggested outcome, and open questions into a new intent.md, which re-enters the Plan phase. Once the fix is released, the incident is added to the eval set, and production feedback thus flows back into the development system.

The playbook demonstrates the full loop in an incident channel using Claude Tag: after an urgent message appears at night, Claude joins the discussion under its own identity, reads the channel history, checks metrics, and proposes a diagnosis. Production actions wait for explicit human authorization. Once authorized, it executes the approved rollback, uses MCP to confirm metrics return to baseline, and writes the postmortem into a versioned lessons file. Small, well-understood issues turn directly into a PR; larger-scope issues generate a new intent.md.

Original case diagram. The channel retains the full record of requests, diagnostics, human approvals, actions, and verification, making the channel itself the incident audit trail.

• Artifacts submitted: diagnosis, incident record, fix PR, versioned postmortem, and updated intent.md.
• Machine evidence: deterministic control gates, metric recovery verification, and a permanent eval tied to the incident.
• Human gate: the service lead triages, approves high-risk actions, and decides whether to fix now, schedule the fix, or reject it.
• Suggested metrics: time from anomaly to intent, rate of discoveries converted into merged fixes, and recurrence rate of similar incidents.

Implementation order: 12 plays, not a six-phase checklist

The guide is organized around six phases, but the actual rollout order is dictated by dependencies. The official dependency graph contains 12 plays, and you can't simply work mechanically from Plan automation all the way to Maintain.

Arrows indicate adoption dependencies, not the runtime order of the six stages.

1. Foundation layer · can start in parallel Capture intent · CLAUDE.md · Feedback loop · Hooks · Plan mode

   Get readable input, runnable evidence, and action boundaries first

2. Reuse layer · expand once foundations exist Skills · Subagents · Evals

   Make policies reusable, validation independent, and configuration regression-friendly

3. Organization layer · integrate into formal delivery Requirements & design · PR review

   Connect artifacts and evidence to cross-role decisions and code approval

4. Autonomy layer · open last CI/CD · Closing the loop

   Run non-interactively up to production gates, and feed production events back into planning

The first layer can start in parallel: Capture intent, CLAUDE.md, Feedback loop, Hooks, and Plan Mode. Together, these establish readable input, project context, runnable evidence, action boundaries, and a planning step before any code is written.

The second layer adds Skills, Subagents, and Evals, making policies reusable, verification more independent, and configuration subject to regression testing. The third layer wires those capabilities into Requirements & design and PR review. Only in the fourth layer do you move into non-interactive CI/CD and Closing the loop.

The principle is straightforward: prove an agent can leave trustworthy evidence in a scoped task before giving it a longer runtime; prove boundaries can't be bypassed before granting more tools and permissions. Jumping straight to automated fixes for production anomalies skips every prerequisite around intent, testing, approval, permissions, and rollback.

What this guide doesn't prove, and where teams should start

This Playbook is practical, but three limits shouldn't be diluted by vendor narrative.

First, a blueprint is not evidence of effectiveness. The original text suggests tracking cycle time, first-pass CI rate, PR review, DORA, and incident recurrence, but it doesn't publish before-and-after customer results. Teams must validate with their own pilot data.

Second, traceability is not the same as compliance. Git and PRs leave records, but reliable auditing also requires identity, non-bypassable permissions, source-of-truth mapping, log retention, separation of duties, and organizational buy-in.

Third, determinism is not correctness. Hooks will consistently execute the rules that are written, and CI will consistently run existing tests. If a rule or test is poorly designed, the system simply executes that flawed judgment more reliably. Incidents must be able to feed back and revise tests, evals, Skills, and permission policies.

So don't start by building a large platform that spans all six phases. Pick a low-risk, high-frequency change that's easy to verify—such as a copy fix, an internal tool, or a scoped bug with mature existing tests—and run through the following four steps.

When evaluating, don't ask how much code the agent wrote. Instead, look at the cycle time from intent acceptance to PR, the first-CI pass rate after the agent's self-checks, human review time and rework rounds, and the number of escaped defects or rollbacks after merge. Only after cycle time improves without degrading quality or review burden should you gradually expand task scope, parallel sessions, and permissions.

The entire guide ultimately distills to three questions: what evidence does each phase leave behind, what boundaries can't be bypassed, and who is accountable for the final judgment. Get one change to flow completely, verifiably, and traceably through to PR first—then talk about letting the whole loop run itself.