Same Six Stages. Different Engine.

Same Six Stages. Different Engine.

I recently read the Claude Academy course on the AI-Native SDLC Playbook. I was impressed by how clearly it puts traditional and AI-native methods side by side. It also inspired this post: a summary, plus commentary from talking to clients.

I wanted the write-up to be AI-tool agnostic, so it stays useful if you are not on Claude. The table below is the summary, with the artifact each stage needs to commit. I used OpenSpec as one system that can provide equivalent artifacts. It can be any other system of your choice, as long as the artifact satisfies what that SDLC stage needs.

How to read the AI-native column: Human is a judgment call — someone still has to accept or reject. Gate is a hard stop, enforced in the tooling, not a meeting. Plan and Design are human-only; from Build onward, some of the control is technical.

The AI-Native SDLC Playbook

Stage Traditional SDLC AI-Native SDLC Committed artifact
01 Plan Product Owner triages tickets, incidents, tech debt, and forward-looking asks into a PRD or Epic, by hand. The agent turns a stakeholder's words, a field ticket, or a Maintain alert into a proto-spec, whether the ask is a problem or a new feature.Human: Product Owner reviews and corrects before commit. Requirements doc: e.g. intent.md (Claude Code) · proposal.md (OpenSpec)
02 Design Design Engineer, Architect, or Lead writes the spec; a separate team re-parses it into a design: two phases, two handoffs. Requirements and design compress into one session with the agent, guided by reusable rules.Human: Product Owner signs off; Tech Lead or Architect on higher risk. Design spec: e.g. spec.md (Claude Code) · design.md + spec.md (OpenSpec)
03 Build One Developer handwrites tests and code; documentation comes after, if at all. The agent plans, then codes, drawing on versioned project-instruction files (CLAUDE.md, .cursor/rules) as institutional memory.Human: Developer approves the plan first, then the architecture review; Tech Lead or Architect on higher risk.Gate: The agent cannot edit files until the plan is accepted. Implementation plan: e.g. plan.md (Claude Code) · tasks.md (OpenSpec)
04 Test Test/QA Engineer's gate sits at each boundary; the signal that code works lags days or weeks. The agent verifies its own work each session, then a separate eval suite regression-tests the configuration itself. Evals collected by a Platform Engineer.Gate: Pass rate gates config merges; incidents become permanent regressions. Eval suite: e.g. evals/*.json + CI workflow
05 Deploy Developers review every line by hand; DevOps deploys and rolls back via manual runbooks under pressure. Layered agentic review runs bugs, security, and compliance passes; automated gates (hooks in Claude Code, equivalent policy checks elsewhere) enforce approval as the agent acts.Human: Code owner judges intent and risk.Gate: Release Manager must authorize the production gate before the agent can pass it. PR + review
06 Maintain SRE watches dashboards, waiting on tickets or incidents before acting. A script watches production metrics (error rates, CI failures, cycle time) against a rolling baseline; crossing a control-band threshold triggers the agent to diagnose and write a new proto-spec.Human: Findings triaged by the on-call SRE.Gate: Version-controlled response tiers cap what the agent may do without approval. Updated requirements doc: e.g. new intent.md (Claude Code) · new proposal.md (OpenSpec)

What ties the right-hand column together is the committed artifact. Each stage ends by writing one to version control, and the next stage begins by reading it. The chain of commits is the audit trail: who asked for what, what the agent produced, who approved it. Humans stay accountable for every judgment call. Their attention just moves with the artifact.

The larger point: it is a journey, not a switch

The table is a useful reference. What I tell clients is that AI-Native is a multi-step journey, and each enterprise’s path is going to be different. Choose your own.

I see the journey as three stages:

Traditional SDLC → AI-assisted SDLC → AI-Native SDLC

From Assisted to Native is a wide spectrum. On one end, companies in a pure vibe-coding / code-completion model. On the other, companies that have embraced a full autonomous AI-Native SDLC. There is a messy middle where most organizations sit, and that middle is unique to each organization. The image at the top of this post shows the two ends of the spectrum. It leaves out trying to define what the middle looks like, because it can be anything.

I have written before about why most companies stall between AI-assisted and AI-led. This playbook is one map for what the far side of that stall actually looks like, stage by stage.

Why the end state still feels futuristic

The end stage of AI-Native still feels too idealistic or futuristic for most organizations, and my conversations with clients attest to that. A few reasons:

  1. Existing SDLC practices wired too deep into traditional and manual ways of working.
  2. Lack of standardization, code and design conventions, automation; monolithic architecture; slow or non-existent continuous delivery.
  3. Lack of awareness of AI-Native tools and frameworks that allow the same levels of control and safety — quality gates, guardrails, hooks, skills, evals.
  4. The team has not been able to make the mental shift; lack of psychological safety.

Each organization has one or more of these, in different proportions, so you are not alone. This is the pattern I see whether the company is small or big, and whether its SDLC is primitive or mature. It does not matter.

The goal is not binary

The goal is not full-or-nothing. I see this like DORA’s engineering performance levels. You start as a low performer and make your way up to Elite — say, deploying to production several times a day.

So map out your AI-Native journey with an incremental goal for each quarter, or a couple of quarters. Measure, take stock, refine, and march toward the next goal. That is the continuous-improvement path that works for any organizational transformation.

The Claude Academy course is a good one (14 lessons) and gives you a mental model. The sketchnote is meant to be consumable and referenceable, something you can map onto your own journey. The table is the tool-agnostic version: same stages, same human gates, filenames that match whichever spec system you actually use.

Where is your organization in this journey? What steps have helped you go further toward your own goal for AI-Native? I would love to hear from you — reach out.

Related:

Resources: