Anthropic's AI-Native SDLC Guide, Explained Stage by Stage

AI changes everything, and that includes how we build software. Not just the coding part, the whole lifecycle: how an idea becomes a plan, how a plan becomes code, how we verify that what was built actually works, and how it gets reviewed, shipped and kept alive in production.

It's something I think about a lot, and I run my own experiments on it: how much planning an agent actually needs, how to review code when agents write most of it, where to run agents safely, and what a human still has to own.

So when Anthropic published their AI-native SDLC guide, a long PDF plus a free course, I went through it and turned it into a short deck. This post is the compressed version: every stage, what changes, how to do it, and the example files the course uses, in about 12 minutes. Where my own work touches a stage, I link it, so you have more paths to explore.

Short on time? I explain the whole thing in 7 minutes. ▶ Watch the video now

One thing before we start. This isn't "Anthropic knows best," and it's definitely not "I know best." Nobody has the final answer yet. The old way of building software was designed for a world where writing code was slow and expensive, and that world is gone. We should all be rethinking old paradigms and finding new ways to work, especially as more and more people become builders.

Code isn't the slow part anymore

Agents write code faster than anyone expected a year ago. But the approvals, reviews, handoffs and policies around the code? Most teams still run those exactly like before. The course names what happens next:

1. The bottleneck moves to the stages around build: planning, review and testing, deploying. Those still move at the speed of people.
2. The old controls stop fitting. Reading every line by hand worked when a human wrote every line. Nobody can keep up with an agent.
3. Governance gets expensive. Every exception still waits for a weekly or monthly committee.

There's one more problem I'd add. When building is this cheap, you can build almost anything, and a lot of it. The hard question stops being "can we build it?" and becomes "are we building what we actually need?" I dug into the research behind this in The 10x AI Engineer (post, video): agents multiplied the code and the pull requests, a lot of it now merges without anyone reading it, and the value moves to deciding what to build.

So the speed-up stalls. The rest of the course is about fixing that: changing every stage, not just the coding.

From a line to a loop

The old lifecycle is a line. Every stage has its own owner, the work moves between them as docs and tickets waiting for sign-off, and going back usually means waiting for the next release.

The AI-native version is a loop, with Claude in every stage. What holds it together is simple: every stage ends by committing a file to git, and the next stage starts by reading it.

Each handoff can eventually kick off the next stage on its own, though you start by running every step by hand. And the files become your history: who asked for what, what the agent built, and who said yes. People don't leave the loop. They spend their time at the checkpoints instead of starting every stage from zero.

The whole course on one page

If you look at one slide, make it this one. Plan becomes an intent.md instead of requirements by committee. Design becomes one session instead of two teams. Build runs on CLAUDE.md and skills instead of knowledge in people's heads. Test runs the whole way through instead of at gates. Deploy gets layers of AI review instead of people reading every line. And in Maintain, agents watch production and turn problems into a new intent.md.

Under all six sits the most important idea: people stay accountable for every call that needs judgment. Most teams are somewhere in the middle, and that's fine. You move one stage at a time.

Stage 1, Plan: an idea becomes intent.md

What changes. Today an idea goes into a backlog, becomes user stories, gets story points, survives a refinement meeting or two, and only then does anyone start. Every step hands it to someone new, so what reaches engineering is a few steps away from what the person wanted. In the AI-native version, the person with the idea talks it through with Claude, and the result is one file, intent.md, in their own words: what they want, why, and what limits apply.

How it works. Explain the problem like you would to a colleague. Claude asks what a good analyst would: who it's for, what's in and out, how you'll know it worked. It writes intent.md, you fix what it got wrong, you commit it, and the product owner takes it forward or closes it.

How to do it. The course's example is a made-up insurance company whose customers keep calling about their claims. Its intent.md fits on one page: the problem, the outcome they want (status, next step and a date in the portal), the limits, and one open question. Set up a template once and give intents one home in git, like an intent/ folder.

Try this first: turn one real idea from your backlog into an intent.md with Claude.

What I've built for this: plan-html, my open-source planner, is built around this interview step. The plan becomes an interactive deck you work through: answer, push back, reshape, then approve (video, post, repo). And do Kanban, stories, features or sprints still matter when an agent builds? I tested all of them across fifty builds in Which Planning Method Works Best With AI (video, post, experiment).

Stage 2, Design: one session instead of two teams

What changes. Traditionally, analysts turn the idea into requirements, then designers turn those into a design. Someone is accountable at each step, but it's slow, and something gets lost at every handoff. In the AI-native version, Claude takes the approved intent.md and writes one spec covering both. Your rules for brand, security, compliance and UX are written as skills, so the spec follows them as it's written, instead of you finding out in a review three weeks later.

How it works. Claude writes spec.md and flags anything that worries it, including spots where two of your rules contradict each other. The product owner reviews instead of writing, sorts out each flag with the rule's owner, and approves. That approval starts the build.

How to do it. Point Claude at the intent.md, tell it to apply your skills, and ask it to call out anything it can't satisfy. In the claims example, that catches a real clash: the UX rule says every status shows a date, the brand rule says never promise a payment date. Claude suggests "Estimated date" and names compliance as the owner. Two teams' rules, reconciled before a line of code exists.

Try this first: take one rule your team repeats in every review and write it as a skill.

What I've built for this: in plan-html, this is where I work out the acceptance criteria, the user intents and the boundaries before anything gets built (repo).

Stage 3, Build: plan first, then Claude builds

What changes. Traditionally, an engineer takes the design and starts coding, and the approach lives in their head. Nobody sees anything until the diff is done, when changing direction is expensive. In the AI-native version, nothing gets built until someone approves a plan. Claude writes it in plan mode, where it reads the code but can't change it, and the approved version goes into git as plan.md so every later stage can check against it.

How it works. Give Claude the spec in plan mode. It comes back with which files change, in what order, and which tests prove it. Push on it: what could break, which step is riskiest? A plan is done when someone who never saw your conversation could build from it. Then let Claude build, often in one go. The team's knowledge lives in CLAUDE.md (what a new hire needs on day one), skills (rules applied the same way every time) and hooks (hard stops, as code). And since builds are cheap, run two or three sessions in parallel, or build the same plan three times and keep the best version.

How to do it. In the claims example, the plan lists three files, the order of work, and one risk worth the whole exercise: the old claims system can only take 50 requests a second, which is why the status panel needs a one-minute cache. You'd never spot that in a diff. Remember it for Stage 5.

Try this first: start your next change in plan mode and commit the plan.

What I've built for this: does CLAUDE.md even matter? I ran 27 builds across 9 popular CLAUDE.md files in Karpathy's CLAUDE.md vs the Internet (video, post, experiment). And Workflows That Ship tests how much structure the build itself needs, from a one-shot to a full test-driven pipeline (video, post, repo).

Stage 4, Test: Claude checks its own work

What changes. Traditionally, you find out late whether code works: minutes for CI, days for a tester, weeks for production. With an agent writing the code, a person ends up checking all of it and becomes the bottleneck. In the AI-native version, Claude tests its own work before you see it, and keeps fixing until it passes.

How it works. Give Claude one command for tests and one for the build, plus a goal it can check without asking you, like "all tests in this file pass" or "the screen matches the mock." You get the passing output with the change, as proof. For a bug, the failing test is written and committed first, and Claude has to make it pass without touching it. And test the setup itself: keep 20 to 50 real tasks as evals and rerun them whenever CLAUDE.md, a skill or a hook changes.

How to do it. Add a short section to CLAUDE.md with your build, test and lint commands, an instruction to run them and paste the output before calling anything done, and my favorite rule in the course: when a test fails, fix the code, never the test.

My take: a self-check is the floor, not the ceiling. Add an adversarial check, a different model like Codex reviewing Claude's work, so the verdict doesn't come from the same assumptions that wrote the code. And get the work off your laptop: run it in a sandbox, a fresh cloud machine per task, where people can watch the session, review it and test it.

Try this first: put your build and test commands in CLAUDE.md, with one rule: fix the code, never the test.

What I've built for this: Sandboxes Are the New Dev Environment shows the setup I built at Reddy: a fresh cloud environment per task, spun up from a Slack message, where anyone can watch the agent work, review and test (video, post).

Stage 5, Deploy: AI reviews, people approve

What changes. Traditionally, a PR waits until someone has time to read all of it, the review is only as good as that person's week, and the queue keeps growing. In the AI-native version, every PR gets the same review passes, sorted by severity, and people move up a level: does this do what the plan said, and is the risk OK?

How it works. Claude reviews every PR for bugs, security and fit with spec.md and plan.md. A person judges intent and risk, a code owner still approves, and the agent that wrote the code can never approve its own work. Then a release gate, which is a hook: dev ships freely, staging asks first, production needs a named person. The agent can take a release up to the production gate, never through it. Later, Claude can also run inside your pipeline for judgment calls like triaging a broken build, always through the same gates.

How to do it. Turn on AI review, and write a REVIEW.md that says what to look for, what counts as important, and how many nitpicks are allowed. Tag @claude on a comment and it pushes the fix. In the claims example, the review catches that the status panel fetches fresh data on every render. The diff looks fine on its own, but plan.md said it must cache because of that 50-requests-a-second limit. Reviewing against the plan is what catches it. Finally, list the approvals you can't live without and turn each into a hook.

Try this first: pick one approval your process can't live without, and make it a hook.

What I've built for this: I built my own AI code reviewer as a GitHub Action, for under 2 cents a review, where the agent fixes what the review finds (video, post, repo). And when PRs explode, Reviewing AI PRs at Scale covers five levers for layering review gates so you don't drown (video, post, repo).

Stage 6, Maintain: problems restart the loop

What changes. Traditionally, maintenance waits for someone to notice: the midnight alert gets missed, the ticket sits, and the post-mortem fixes never reach the code because the next fire already started. In the AI-native version, a metric going out of range, a ticket or a schedule triggers Claude with nobody in between. It diagnoses, acts only through routes you approved, and writes what it found as a new intent.md. People still decide. They just don't have to be the ones who notice.

How it works. Detection stays boring on purpose: a plain script, no AI, watches one metric. How far it drifts decides what Claude may do. A small blip gets logged, a bigger one gets investigated read-only, and only the biggest lets Claude act, by opening a PR or running a rollback approved in advance. Either way it writes a new intent.md, and we're back at Stage 1. When the fix ships, the incident becomes an eval.

How to do it. Pick one metric with a stable baseline, like the error rate after a deploy. Keep the detection script and the three tiers in git. The claims example closes the story: after a release, errors on the status page jump almost ten times. The agent finds that the release turned off the one-minute cache, rolls back within two minutes, and writes an intent.md asking who wanted live status in the first place. Same cache, from Stage 3 to Stage 6. That's the loop.

My take: you don't need the full setup to start. Give an agent read access to your logs, metrics and alerts, and set it up with your own rules and runbooks. Have it explain what broke, suggest a fix and draft the next intent.md, with a human approving anything that ships. Even read-only, a midnight page becomes a diagnosis waiting for you in the morning.

Try this first: pick one metric and set three tiers: log it, investigate it, act on it.

Where to start

Six plays in the course depend on nothing else, so you can start any of them tomorrow: write an intent.md, start in plan mode, write a CLAUDE.md, turn a rule into a skill, give Claude a self-check, or turn one approval into a hook. Pick one, get it working, then add the next.

People stay accountable, and what's next

If you take one idea from the course, take this one: agents can do more of the work at every stage, but every decision that needs judgment still belongs to a person.

And remember where we started. Anthropic doesn't have the final answer, and neither do I. This will keep changing as the agents change, so keep questioning how you work.

In the next video, I run the whole loop on a real project, from scratch, in public, and show you the actual files. Until then, pick one play and try it this week. Watch the 7-minute video, and for the full detail, the free course is at academy.claude.com.