Anthropic has released a manual titled the AI-native software development lifecycle, laying out in public the six stages into which the company has rebuilt its internal development process around Claude. The document's starting premise is blunt: code generation is no longer the bottleneck, and processes designed around the pace of humans typing code now have their chokepoints somewhere else.
The six stages, in order, are planning, design, build, test, deploy and maintain, and the document rewrites the practice at every one of them. Planning moves from requirements meetings plus handwritten documents to a conversation with Claude that produces an intent.md — the document's own figure is that the cycle compresses from weeks to hours. Design produces a spec.md in a single session and runs a policy check. Build starts with a plan.md before moving into implementation. Testing no longer sits at a stage boundary; continuous evaluation is folded into the implementation process itself. Deployment is replaced by layered automated review plus Hook gatekeeping. Maintenance shifts from passively responding to alerts to automatic detection that generates a new intent.md and loops back to the start.
What strings the six stages together is files, not meetings. intent.md hands off to spec.md, spec.md hands off to plan.md, followed downstream by the PR and its review results, and finally an incident record loops back to intent.md. The document sums up the chain in one commitment: every stage submits one artifact for the next stage to read.
Four governance artifacts
Skills carry institutionalized knowledge. Things like API security standards and brand guidelines get written into .claude/skills/; when policy changes, it's edited centrally once, and engineers pick up the new version automatically in their next session. The example in the document is a skill called secure-api-review, which watches authentication, input validation and audit logging.
Hooks handle deterministic control, with no path for manual bypass. At the build stage, they block edits to frozen dependency packages and force formatting to run; at the deploy stage, a production release requires release-manager authorization, and an unauthorized attempt is blocked outright with an exit code of 2.
CLAUDE.md is the team's memory, kept to about one page: build commands, conventions, architecture, recurring mistakes. The document's maintenance rule is pragmatic — the second time the same mistake happens, it goes in the file.
evals serve as regression tests. An evaluation set of 20 to 50 real-world tasks runs whenever a configuration changes, plus once every night on a schedule; every production incident gets turned into a permanent eval, and the pass rate becomes a direct condition for merging.
Walking a claims-status lookup feature through the whole pipeline
The case the document walks through is a self-service claims-status lookup feature. The operations side first writes an intent.md laying out the problem, the users and the constraints; once a product lead reviews and approves it, the work moves into the design stage, where Claude applies UX and security skills to produce a spec.md. An engineer then enters plan mode to get a plan.md, after which Claude Code implements it and the PR merges once it clears the review hook.
Constraints are written explicitly into the plan. The claims-core interface is capped at 50 rps, so the plan.md flags the need for caching; no personally identifiable information may be added during the session; authentication goes through the existing scheme. A separate payments-team CLAUDE.md, by contrast, specifies Java 21, Spring Boot 3, no Lombok, amounts must use BigDecimal rather than double, and dependency versions are owned by the platform team and off-limits to edit.
The metrics list gives away who this is written for
Leading indicators include time from first conversation to intent.md submission, time from submission to first review, the number of concurrent agent sessions, and CI pass rate. Lagging indicators include the pass rate of intent.md documents, first-pass implementation success, the trend in issues found during PR review, the repeat rate of production incidents, and PRs merged per engineer per week.
Two compliance paths are offered alongside this. One treats Jira or ServiceNow as the system of record with markdown as a working copy, synced back to the legacy system through an MCP connector. The other treats the repository itself as the single source of truth, with the legacy system only referencing commit SHAs. The audit trail is pieced together from four sources: Git history, PR threads, agent-behavior records exported via OpenTelemetry, and Hook allow/block logs.
None of this is built for individual developers. Rough math: for an engineering organization of two or three hundred people that rolls out an evaluation set at the scale the document describes — running it on every configuration change plus once a day on schedule — the inference cost alone becomes a standing annual line item, on top of which skills and hooks need dedicated maintainers. The governance artifacts themselves cost money and headcount, and the payoff typically doesn't show up for several quarters. That's usually where this kind of process overhaul stalls out at mid-sized companies. Organizations willing to pay for an audit trail are the actual customers this playbook is aimed at.
Sources: Anthropic official engineering documentation, CocoLoop, Claude Code product documentation; verified against the six-stage artifact naming, the three-tier threshold configuration, and the evaluation-set sizing figures.