AI-Native SDLC in Practice: Anthropic's Playbook, Spec-Driven Development and AWS AI-DLC

Hi Folks! Are you all right? everything in peace? Everything calm? I hope you are well!

It's been a while since I've posted anything here, but I'm back!
In this article I want to talk about the AI-native SDLC (Software Development Life Cycle): the process that Anthropic documented in "The AI-native SDLC playbook", and how I'm applying it in my day to day using the skills of Matt Pocock: grill-me, to-spec, to-tickets and implement.

Everybody is using AI to write code. But writing code was never the whole job. Where do we decide what to build? Where do we review? Where do we say "stop, this goes no further without a human"? That's what an SDLC answers, and that's what changes (and what doesn't) when an agent enters the loop.

Disclaimer: the playbook is from Anthropic, but the skills of Matt Pocock are not part of it. The mapping between them is mine, based on how I use both. Take it as an opinion, not as official documentation.

What is the AI-native SDLC?

In the AI-native SDLC playbook (published in August 2026), Anthropic keeps the six stages that we already know, but changes how each one produces and consumes work:

1. Plan
2. Design
3. Build
4. Test
5. Deploy
6. Maintain

The central idea is simple: each stage ends by committing an artifact to Git, and the next stage starts by reading it.

The chain of commits becomes your audit trail. And the humans? They stay accountable. In the words of the playbook:

"Humans remain accountable for every decision that requires judgment."

Another principle that I loved is about the deploy: the agent may act up to the production gate and cannot pass it.

The skills of Matt Pocock

Matt describes his repo as "skills for real engineers... to do real engineering, not vibe coding". They are small, composable and work with any model. He even says he doesn't want a framework that owns the process and takes away your control: you can hack them and make them yours.

The four that I use the most, in order:

• /grill-me: a relentless interview about your plan or design. It maps the decisions that need to be made, asks them in rounds (each one with a recommended answer) and only stops when you reach a shared understanding.
• /to-spec: turns the current conversation into a spec and publishes it in your issue tracker. No new interview, just synthesis of what was already discussed. The spec has Problem Statement, Solution, User Stories, Implementation Decisions, Testing Decisions and Out of Scope.
• /to-tickets: breaks the spec into tracer-bullet tickets: vertical slices that cut through every layer, each one demoable on its own, declaring what blocks what.
• /implement: implements a ticket (or a spec) using TDD at the agreed test seams, runs typecheck and tests, calls a code review and commits.

You can already see the shape: it's the same "artifact in, artifact out" idea of the playbook.

The flow, stage by stage

1. Plan → grill-me

Anthropic: the originator brainstorms with Claude and the result is an intent.md: the problem, the proposed outcome, who is affected, constraints and open questions. A human reviews, corrects and commits it.

Matt's skill: /grill-me is the best "brainstorm" I've found. Instead of the AI jumping to the code (or agreeing with everything I say), it interviews me. It splits the plan into a design tree, asks the questions whose prerequisites are already settled, and suggests an answer for each one, so most of the time I only need to say "yes".

A detail that I like: facts are the agent's job, decisions are the user's. If the question can be answered by reading the codebase, it goes and reads. If it's a decision, it asks me.

My experience:

I usually use grill-me for the more complex initiatives, the ones that involve product, design and engineering decisions at the same time. Many times I use it just to refine and understand an initiative or a story, and to generate the artifact. Then the whole team can analyze it and review if the generated requirements really make sense.

2. Design → to-spec

Anthropic: the agent writes a spec.md from the accepted intent.md, flagging concerns (security, compliance, UX...). The product owner reviews it but doesn't write it.

Matt's skill: /to-spec takes everything that was discussed in the grilling and writes the spec. It does not interview me again, it only synthesizes. It also asks me to confirm the test seams (where the tests will touch the code), which will matter later.

Notice the difference of mindset: the thinking happened on the previous stage. The spec is just the written record of it.

My experience:

Where the spec is stored depends on the context of each team. Some teams version the artifacts inside the project itself, others keep a dedicated repository with all the artifacts.

3. Build → to-tickets + implement

Anthropic: the engineer starts in plan mode, interrogates the plan and commits a plan.md (files that change, order of work, risks, proof). Claude cannot edit files until the engineer accepts the plan. The playbook also puts CLAUDE.md, skills, subagents and hooks in this stage.

Matt's skills: here I use two of them.

• /to-tickets is my plan.md. It slices the spec into tracer-bullet tickets, each one small enough for a fresh context window, with the blocking edges between them. It also quizzes me about the granularity: merge these two? split that one?
• /implement takes one ticket and builds it using TDD (red, green, refactor) at the seams that we agreed on. It runs the typecheck regularly, single test files often and the full suite once, at the end.

Working with small tickets and fresh contexts is, for me, the biggest quality jump. Long sessions drift.

4. Test → TDD and review inside implement

Anthropic: the agent runs tests and builds to check its own work before a human sees it. Evals run in CI, and a production incident becomes a new eval.

Matt's skills: /implement delegates to the tdd skill and, when it finishes, calls code-review, which checks the changes in two axes: does it follow the repo's standards, and does it match what the spec asked for. This is the part that I find closest to the "give Claude a way to verify its own work" advice of Anthropic's best practices.

5. Deploy → the human gate

Anthropic: the agent reviews PRs against a REVIEW.md, a code owner approves, and in production a release manager authorizes the release. Hooks (PreToolUse) act as approval gates: allow, ask or deny. Another quote that I like: "A skill is a control, though an advisory one." If a rule must always hold, it needs a hook behind it, not only a prompt.

Matt's skills: nothing here is automatic, by design: his skills that orchestrate are user-invoked, and implement only commits to the current branch. The PR, the review and the merge still go through the human gate.

6. Maintain → closing the loop

Anthropic: this is the most "futuristic" stage. A deterministic script detects when a metric leaves its control band (bands.yaml). At 2σ Claude only diagnoses (read-only), and at 3σ it may open a PR or trigger a pre-approved runbook. The output is a new intent.md, which restarts the cycle.

Matt's skills: there's no skill for this stage, but the loop closes in the same way: a bug or a new need becomes a new /grill-me. He also has /diagnosing-bugs for the hard ones.

The whole picture

Plan      →  /grill-me     →  shared understanding (intent)
Design    →  /to-spec      →  spec in the issue tracker
Build     →  /to-tickets   →  tracer-bullet tickets
          →  /implement    →  TDD + code review + commit
Test      →  CI / evals    →  human sees only verified work
Deploy    →  PR + review   →  human gate
Maintain  →  new problem   →  back to /grill-me

Where does Spec-Driven Development (SDD) fit?

If you've been following the AI coding scene, you probably saw the term Spec-Driven Development (SDD). The idea: before the agent writes code, you and the agent agree on a written specification, and the spec (not the chat) becomes the source of truth. GitHub's Spec Kit puts it in a nice way:

"Specifications don't serve code—code serves specifications."

Sounds familiar, right? SDD is basically the Plan and Design stages of the AI-native SDLC (intent.md → spec.md) turned into tooling. The playbook tells you what artifact each stage must leave behind. The SDD tools give you a ready-made structure to produce and keep those artifacts.

Let's see three of them:

OpenSpec

OpenSpec describes itself as "spec-driven development (SDD) for AI coding assistants". It adds "a lightweight spec layer so you agree on what to build before any code is written", and supports 30+ tools (Claude Code, Cursor, Codex, Copilot, Gemini CLI, Kiro...).

Install and start:

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

The folder layout is the interesting part:

openspec/
├── specs/<capability>/spec.md      # source of truth: what the system does today
└── changes/
    ├── <change-name>/              # one folder per change in flight
    │   ├── proposal.md             # why, and what changes
    │   ├── specs/                  # what "done" means (the spec delta)
    │   ├── design.md               # technical decisions (only when needed)
    │   └── tasks.md                # implementation checklist
    └── archive/YYYY-MM-DD-<change>/

And the flow has five steps: Explore → Propose → Review → Apply → Archive, through slash commands like /openspec-explore, /openspec-propose, /openspec-apply-change and /openspec-archive-change.

The part that I find smart is the archive: when a change is done, its delta is merged into openspec/specs/ and the change folder goes to the archive (nothing is deleted). So the specs describe the system as it is now, not only the history of what was planned. That attacks the biggest problem of specs: they rot, and nobody trusts them anymore.

OpenSpec says it wants to be "fluid not rigid", "iterative not waterfall" and "built for brownfield not just greenfield".

Spec Kit (GitHub)

Spec Kit is more structured. It starts with a project constitution (principles), and then goes through:

/speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement

(it also has optional steps like /speckit.analyze and /speckit.converge to check consistency between spec, plan and code). Each feature gets its folder with spec.md, plan.md, tasks.md and others.

Kiro (AWS)

Kiro is an IDE where the spec is a first-class thing. Every spec generates three files: requirements.md, design.md and tasks.md, going through three phases (requirements, design, tasks).

So, how does it compare with the skills?

All of them end up in the same place: intent → spec → tasks → implementation. The difference is who owns the process:

Two differences that matter for me:

• Where the artifacts live. SDD tools keep them as Markdown in the repo, versioned by Git, exactly like the playbook says ("commit an artifact"). Matt's to-spec and to-tickets publish in your issue tracker (Linear, GitHub Issues...), or locally in .scratch/ if you don't have one.
• How much process comes in the box. OpenSpec and Spec Kit give you folders, templates and commands. Matt's repo goes the other way: small skills that you can hack. He even calls out frameworks that "own the process" and take away your control.

None is "the right one", it's a trade-off between structure and freedom. And you can mix: for example, use /grill-me to align and then let OpenSpec hold the proposal and the living specs in the repo.

And the AWS AI-DLC?

Anthropic is not the only one thinking about this. AWS proposed the AI-Driven Development Life Cycle (AI-DLC) in a blog post from July 2025. The problem is the same: if the AI does the heavy lifting, the old process (sprints, epics, long meetings) doesn't fit anymore.

In that post, AI-DLC has three phases:

• Inception: "AI transforms business intent into detailed requirements, stories and units through 'Mob Elaboration' – where the entire team actively validates AI's questions and proposals."
• Construction: the AI proposes architecture, domain models, code and tests through Mob Construction, where the team clarifies technical decisions in real time.
• Operations: the AI uses the context accumulated in the previous phases to manage infrastructure as code and deployments, with team oversight.

Two things caught my attention:

• The "mob" rituals. The whole team validates what the AI proposes, together, instead of one person alone with a chat. The AWS follow-up post says this is to make sure "AI's suggestions are not blindly accepted". This is exactly the use case that I described in the Plan stage: use grill-me to generate the requirements, and then the team reviews if they make sense.
• New vocabulary. Sprints are replaced by bolts ("shorter, more intense work cycles measured in hours or days rather than weeks") and epics by units of work.

The human-in-the-loop idea is the same as the playbook: AI "implements solutions only after receiving human validation", at every decision gate.

AWS also open sourced the workflows in awslabs/aidlc-workflows. It works with Claude Code, Kiro, Codex, Cursor, opencode and GitHub Copilot, and you start it with /aidlc <what you want to build>. The README says it "selects a workflow from the request, asks for missing decisions, and stops at approval gates before moving forward".

Note: the repository README talks about "5 phases and 33 stages", while the original blog post describes 3 phases. I couldn't reconcile this from the pages I read, so check the repo for the current structure before adopting it.

So, how does it compare? Anthropic's playbook is about artifacts: each stage commits a file that the next one reads. AI-DLC is about team rituals and approval gates: the whole team validates the AI at every step. For me they complement each other. Use the artifacts to have the trail, and the rituals to make sure that the right people looked at it.

What I learned

A few things from the sources that I want to leave here, because I agree with them:

• Artifacts over chat. If the decision only lives in the conversation, it's gone with the context. Spec and tickets live outside of it.
• Alignment before code. It's cheaper to answer 10 questions than to review 1000 lines in the wrong direction.
• The human is not removed, the human is moved. From typing code to deciding, reviewing and approving.

Conclusion

🎉 We saw the six stages of the AI-native SDLC of Anthropic and how I map them with the skills of Matt Pocock.

What You've Learned:

✅ The six stages: Plan, Design, Build, Test, Deploy and Maintain

✅ The "artifact in, artifact out" idea and why the humans stay accountable

✅ How grill-me, to-spec, to-tickets and implement fit in this flow

✅ What Spec-Driven Development is and how tools like OpenSpec, Spec Kit and Kiro fit in the flow

✅ How the AWS AI-DLC (Mob Elaboration and Mob Construction) approaches the same problem

✅ Where the human gate must stay

Happy building! 🚀

📚 Resources and Further Reading

Official Documentation

The AI-native SDLC playbook - Anthropic

AI-native SDLC playbook course - Claude Academy

Best practices for Claude Code - Claude Code Docs

Skills Used in This Article

mattpocock/skills - Matt Pocock's agent skills

Spec-Driven Development Tools

OpenSpec - SDD for AI coding assistants

OpenSpec Quickstart

Spec Kit - GitHub's SDD toolkit

Kiro Specs - Kiro documentation

AWS AI-DLC

AI-Driven Development Life Cycle: Reimagining Software Engineering - AWS DevOps Blog

Open-Sourcing Adaptive Workflows for AI-DLC - AWS DevOps Blog

awslabs/aidlc-workflows - AI-DLC workflows on GitHub

Thank you very much for reading this far and stay well always!

Contacts:

• Linkedin: https://www.linkedin.com/in/kevin-uehara/
• Instagram: https://www.instagram.com/uehara_kevin/
• Twitter: https://x.com/ueharaDev
• Github: https://github.com/kevinuehara
• dev.to: https://dev.to/kevin-uehara
• Youtube: https://www.youtube.com/@ueharakevin/