The AI-Native SDLC playbook

Louis Claxton · article · 2026-08-21 source ↗ Reader 🖥️

practical · mixed — A vendor (Anthropic Applied AI team) playbook: expository framing of why the traditional SDLC breaks down, followed by six prescriptive 'plays' (one per lifecycle stage), each with concrete steps, worked examples, governance considerations, and measurement indicators. Argues for action throughout, not just understanding.

Structure

Key terms

• AI-native SDLC Small Teams & Compression
  A reimagined software development lifecycle that keeps the traditional control objectives (accountability, traceability, policy compliance) but enforces them with new mechanisms — a non-linear loop with AI embedded at each point, where an accepted artifact automatically triggers the next stage.
• intent.md / spec.md / plan.md (the artifact chain)
  A sequence of version-controlled markdown artifacts — captured intent, requirements-and-design spec, implementation plan — each produced by a human-agent session, each reviewed and committed before the next stage begins, together forming the audit trail of who asked for what and who approved it.
• Plays
  Modular, independently adoptable units of practice, each covering what changes, how to get started, concrete implementation steps, governance considerations, and how to measure success; organized under six stages but not required to be adopted in stage order.
• Closing the loop
  The practice of letting a deterministic monitoring script detect a control-band breach in production and invoke Claude, without a person in the invocation path, to diagnose the issue and write it back into the pipeline as a new intent.md.
• Harnessability (implicit contrast) Agent Harness
  Not used by this author, but relevant: the piece never uses the word 'harness' at all, instead decomposing the same underlying concept into named components (CLAUDE.md, skills, hooks) treated as separate plays rather than as parts of a single named layer.

Propositions

• explicitThe traditional SDLC's process-heavy controls (approval gates, reviews, handoffs, PRDs, estimation rituals) were designed to maximize efficiency and accountability in an era when writing and implementing code was the most time-consuming and expensive stage — an assumption that no longer holds once agentic coding collapses that stage.conf: high
• explicitWhen the build phase collapses to hours, the bottleneck moves to the human-speed stages on either side of it (plan, review/test, deploy); controls stop matching reality because reviewing each line by hand made sense when a person wrote it, but cannot keep up once agents write most of the diff.conf: high
• explicitThe AI-native SDLC is a loop, not a linear flow: every stage ends by committing a version-controlled artifact (intent.md, spec.md, plan.md, the diff and its tests, the PR with review findings, the incident record) that the next stage reads and that automatically triggers it, and the resulting chain of commits is itself the audit trail of who asked for what, what the agent produced, and who approved it.conf: high
• explicitCapturing an idea as intent.md — written by the originator in their own words, with Claude's help, then corrected and committed by that same originator — replaces the traditional path where an idea passes through backlog entries, story points, and refinement meetings, losing fidelity to the originator's intent at each handoff.conf: high
  supportsThe Intent Debt · p18 — Claxton's intent.md — originator-written, human-corrected, committed to a shared versioned home — is a concrete team-level implementation of exactly what Osmani argues AGENTS.md should be used as: a reviewed intent ledger, not auto-generated config describing the code.
• explicitRequirements and design can collapse into a single prompted agent session because the organization's policies (brand, security, compliance, UX, encoded as skills) are applied live while the spec is being written, rather than discovered in a separate review weeks later.conf: high
• explicitcorroboratedNo code should be implemented without an accepted plan; Claude Code's plan mode enforces this structurally, since the agent cannot edit files until the engineer accepts the plan, which moves design review to a point where changing course is still a matter of editing a document rather than a diff.conf: high
  supports ←How I write software with LLMs · p7 — Both converge on 'no implementation without an accepted plan' as the core safety mechanism, though this article enforces it through agent-instruction discipline in a vendor-agnostic harness (OpenCode) rather than through a specific product's structural plan-mode.
• explicit⚡ disputed & corroboratedInstitutional knowledge that used to sit in people's heads and on wikis becomes version-controlled, team-shared files — CLAUDE.md and skills — that every agent session reads at the start, maintained by the whole team and reviewed like code rather than owned by any one person's memory.conf: high
  contradictsThe Orchestration Tax is You · p18 — Osmani frames the orchestration tax as an individual-developer problem to solve through personal workflow design; Claxton locates the same tax-paying activity (maintaining shared context, catching repeated mistakes) in team-owned, version-controlled infrastructure (CLAUDE.md, skills) a platform team maintains — an organizational-capability framing, not a personal-discipline one.
  supportsEncoding Team Standards · p2 — Both independently converge on the same practice: team standards belong as versioned, repository-resident, agent-readable files rather than wiki documentation or tribal knowledge, maintained and reviewed like code.
  supports ←Harness engineering: leveraging Codex in an agent-first world · p6 — Both independently arrive at the same requirement from opposite directions in the same batch: institutional/team knowledge must become repository-resident, versioned, and machine-readable (CLAUDE.md/skills; docs/ as system of record) or it is effectively invisible to every future agent session.
• explicitA skill is only an advisory control — it makes compliance likely but nothing forces a session to comply — so any policy that must always hold needs a deterministic hook behind it as well; the skill makes violations rare and the hook makes them close to impossible.conf: high
  extendsThe New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p7 — Where the earlier piece names 'the harness' as what dominates agent behaviour without decomposing it, Claxton's playbook operationalizes exactly that dominance into an advisory layer (skills, CLAUDE.md) backed by a deterministic layer (hooks), naming which layer an organization needs for a policy that 'must always hold.'
• explicitSeparation of duties in AI-assisted PR review is preserved structurally rather than by policy alone: the agent that wrote the code has no way to approve it, because approval always requires a human through branch protection, however extensive the AI review passes are.conf: high
• explicitAs guardrails mature (a tuned CLAUDE.md, policy-encoding skills, blocking hooks, a test suite Claude can run), auto-accept becomes the default for routine work, and human review shifts from watching each edit as it happens to reviewing artifacts after longer autonomous sessions.conf: high
• explicitdevelopedMaintenance and incident response can run headless end to end: a deterministic, version-controlled detection script monitors a production metric against a rolling baseline, and a breach invokes Claude without a person in the path to diagnose and write the finding back as an intent.md that re-enters the normal pipeline, with response tiers (log, diagnose, propose) set in advance by breach severity.conf: high
  extends ←AI Development Patterns · p11 — Claxton's Stage 6 describes humans triaging a queue of autonomously-generated incident diagnoses; Duvall's On-Call Handoff Automation supplies a concrete generation mechanism (combining live alerts and dashboard state into one AI-written brief) for exactly the handoff moment between the humans doing that triaging.
• explicitcontestedGovernance has to be embedded as code (hooks, branch protection, managed settings that engineers cannot override) rather than enforced through meetings and committees that convene weekly or monthly, because that cadence cannot keep pace with agents producing changes continuously.conf: high
  contradictsThe Intent Debt · p24 — Osmani frames intent debt as 'primarily an individual-developer (and possibly individual-team) problem to be solved by personal discipline around externalization'; Claxton locates the same externalization need in organization-wide process infrastructure — a shared intent.md home a platform team stands up, a product-owner review gate, and governance enforced as code — not personal discipline.
• explicitLegacy systems of record (Jira, requirements tools with regulatory traceability, change boards) cannot simply be displaced by markdown artifacts because auditors, regulators, and other teams already depend on them, so for every artifact the process produces, an organization must explicitly name one system — the repo, the legacy system, or a cross-linked pair — as the source of truth.conf: high
• explicitParallel Claude Code sessions (one per git worktree) raise how many tasks one engineer can have in flight, but the practical ceiling on how many to run is set by how many streams that engineer can review properly, not by infrastructure or tooling capacity.conf: high
  supportsThe Orchestration Tax is You · p9 — Both converge on the identical rule for bounding parallel agent sessions: cap at what one person can actually review properly, not at what the tooling permits.
• explicitGiving an agent a way to verify its own work (tests, build, screenshot diff it runs itself) shifts the human reviewer's job from catching mechanical errors to judging intent and risk, because what reaches the engineer has, by construction, already passed the mechanical check.conf: high
• implicitThe whole framework assumes that a legible process — committed artifacts plus session/PR/OpenTelemetry logs — can fully reconstruct accountability after the fact, substituting for synchronous human oversight without loss of real accountability.conf: medium
• explicitContinuous evals function as the regression-test suite for the agent's own configuration: they must re-run whenever CLAUDE.md, a skill, or a hook changes, because a model swap or prompt rewrite can silently change behavior that was previously verified by hand only once.conf: high

Arguments

Narratives

• A single running example — a claims-status self-service feature — is threaded through the worked examples in Stages 1 through 3: the same change accrues an intent.md, then a spec.md, then a plan.md, each shown as a literal file excerpt.
  → Makes concrete the claim (P3) that the committed-artifact chain is the audit trail, by showing one real change traced end to end rather than describing the chain abstractly.
• A full managed-settings.json worked example for 'a regulated enterprise,' explicitly annotated line by line with what each setting buys in control terms (deny lists, sandboxed network egress, credential denial, managed-only hooks/MCP servers/plugin marketplaces, a minimum version floor) — deployed by the platform team via MDM so individual engineers cannot edit or override any of it.
  → Makes concrete what 'governance enforced as code rather than through committees' (P12/A1) looks like at the infrastructure level, going well beyond the single-hook examples used elsewhere in the piece.

Questions addressed

• ✅ How should the SDLC's controls be redesigned once writing code is no longer the slow, expensive step?
  Rebuild the lifecycle as a loop of six stages, each committing a version-controlled artifact that triggers and is read by the next stage, with governance embedded as hooks and managed settings rather than periodic review.
• ✅ Where does human judgment still belong once agents do most of the work end to end?
  At artifact-acceptance gates (reviewing intent.md, spec.md, plan.md, the PR) and in judging intent and risk, not in mechanically checking each edit.
• ✅ How does an organization keep legacy systems of record (Jira, ServiceNow, change boards) coherent with new markdown-first artifacts?
  Explicitly designate one source of truth per artifact — the repo, the legacy system, or a cross-linked pair — rather than letting two systems silently diverge.
• ⭕ Does the described transformation actually produce better, safer, or faster software when measured, as opposed to merely being plausible in principle?
  The piece specifies leading and lagging indicators for every play, but presents them prescriptively (what you should measure) and never reports the resulting numbers from a real deployment, despite claiming the practices are drawn from daily work with customers.

Gaps

• incompleteEvery play redefines the human's role (from author to reviewer, from implementer to orchestrator, from on-call responder to incident-queue triager) but the piece never addresses the human cost of that shift — skill atrophy from no longer writing code directly, morale effects of reviewing AI output all day, or how an organization trains new engineers who never practiced the skills the plays assume a senior reviewer already has.
  Read next: Look for practitioner accounts (not vendor playbooks) of how teams that have run this kind of pipeline for a year or more describe the experience of the reviewer-not-author role, and whether junior engineers develop judgment without first doing the work themselves.
• incompleteThe guide is written from a single-team, single-repo vantage point (one intent/ folder, one REVIEW.md, one set of skills) even though it recommends org-wide managed settings; it never addresses how multiple teams' independently evolved intent.md templates, skills, and REVIEW.md policies stay compatible, or what happens when one team's skill or hook conflicts with another's as code or ownership crosses team boundaries.
  Read next: Platform-engineering and multi-team governance literature on keeping independently-evolving, repo-local policy artifacts from diverging across an organization.
• uninformedThe piece is presented as consolidating 'real best practices our Applied AI team executes on a daily basis for our customers,' but every quantitative claim (leading/lagging indicators, 'elapsed time falls from weeks to hours') is prescriptive guidance on what to measure, not a reported result; no outcome data from an actual deployment appears anywhere in the piece.
  Read next: Look for independent case studies, post-mortems, or DORA-style empirical measurement of organizations that adopted this specific stage structure, as distinct from vendor-authored playbooks.
• incompleteThe piece diagnoses, at the individual level, that unstructured agent use creates an orchestration tax paid through shallow review or cognitive surrender — but never asks the organizational mirror question: whether the governance apparatus it prescribes (REVIEW.md passes, hooks, managed settings, eval suites, per-stage indicators) can itself become a new review-queue bottleneck once a tech lead or platform engineer has to maintain all of it across many repos and teams.
  Read next: Read Addy Osmani's orchestration-tax and intent-debt pieces for the individual-level version of this dynamic, then ask what the team/platform-level equivalent of 'the correct number of parallel agents equals what you can review' is for governance artifacts themselves.

Closes gaps elsewhere

• The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · g3 — Claxton's playbook is the detailed, stage-by-stage answer the gap asks for: it walks through exactly how team/org structure evolves — the product owner reviews intent.md and spec.md, the engineer reviews plan.md and the diff, the tech lead sets REVIEW.md policy and tunes it monthly, the release manager authorizes production deploys via a hook, and on-call shifts from reactive paging to triaging an autonomously-generated intent.md queue in Stage 6 — with governance embedded as hooks and managed settings rather than left as an unaddressed bullet point.

Related documents

• Encoding Team Standards
• The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering
• The Orchestration Tax is You
• Harness engineering: leveraging Codex in an agent-first world
  Agent Governance (Internal) Agent Harness Feedback Loops Intent Debt
• AI Development Patterns
  Agent Governance (Internal) Intent Debt Pull Requests & Async Code Review Small Teams & Compression
• Addy Osmani's Post
  Agent Harness Feedback Loops Orchestration Tax / Human Review Bottleneck
• Agentic Code Review
  Intent Debt Orchestration Tax / Human Review Bottleneck Pull Requests & Async Code Review
• Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle
  Agent Harness Orchestration Tax / Human Review Bottleneck Pull Requests & Async Code Review
• AWS Expands DevOps Agent with AI-Powered Release Management to Validate Code Before Production
  Agent Governance (Internal) Agentic SDLC Pull Requests & Async Code Review
• Harness engineering for coding agent users
  Agent Harness Feedback Loops Orchestration Tax / Human Review Bottleneck