AI-Native SDLC
Definition
The AI-native SDLC (also agentic SDLC, AI SDLC) keeps the old control objectives of software delivery and replaces the enforcement. The linear flow becomes a loop with an agent embedded at every point, and each stage hands to the next automatically instead of through a manual handoff.
The premise: code is no longer the bottleneck. Teams generate code at a speed unthinkable a year ago while the approval gates, reviews, and handoffs around it are unchanged — so the process, not the typing, is what now limits delivery.
Core Ideas
The six stages and what shifts
| Stage | Traditional | AI-native |
|---|---|---|
| Plan | requirements by committee, workshops, sign-offs, written up by hand | Claude synthesises pain points from the sources into intent.md — human readable, machine actionable |
| Design | spec written by analysts, parsed by designers | requirements and design compressed into one working session, standards encoded as skills, versioned in git |
| Build | tests and code handwritten, docs written after | tests and code generated; institutional knowledge lives in versioned CLAUDE.md files and skills |
| Test | QA gates at stage boundaries | continuous evals woven through implementation |
| Deploy | humans review every line, governance in review cycles | layered agentic review, human review reserved for regulated and critical code, hooks as approval gates |
| Maintain | humans watch production | agents monitor deployments; a breached control band is diagnosed and written back as a new intent.md |
The artifact chain is the whole design
Every stage ends by committing an artifact and the next stage begins by reading it: intent.md → spec.md → plan.md → the diff and its tests → the PR with its review findings → the incident record. Early stages use markdown because a product owner and an agent can both read and act on the same file; from Build onward the artifact is code and its records.
The chain of commits is also the audit trail — who asked for what, what the agent produced, who approved it. And it is what closes the loop: an accepted intent.md fires the design pass, an approved spec.md fires plan mode, a merged PR fires the pipeline, a breached control band in production writes the next intent.md.
Human attention concentrates at the gates, reviewing what the agent flagged rather than starting each stage from scratch. Humans stay accountable for every decision requiring judgement.
Plan — capture as intent.md
The originator describes the problem to Claude in their own words; Claude asks the questions an analyst would (scope, users, constraints, success); the result is written as intent.md from a team template encoded as a skill; the originator corrects it and commits.
This kills the broken telephone problem, named by Heidi’s co-founder: an idea used to pass from originator → PM → designer → engineer, losing its essence at each hop and taking weeks. Non-git contributors commit through a version-control connector, so the artifact home stays a folder in the product repo.
Build — CLAUDE.md, skills, hooks
CLAUDE.mdcarries what a new joiner would need: conventions, commands, architecture, and the mistakes the team sees most. The working rule is when Claude makes a mistake twice, the correction goes intoCLAUDE.md. Keep it under a page — it is read at the start of every session, so anything stale spends context for nothing.- Skills are institutional knowledge made operational: explicit, version-controlled, applied broadly, updated centrally. The rule of thumb — write a skill for institutional knowledge that must be applied consistently; don’t write one for what belongs in
CLAUDE.mdor a prompt. - Hooks are the deterministic layer behind an advisory skill. Build-phase hooks block edits to protected paths, run formatter and linter after edits, keep credentials out of the diff. They fire per matching action, so keep them fast and scoped; heavy checks belong at commit or PR. A hook that asks a human for approval belongs at Deploy, not Build — an approval prompt mid-build puts a person back on the critical path of every parallel session.
- Parallel sessions vs subagents: a parallel session is another full Claude Code instance in its own git worktree, sharing nothing but the engineer steering it. A subagent runs inside one session as a scoped helper with its own context window. Sessions raise tasks in flight; subagents keep each session focused.
Test — the feedback loop, and evals as the new QA gate
Always give the agent a way to verify its own work: tests, a build, a screenshot diff. It iterates until the check passes, so what reaches the engineer has already passed it.
The feedback loop and a verifier subagent are different things: the loop runs throughout the task, as many times as the work needs; the verifier is a fresh context window run once, when the session believes it is done, so the verdict is not coloured by the assumptions that produced the code.
Continuous evals are the AI-native stage-gate QA — a suite that runs whenever the agent’s configuration changes, saying whether a new model or rewritten prompt still does the work to standard. Treat it as live: as models improve, cases that once discriminated stop doing so.
Deploy — review as a policy artifact
Claude both gives and receives reviews. Every PR gets an identical set of passes with findings ranked by severity, so human attention moves up a level — to whether the change does what the plan intended and whether the risk is acceptable.
The tech lead writes REVIEW.md at the repo root, split into the passes the organisation cares about (bugs, security, compliance against spec.md and plan.md), and it defines what counts as Important versus a Nit. Findings do not approve or block on their own; branch protection still requires a code owner. Monthly, the lead tunes by rating findings and capping nit volume, excluding generated paths and anything CI already enforces.
The compounding rule appears again: when review flags a mistake for the second time, the correction goes into CLAUDE.md — and because review reads CLAUDE.md, the mistake is caught from the next PR onward.
Maintain — closing the loop
This is the stage that runs headless. A trigger (control-band breach, ticket, channel message, schedule) invokes Claude with no person in the path; Claude diagnoses, acts only through gated routes, and writes intent.md, which re-enters the stages above. Between stages sits an independent confidence gate — a deterministic check or an adversarial reviewing agent — deciding whether output continues or escalates to a human.
Security scanning follows the same logic: a scan is a point-in-time statement and both halves go stale — the code changes weekly, and each model generation finds what the last one missed. So run it on a schedule and send findings through the same gates as any other change.
Fitting a legacy source of truth
For every artifact, name one system as the source of truth and let everything else hold a copy or a link. Three workable configurations: the repo as authoritative (cleanest for engineering-led orgs — one tool, one timestamp authority); the legacy system as authoritative (Jira/ServiceNow holds the record, Claude reads at session start and writes back through MCP); or linkage as the minimum bar — every artifact notes the record ID, every legacy record holds the commit SHA. Linkage is the honest place to start, accepting two sources of truth.
What startups do differently
The startup guide is the same playbook seen from a company with no legacy to fit around. Reported outcomes: ClickHouse 30% more features shipped, Omni 2–3x engineering productivity, Clay 100% of bug triage automated, Artemis Security 6,000+ PRs a week.
- Everyone ships. The barrier drops far enough that the person who understands the problem builds the first version. Division of labour survives — marketers still market — but 0 to 1 is open to everyone. Clay runs quarterly reviews where prototypes enter the formal roadmap; Omni has a Slack channel for Claude-generated prototypes. Shared skill directories keep contributions coherent rather than piecemeal.
- Automate the tedium. Agents own the mechanical 80% so engineers spend time on cases needing judgement.
- Trust, but verify. The necessary corollary — you cannot automate what you cannot verify. Cainex’s medical-coding loop is the worked example: auditors review output including the model’s reasoning, every correction is versioned, Claude traces each error back to the instruction that produced it and revises against a golden set plus random samples. Their enforced rule: fix the principle, not the example.
- Build for rebuilding. Model capability keeps shifting, so little is permanent. Clay’s Kareem: “you build it and then you build it again… the fourth time you build it, you know everything that’s needed.” Commure’s Tanay adds the harder half — a rebuild isn’t done when the new path ships, it’s done when the old path is gone; teardown always lost the prioritisation fight because it ships no features, and now it is a skill invocation plus a review. Git worktrees make v2 cheap to run beside v1.
- Prototype, dogfood, productionize. Building with AI teaches you what to build into AI products. Omni took Anthropic’s file-vs-embedding approach as licence to skip a RAG pipeline; Emergent debugs its own product locally through Claude Code to tell model behaviour from harness issues.
Relationships
- Loop Engineering — the loop primitive this whole lifecycle is built from
- Context Engineering — what goes in
CLAUDE.md, and why a stale line costs context - Agent Skill Evolution — skills that rewrite themselves from execution history
- Developer Productivity Measurement — measuring whether the shift actually delivered
- Legacy Systems — why the legacy record usually wins the source-of-truth argument
- Coding Agents and AI Tools — parent topic
- Software Engineering Practices — the practices this reorganises
References
- The AI-Native SDLC playbook | Claude by Anthropic
- The Claude Code Guide For Startups