Area 73 logo

The AI-native SDLC, distilled

ai-codingsdlcclaude-codeartificial-intelligencebest-practices

Anthropic has published The AI-Native SDLC playbook, a long (and very enterprise) guide to rebuilding the software lifecycle now that agents write most of the code. Here it is distilled: the concepts and the actions, stage by stage.

Code is no longer the bottleneck

Agents write code in hours. The processes around it still run at human speed.

With AI, build shrinks from weeks to hours, but plan, design, test and deploy keep their human-speed lengthtime →TraditionalAI-nativePlanDesignBuildTestDeployPlanDesignTestDeploybuild: hoursthe rest, at human speed

When build collapses, three things happen:

  • The bottleneck moves to either side of build: planning, review/testing and deploying.
  • The controls stop fitting. Reviewing every line by hand made sense when a person wrote it, not when an agent does.
  • Governance gets more expensive: exceptions still go through committees that meet weekly or monthly.

From a line to a loop

The idea holding the whole playbook together: every stage ends by committing an artifact the next one reads, and that commit is what triggers it.

The six stages form a loop: each commits an artifact (intent.md, spec.md, plan.md, tests, PR) and maintenance feeds what it detects back as a new intent.md1 · Plan2 · Design3 · Build4 · Test5 · Deploy6 · Maintainintent.mdspec.mdplan.md + difftests · evalsPR + reviewalert → intent.mdevery stage ends in a committhat triggers the next onehumans at the gates
  • The chain of commits is the audit trail: who asked for what, what the agent produced and who approved it.
  • At first you kick off each step by hand. The end state is every accepted artifact firing the next gate.
  • People remain accountable for every judgment call, but their attention concentrates at the gates: they review what the agent flagged instead of starting each stage from scratch.

1. Plan: intent.md

Concept: the idea is captured once, in its originator’s own words, as a versioned file. No detour through backlog entries, story points and refinement meetings that drift it away from what was meant.

Actions:

  • Whoever has the idea brainstorms with Claude until it’s concrete: scope, users, constraints and what success looks like.
  • Claude writes it up as intent.md using the organization’s template (problem, outcome, who’s affected, constraints, open questions). The template works best as a skill.
  • It lives in an intent/ folder in the repo, next to the code it will turn into. The PO reviews it and accepts it with a merge.

2. Design: spec.md

Concept: requirements and design merge into a single session. Policy (brand, security, compliance, UX) is applied while the spec is written, not in a review weeks later.

Actions:

  • The PO opens a session with the organization’s skills and the intent.md, and asks for the spec with concerns flagged.
  • Resolve the flagged items first, with each policy’s owner, before engineering sees the spec.
  • Commit spec.md next to intent.md: what was asked for and what was decided.
  • Then automate it: a slash command first; later, a job that runs when the intent.md merges and opens the spec as a PR.
Artifact chain: the idea becomes intent.md, then spec.md with the organization’s skills, then plan.md in plan mode; each step has a human gateideaticket · alertcodebrainstorm+ org skillsplan modeintent.mdspec.mdplan.mdhuman gate →reviewedby the POPO + eachpolicy ownerapproved bythe engineerreviewedin the PR

So far, nobody has written a line of code.

3. Build: plan, context and guardrails

Concept: nothing gets implemented without an accepted plan, institutional knowledge becomes files the agent reads, and guardrails run as code, not as habits.

Actions:

  • Plan mode by default. Hand it the spec.md, let it interview you, and ask what the change could break and which options it discarded. Iterate until someone outside the conversation could implement it from the plan alone. Commit it as plan.md. With a solid plan, implementation is often a single pass.
  • A CLAUDE.md under one page. Run /init and cut it down to what a new joiner needs on day one. Rule: if Claude makes the same mistake twice, it goes into CLAUDE.md.
  • One skill for each piece of knowledge that’s applied inconsistently today (a security standard, an API convention, a brand rule), with an owner who signs off its changes.
  • Hooks for whatever allows no exceptions: protected paths, formatter and linter after every edit, credentials kept out of the diff. Fast, and scoped to the file that changed.
Three control layers from least to most deterministic: CLAUDE.md gives context, a skill advises and a hook guaranteesmore deterministicCLAUDE.mdskillhookconventions · commands · common mistakesversioned policy with an ownerscript before every action: allow · ask · blockcontextadviceguarantee

The skill makes violations rare; the hook makes them close to impossible.

  • Parallel sessions: two or three, each in its own worktree (claude --worktree feature-auth). The ceiling isn’t your machine, it’s how much you can review properly. Repeated jobs become subagents in .claude/agents/.
One engineer steers several parallel sessions, each in its own worktree, with subagents for repeated jobs such as verifying, simplifying or researchingparallel sessions · one worktree eachsubagentsengineersteers and reviewsclaude –worktree feature-authclaude –worktree fix-rate-limitclaude –worktree docs-apiverifiersimplifierresearcher
  • Auto mode: once all of the above has matured, it stops being the exception for routine work (tight spec, small blast radius, code the tests already cover). You no longer watch every edit: you review artifacts at the end of longer sessions.

4. Test: let the agent correct itself

Concept: every session checks its own work before a person sees it. And the configuration steering the agent gets tested just like the code it writes.

Feedback loop: Claude implements, verifies with tests, build or screenshot and, if it fails, fixes and repeats; only work that already passed reaches a personimplementsverifiestests · build · screenshotpasses?reaches a humanalready verifiedyesno → fix and repeat

Actions:

  • A single command per check (make test, npm test) that exits non-zero on failure, listed in CLAUDE.md with an example of healthy output.
  • Measurable targets so it doesn’t have to ask you: “all tests in test_status.py pass”, “the screenshot matches the mock”.
  • For bugs, the failing test comes first: have Claude reproduce it, confirm it fails for the right reason and commit it. Then ask for the fix without touching the test, with a hook that blocks edits to test files.
  • For UI, give it a browser or screenshots and the mock. Two or three rounds is normal.
  • “Done” includes green tests, with the output shown.
  • Evals in CI: 20 to 50 real tasks with their accepted outcome, run on every change to CLAUDE.md, skills or hooks. Every production incident leaves a new eval behind.

5. Deploy: two-way review and gates as code

Concept: the agent does everything up to the production gate and nothing past it.

Actions:

  • Claude in PR review: every PR gets the same passes (bugs, security, and compliance with spec.md and plan.md), defined in a REVIEW.md. The human judges intent and risk, and approval stays human: the agent that wrote the code cannot approve it.
  • An @claude on a comment and Claude fixes it and pushes. Anything review flags a second time goes into CLAUDE.md.
  • Hooks as gates: list the approvals that must survive (change management, release authorization) and turn each into a hook that allows, asks or blocks. The non-negotiable ones go in managed settings nobody can switch off locally.
  • CI/CD: start with read-only steps using claude -p (triage a broken build, summarize a flaky test, draft the changelog). Then write steps, but always landing as a PR. Sandboxing, short-lived tokens, and deploy, status and rollback exposed through MCP.
  • A rehearsed rollback: a single command the agent can run, exercised regularly in staging.
Autonomy by environment: in dev the agent deploys freely, in staging it has intermediate autonomy, and in production it prepares the release but a person authorizes it past a gategatedevstagingproductionthe agent deploysfreelyintermediateautonomythe agent prepares,a human authorizesagent autonomyagent autonomyagent autonomythe agent acts up to the production gate, never past it

6. Maintain: closing the loop

Concept: a trigger (an alert, a ticket, a message, a schedule) invokes Claude with no person in the path, and whatever it finds re-enters as intent.md. People no longer start the work: they triage and review it.

Control bands: a metric oscillates within 1, 2 and 3 sigma; at 1σ it is only logged, at 2σ Claude diagnoses read-only, and on breaching 3σ it proposes a PR or a rollback3σ → proposesPR or rollback2σ → diagnosesread-only1σ → logsnothing elsedeterministic detection; Claude only steps in when a band breaks

Actions:

  • Deterministic detection: a script watches metrics with control bands (a bands.yaml). Claude only steps in when a band is breached, and the tier decides what it may do.
  • Examples: CI test failures above 3σ → quarantine the flaky test or open a revert PR; 5xx spiking after a deploy → trigger the rollback.
  • Scheduled security scans (weekly is a good default): every finding goes through the same PR gate, and anything that doesn’t fit in one PR becomes an intent.md.
  • On call in the channel: with Claude Tag in Slack, Claude is the first responder to an incident. The thread is the audit trail: request, diagnosis, human authorization and fix.

How to know it’s working

Every play is measured with data you already have: git timestamps, PR metadata, the incident tracker and DORA metrics. Three examples:

  • First conversation to committed intent.md: from weeks to hours.
  • Share of changes that merge on the first pass.
  • Regressions caught in CI versus regressions found in production.

Where to start

You don’t need to transform everything at once. The plays that depend on nothing are the way in.

Adoption order: first CLAUDE.md, the feedback loop, hooks, skills and intent.md; then spec.md, plan mode, parallel sessions, evals and PR review; last, agentic CI/CD and closing the loop1 · start here2 · next3 · lastCLAUDE.mdfeedback loophooksskillsintent.mdspec.mdplan modeparallel sessionsevals in CIPR reviewagentic CI/CDclose the loop

My short list:

  1. A CLAUDE.md in the repo, under one page.
  2. One verification command and the rule that nothing is done without green tests.
  3. Plan mode as the starting point, with the plan.md committed.
  4. A hook for the non-negotiables: tests during fixes, protected paths, production.
  5. A skill for the policy that’s applied worst today.
  6. PR review with Claude and a REVIEW.md.
  7. Only then, agentic CI/CD and closing the loop.

If you already live in Jira, Figma or a requirements tool, you don’t have to throw it out: declare one source of truth per artifact. At a minimum, the ticket ID in the file and the commit SHA in the ticket.

What I take away

The loop keeps running. Human judgment stays above it.

The playbook isn’t about writing code faster (that already happened); it’s about turning the process into versioned files the agent reads and the gates into code that runs. Nearly everything it proposes fits a small repo too: this blog already has its CLAUDE.md, git hooks that stop pushes to master, and tests the agent runs before calling anything done.