Anthropic's AI-Native SDLC Playbook, in Brief

aidevopsculturesecurity

What Anthropic Is Arguing

Anthropic’s AI-Native SDLC Playbook is best read as an argument about bottlenecks. If agents can produce code faster than the old development process can absorb it, then code generation stops being the main constraint. The surrounding system becomes the constraint: planning, requirements, design, testing, review, deployment, monitoring, and incident learning.

That matters because the tempting failure mode is obvious. A team adopts an agentic coding tool, watches implementation time collapse, and then sends larger, faster, less familiar diffs into the same review queue, the same QA process, the same deployment controls, and the same production feedback loop. The local speedup turns into system pressure. Review gets slower. Governance gets noisier. Production risk rises. Everyone becomes very impressed with the tool and slightly worse at shipping.

The course’s answer is to redesign the whole loop so agents execute and check bounded work, while humans direct priorities, resolve ambiguity, own accountability, and approve consequential decisions. It is not a manifesto for removing humans. It is a plan for using human attention less wastefully.

This is also why the playbook belongs next to our existing Cairns on AI-native migration, quality gates, CI/CD maturity, and evals. The same pattern keeps reappearing: AI changes the rate at which work can be proposed, so the organization has to change the way work is constrained, proven, accepted, and learned from.

The Artifact Chain

The connecting mechanism in the course is a versioned record. Each stage leaves an artifact that both people and agents can read. The next stage begins from that artifact instead of reconstructing intent from memory, Slack, a half-written ticket, or the agent conversation that disappeared two compactions ago.

The first artifact is intent.md. Its job is to capture the problem, affected users, desired result, constraints, and unanswered questions in the originator’s terms. It is deliberately not a giant requirements ceremony. It is the smallest artifact that keeps an idea from mutating at every handoff.

Then the agent develops that intent into spec.md, covering requirements and design. A human checks whether the spec solves the actual problem, whether it respects policy and product constraints, and whether any ambiguity has been papered over. This is where product judgment stays product judgment, instead of being silently delegated to whichever prompt happened to run next.

Then comes plan.md. The plan should name the files likely to change, the order of implementation, alternatives considered, risks, and tests. This is the point where the team challenges the approach before code exists. Once code exists, review gravity pulls everyone toward “is this implementation acceptable?” Planning review keeps the sharper question visible: “is this the right implementation to attempt?”

After that, the chain continues through code, tests, PR review, deployment evidence, production findings, and new intent created from incidents or monitoring. The record is useful because it preserves why each stage happened, who approved the consequential choices, and what evidence the next stage can trust.

Where Human Judgment Moves

The human role does not vanish; it moves. Humans stop spending so much time as slow transcribers of implementation detail and spend more time as directors of intent, risk, and acceptance.

That shift starts with the problem statement. A person decides what pain matters, who is affected, what success means, and what is out of scope. The agent can ask useful questions and produce a better first draft, but it cannot decide organizational priority by itself. Or, more precisely, it can produce an answer. It should not be allowed to become the authority.

In design, humans resolve policy conflicts and domain ambiguity. In planning, humans challenge what could break, which files should not be touched together, what test proves the change, and whether a simpler option was ignored. During review, humans judge intent and blast radius while automated and AI-assisted checks handle repeated mechanical passes. In deployment, humans decide when autonomy is earned and where production authorization stays manual.

This is the same operating shape described in From Plan to Pull Request: the agent can do the typing, searching, scaffolding, and local iteration, but the human has to keep control of scope, acceptance, and risk. Otherwise the team has not built an AI-native SDLC. It has built a very fast ambiguity amplifier. A marvel of modern machinery. Pointed at fog.

The Operating Manual

The course puts surprising weight on the small operating manual. For Claude Code, that means CLAUDE.md; for other harnesses it may be AGENTS.md, a repo-local instruction file, or a tool-specific equivalent. The shape matters more than the filename.

The file should stay short and maintained. It should tell the agent the commands that prove work, the architecture it must respect, the conventions that are not obvious from syntax, and the recurring mistakes the team has already seen. It should not become an attic. Stale instructions are worse than missing instructions because they create false authority.

The course’s practical rule is useful: add a correction when the same mistake happens twice. Once may be noise. Twice is a pattern. Capture the pattern close to the work.

Skills are the next layer up. They turn reusable expertise into something agents can invoke: security review routines, design-system conventions, release-check workflows, incident investigation patterns, organizational norms. They are institutional memory in executable reading form.

But the course is careful about the boundary between advice and enforcement. Instructions are advisory. Mandatory rules need executable controls: tests, linters, hooks, permissions, approval gates, branch protection, environment policies, or managed credentials. This is exactly the line Quality Gates keeps drawing. If the rule must hold, make the system check it.

The Verification Loop

Agentic development needs feedback tight enough that the agent can correct itself before the human reviewer becomes the test harness. That means runnable tests, builds, visual checks, smoke tests, and clear local commands. For bugs, the course’s advice is the old discipline with higher stakes: establish a failing regression test first, fix the bug, and protect the test from being weakened.

Independent verification matters too. A fresh verifier can read the diff, spec, plan, and test evidence without inheriting the implementation conversation’s assumptions. That gives the team a second pass against exactly the failure mode agents are prone to: sounding coherent while carrying forward an early wrong turn.

The playbook also expands “testing” to include the agent configuration itself. Prompts, skills, models, hooks, and permissions are now part of the delivery system. If changing them can change outcomes, they need representative eval tasks with known acceptable results. Production incidents and review misses should become eval cases, not just anecdotes.

That is the bridge to Evals Are Production Tests. Traditional tests prove properties of the product. Agent evals prove properties of the work-producing system: source choice, policy compliance, refusal behavior, task classification, escalation, review quality, and whether the right artifact changed.

The useful feedback loop is therefore layered:

• Product tests prove the code still behaves.
• Build and quality gates prove mechanical standards still hold.
• Visual and integration checks prove the user-facing path still works.
• Fresh verification proves the implementation matches the intended work.
• Agent evals prove the agent setup still handles representative tasks.

This is more machinery than “ask the model to be careful.” Regrettably, that is the point.

Review, Deployment, And Production

The course treats review as a focusing tool. AI review can scan for bugs, security issues, test gaps, spec mismatch, plan mismatch, and repeated mechanical concerns. That lets human reviewers spend less time finding formatting nits and more time judging whether the change should exist, whether the design is acceptable, and whether the risk is understood.

The course does not argue for dropping code-owner approval. It argues for using automated and AI-assisted passes before human review so the human review starts with ranked findings and cleaner evidence. Let the agent address feedback. Let branch protection preserve ownership. Let humans decide whether the result is acceptable.

Deployment autonomy follows the same gradient. Start by letting agents diagnose pipeline failures. Then allow fixes through PRs. Later, consider constrained actions with sandboxing, limited credentials, environment-specific permissions, and explicit approval gates. Production authorization should remain human until the recovery path is tested, observed, and boring.

The production loop closes when monitoring and incidents feed development directly. Deterministic monitoring detects anomalies. AI investigates, summarizes evidence, proposes fixes through the existing gates, or executes pre-approved runbooks where the action is already bounded. Findings become new intent.md work. Incidents become regression tests and eval cases.

CI/CD Maturity covers the same discipline from the deployment side: increase autonomy only when verification, observability, rollback, and ownership have caught up. The playbook’s contribution is to show how that deployment discipline connects back to intent and planning instead of living as a separate release-engineering ritual.

How To Adopt It Incrementally

The safest reading of the playbook is incremental. Do not replace every ticketing system, requirements process, release control, and incident workflow because a course diagram contains a loop. The course itself allows existing systems to remain, provided each artifact has a clear authoritative home.

Start where the current workflow already hurts. If ideas lose meaning before engineering sees them, start with intent.md. If implementation frequently veers away from the agreed approach, start with plan.md review. If agents repeat the same repo mistakes, trim and maintain the operating manual. If review is overloaded, add AI review passes and ranking. If production incidents recur, turn them into regression tests and eval cases.

The sequence can be modest:

1. Choose one recurring lane of work.
2. Name the authoritative home for intent, spec, plan, PR evidence, and production findings.
3. Add the smallest useful template for the missing artifact.
4. Add one executable check where a mandatory rule is currently only advice.
5. Run the loop on real work and improve it only after the friction is visible.

That is Gall’s Law doing its dreary little miracle again. Build the simple thing that works. Then let it grow where reality asks for more.

Summary

1. AI coding speed changes the bottleneck. Planning, review, testing, deployment, and maintenance have to accelerate without surrendering accountability.
2. The artifact chain is the core mechanism. Intent, spec, plan, code and tests, review, deployment, and production findings should form a versioned record.
3. Humans still own judgment. Agents can draft, execute, check, and summarize, but humans decide priorities, ambiguity, policy conflicts, risk, and consequential approvals.
4. Instructions are not enforcement. Keep the operating manual small and current, turn reusable expertise into skills, and turn mandatory rules into checks or gates.
5. Feedback loops have to cover both product and agent behavior. Tests, builds, visual checks, fresh verification, and evals all protect different parts of the system.
6. Autonomy should expand gradually. Diagnose first, fix through PRs next, automate only where credentials, rollback, observability, and approval boundaries are ready.

Discussion Prompts

• Where does our current work most often lose intent: before implementation, during implementation, during review, or after production incidents?
• Which rule do we currently express as an instruction even though it really needs a test, hook, permission boundary, or approval gate?
• If we piloted this on one Constructured workflow, which artifact would give us the fastest evidence: `intent.md`, `spec.md`, `plan.md`, regression tests, agent evals, or deployment runbooks?

References

1. Anthropic Claude Academy: The AI-Native SDLC Playbook introduction - The course framing: code generation speed moves the bottleneck into planning, review, deployment, and maintenance.
2. Capture as intent.md - The planning play that turns an idea, ticket, or incident into a human-readable, versioned intent artifact.
3. Requirements and design - The design play that develops intent into a requirements and design artifact for human review.
4. Claude Code plan mode as the default starting point - The implementation-planning play: files, order, risks, alternatives, and tests before code generation.
5. The CLAUDE.md - Guidance on keeping repo-level agent instructions small, current, and useful.
6. Skills as institutional knowledge - The play for packaging recurring expertise into reusable agent capabilities.
7. Hooks as approval gates - The control layer for allow, block, or approval-required actions around agent behavior.
8. Parallel sessions and subagents - The play for splitting independent work while keeping review capacity as the governing limit.
9. Give Claude a feedback loop - The testing and self-correction play for builds, tests, and visual checks.
10. Continuous evals in CI - The play for regression-testing model, prompt, skill, and configuration behavior.
11. AI in the PR review loop - The review play for using automated findings to focus human attention.
12. CI/CD integration and deployment - The deployment play for moving from diagnosis to constrained automation.
13. Closing the loop on metrics - The maintenance play for turning production signals into new intent and regression coverage.