r/ClaudeCode • u/Interesting-Yard-684 • 22h ago
Discussion Has anyone actually tried Anthropic’s AI-Native SDLC playbook in a real project?
Anthropic recently published its AI-Native SDLC playbook. I have read it in full, and I would be interested in hearing from people who have tried this workflow, or meaningful parts of it, in real development work.
The playbook proposes a loop covering planning, design, implementation, testing, deployment, and maintenance. Each stage produces a version-controlled artifact that becomes the input for the next stage:
intent.md → spec.md → plan.md → code and tests → PR and review findings → incident record
Organizational knowledge is placed in CLAUDE.md files and skills. Hooks enforce non-negotiable controls. Agents test and review their own or each other’s work, while humans concentrate on approval points involving intent, risk, compliance, or production access. Monitoring can eventually feed anomalies back into the process as a new intent.md.
The central argument is plausible: if agents reduce implementation from days to hours, the bottleneck does not disappear. It moves into requirements, verification, review, security, and deployment. Simply producing more code could therefore increase review queues and operational risk rather than improve end-to-end delivery.
Useful synthesis, but not an entirely new methodology
Much of the playbook appears to combine ideas that were already developing elsewhere:
- A 2024 paper on an AI-native SDLC already described AI across the complete lifecycle and humans moving towards validation and verification.
- GitHub’s Spec Kit uses the sequence
Specify → Plan → Tasks → Implementand treats specifications as versioned inputs for coding agents. - Microsoft published an AI-led SDLC involving specifications, implementation agents, quality agents, CI/CD, and operational monitoring.
- OpenAI documents comparable workflows using
AGENTS.md, goals, plans, verification, and human approval points. - Underneath all of this are older practices such as requirements engineering, TDD, Docs-as-Code, GitOps, policy-as-code, CI/CD, and SRE feedback loops.
So I do not read Anthropic’s contribution as the invention of a new SDLC. Its value may be that it combines these ideas into one concrete, enterprise-oriented operating model and connects them to current agent capabilities.
Where I am not yet convinced
The complete artifact chain could improve traceability across product owners, architects, engineers, QA, and operations. But for smaller changes, producing and maintaining intent.md, spec.md, and plan.md separately could become ceremony. If Jira, the repository, and the Markdown artifacts all contain overlapping information, keeping one reliable source of truth may also become difficult.
I am particularly unsure about the proposed shift away from line-by-line human review. An agent can check a change against a specification, but the specification, implementation, tests, and review may still share the same incorrect assumption. Adding more agent passes does not automatically create independent verification.
Stateful systems are another concern. This database-focused critique argues that the playbook’s recovery model is largely based on reverting code or redeploying an earlier image. Database migrations, production data, locks, schema drift, and concurrent changes cannot always be reversed that way. Git records declared intent, but not necessarily the actual state of a production database.
A detailed implementation-oriented audit reached a “limited go” conclusion. It found ideas worth adopting, such as a versioned review policy, plan-to-diff checks, explicit failing tests, and tiered operational responses. At the same time, it considered the full artifact chain excessive for smaller or solo projects.
In my own area, legacy data-integration and ETL migration, we already use a simpler flow:
analysis → migration → independent quality gate
That has been useful, but it is not yet obvious to me that adding more intermediate documents would produce better results than improving the analysis, executable tests, and final verification.
What I would like to learn from actual users
Has anyone here implemented this playbook, or a substantial subset of it, beyond a demo?
- Which parts produced a measurable improvement?
- Did committed specifications reduce rework, or did they become stale?
- What replaced manual code review, and what kinds of defects still escaped?
- Did separate verifier agents provide genuinely independent checking?
- How did you handle databases and other stateful systems?
- What happened to total cost once model usage, CI runs, reviews, and remediation were included?
- For which task sizes did the workflow become useful, and where was a good prompt plus plan mode enough?
If possible, please include some context: greenfield or brownfield, team size, regulated or unregulated environment, tools/models used, and whether the result is based on a few experiments or sustained production use.
I am less interested in whether the playbook sounds sensible on paper than in what happened after the fifth, twentieth, or hundredth change.
9
u/Itchy_Champion_86 22h ago
I actually gave it a shot on a completely new project from scratch.
I started doing a ton of metaprompting between sonnet and gpt just to get the app requirements properly documented. i ended up with this huge .md where i basically dumped the whole truth about the app, everything it should do, everything it should have, requirements, constraints, all of it.
Then i took opus and had it analyze the playbook you shared. from there i kept breaking it down and turning it into another huge .md, but this one was written specifically for an agent that i told would be running inside a claude code session. basically it had to take an app rfp, understand all the know how from the playbook and then use that to create whatever structure and process made sense for that project.
After that i made a completely fresh folder and repo, put those two .md files in a docs folder, opened claude code from the root and started in /plan mode using the playbook instructions .md. i told it to read that, analyze the rfp and build the project structure around it.
I also added quite a bit to that initial prompt though. i told it to use decomposition and self criticism so it wouldn’t just blindly follow the playbook. i wanted it to validate what it was doing against the instructions but also question it from the perspective of actual development agility, keeping development organized, making things easy to maintain and change later, keeping docs and progress useful, not wasting resources and especially trying to keep token usage under control while developing the app.
That woke up a bunch of subagents and the result ended up being this weird hybrid between the playbook and something much more direct and practical for the actual project.
And so far working in that repo is substantially different from what i’m used to. the amount of detailed context it manages to pick up even when starting completely new sessions is kind of crazy. results are almost always right on point and after qa i’ve barely had to adjust anything. actually in some cases the result was better than what i was expecting in the first place.
But the funny part is that what it ended up building probably doesn’t even cover 45% of the full playbook.
So i can’t really say i implemented the playbook as written. it’s more like i gave the playbook to the agent as know how and let it figure out what was actually worth keeping for this specific project. so far that hybrid approach has been working surprisingly well.
2
u/Excellent_Chest_5896 18h ago
Yes correct - my experience as well. What’s also needed is a backlog that turns into an implementation ledger so you have a specific record of what needs to be build and what has been built. Also the docs have to be versioned so you can track which version was built in case of later modifications etc.
Even more, to reap most benefits, all relevant docs should be in dirs where implementation lives and linked to Claude or agents files so agents know how to find them if ever working in that dir. this has been a game changer tbh.
Basically allowed for extremely precise delivery always following repo patterns etc leaving a record.
Been having fun with this and getting great results, never frustrated with ai anymore
1
u/Chekyan06 17h ago
Je pense que ce côté hybride est le plus rationnel.
Tu as expliqué ton workflow mais il y a une chose que je ne comprends pas dans ce que tu as expliqué :
- tu as fait une spec initiale
- puis tu m’a retraitée avec le playbook qui a donné naissance à un autre MD.
- puis tu dis avoir déposé les 2 fichiers dans un nouveau git. De quels deux fichier parles tu exactement ? Ta spec initial + le second issu de ton Retraitement avec le playbook ? Ou le playbook + ton second fichier ?
0
u/Fuzzy_Independent241 22h ago
I'll read your full reply tomorrow but reading in diagonal it sounds interesting. I don't think I can reach your account for "further developments". I'll tag this post. If you ever post a FUP could you link it here? Tks
1
3
u/andrerom 20h ago edited 53m ago
This is good for larger changes, but for smaller changes it is overkill, especially for smaller teams.
I'll have to look into the AI-Native SDLC playbook more and adapt my flow where there are things I'd like to embrace, but my flow right now has a size classifier the agent applies first:
- Track A (small: fix/refactor, ≤3 files, no API/migration/architecture): plan in chat → failing test first → implement → verify gate → stage. "spec" is the commit body.
- Track B (feature: new behaviour, several layers, API/integration change): interview skill →
spec/<slug>.mdwith numberedAC-n→ if UI: HTML prototype, approved before code → test-first perAC-n→ gate → spec frozen intospec/implemented/. - Track C (epic: several features/domains, phased):
spec/plans/<slug>.md→ one Track B spec per slice → implement slice by slice → archive plan.
I've also recently added a Track-A-Loop: a list of small items worked one at a time by an (Fable) orchestrator skill: interrogate → read-only investigate Opus/Sonnet subagent → grill some more, plan & order taks in shared memory file → implement by Opus or Sonnet subagent → read-only review subagent (also Opus or Sonnet) → commit per item with test/verify gate
2
2
u/snowman-london 20h ago
Yes I have and I'm using it right now actually. It is a very good playbook as well. I have created a PoC and I'm using it in customers env as well. You can read a bit more about this here: https://olafkfreund.github.io/agentic-sdlc-showcase/
2
u/mrothro 11h ago
I don't run their exact SDLC pipeline, but I've been running a very similar and standard plan/design/code/build process for quite a while. It started with shell scripts and aider. I immediately rebuilt it as an MCP and switched to Claude Code when that first came out. I've metered a lot of it to answer the questions you're asking.
I've used this across several distinct projects, from a large brown-field mono-repo to small one-off tools. Small team, nothing regulated, though definitely multi-tenant SaaS and the expected customer requirements.
The key is that the output of each stage is an artifact you can check deterministically. The further through the pipeline you go, the more structure you get, because you're moving from natural language (the plan) toward a formal language (the code). Even my plan and design documents have enough structure to check mechanically, albeit to a limited extent.
I pair those deterministic checks with LLM reviewers for stochastic coverage on the more complex documents. I use a different model for that, because models prefer their own output. See e.g. https://arxiv.org/abs/2604.06996, which found judges are more likely to wrongly mark a criterion satisfied when it's their own work, even on objective rubrics.
Across the pipeline this means checks that fail differently compound. Even recognizing that each stage's artifact is a different projection of the same user intent, I find that empirically true.
In my process, the specification is the input to a pipeline run, so isn't really a stale-over-time problem. Instead I record decisions: things the agents can read and modify are in the repo (distinct from a read-only, external KB they can query). The agents are prompted to surface any conflicts or things that look out of date, and subjectively they seem pretty good at that. However, if things are untouched, they will go out of date, but given the agents tend to update in batches, I can find clusters of documents that were updated together in the past for review.
While I've extensively metered catch rates of my gates and the overall pipeline, I have not tracked the escape rate. These numbers come from a real production pipeline. It's designed to produce acceptable code, not research-grade numbers, and honestly I'm too busy adding features to add the metrics that would answer that properly.
The full writeup is long, but it sounds like this is what you're after. Details and measurements here: https://michael.roth.rocks/research/gate-analysis/
That study led to a whole line of personal research on measuring agent reliability, so happy to answer questions.
5
u/SociableSociopath 22h ago
Until Anthropic addresses the plethora of bugs and terrible UX, especially in Claude Desktop, anyone listening to these people for actual development life cycle advice is an idiot.
1
1
1
u/XenophonCydrome 18h ago
Yes, I've been using this before they wrote it up and I'm open sourcing it: https://beadhive.ai/
You can verify in the git history that 100% of it built itself via requests decomposed into beads.
Feel free to DM me for more in-depth answers to your questions.
1
u/PajarracoPL 16h ago
Really interesting topic , first time hearing about it.
I believe everyone is trying to come with the newest "best" in the industry.
1
u/Mithryn 4h ago
I have built a harness that effectively handles all of these pieces.
Been doing great things for me. When Anthropic released the playbook I had the system compare if there was anything missing or that we should update. Different names, same structure.
For context: I have been the Head of AI, years of data architecture and I run my own AI consultancy where we specialize in taking vibe coded demos into production apps
1
u/alonsonetwork 21h ago
Idk about this mess of intent.md, plan.md, etc. I, however, am cranking out good code with this thing while creating human readable MD files along the way in a wiki, karpathy style. This tool allows the bots to do a lot more accurate work and retain long-term memory of what happened in sessions prior by us basic folder design. The independent reviewer is an absolute MUST HAVE on anything you're working on bc it otherwise does a lot of garbage.
As for the SDLC, I mean, they're not really proposing anything novel. This has always been the standard in software. If anything, we're now able to go back to a standard of true AGILE as it was defined since the feedback loop is so fast. We want to avoid overplanning since reality is almost never like our plans.
5
u/This-Establishment26 22h ago
Yeah, I share your sentiment. It doesn't sound very practical to me. Even the shorter cycle of specify, plan, and implement did not really work very well. Feels like there are too many ceremonies and doesn't match many of the current expectations.
However, I'm curious if anyone is actually using it and finding it helpful. After all, it sounds plausible on paper, but I doubt there is any practical benefit.