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 → Implement and 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. submitted by /u/Interesting-Yard-684
Originally posted by u/Interesting-Yard-684 on r/ClaudeCode