Anthropic's AI-Native SDLC Playbook Moves the Bottleneck to Verification

A lifecycle rebuilt around agents

Anthropic has published a playbook for reorganizing the software development lifecycle around AI coding agents, according to an analysis by MetalBear, the company behind the mirrord Kubernetes development tool, which surfaced on Hacker News's front page. The playbook's premise, as MetalBear summarizes it, is that the traditional SDLC was designed for an era when writing code was the slow step. Agents collapsed that step, and the bottleneck shifted to everything surrounding it: planning, design, review, and verification.

Six stages, each leaving a file behind

The framework spans six stages, and each one is expected to commit an artifact that the next stage can read. Planning produces an intent.md file. Design translates that into a spec.md. Before any code is touched, the build stage writes a plan.md. Deployment carries its review policy in a REVIEW.md. Anthropic also includes an adoption graph in which arrows indicate which plays to take up first, and the top row lists practices with no prerequisites — the feedback loop sits in that row, meaning teams can start there.

Stage 4: the agent audits itself

The stage MetalBear focuses on is Stage 4, the feedback loop, where the agent checks its own output before a human ever looks at it. The playbook asks teams to give the agent something concrete to check against: a test suite, a build, or a screenshot diff. To prevent gaming, it recommends a hook that blocks edits to test files while the agent is fixing a failure, so it cannot make a red test green by rewriting the test. For interface work, it suggests connecting a browser or screenshot tool over MCP.

MetalBear notes the playbook goes further than most process documents by asking teams to manage the agent's own configuration with the same rigor as production code: evals run in CI to re-test CLAUDE.md, skills, and hooks whenever any of them change, and every production incident becomes a permanent eval case. The stated prerequisite for all of this is a test suite and a build that each run locally with a single command.

The question the playbook leaves open

That prerequisite is where MetalBear's critique begins. The playbook says the agent needs runnable tests, but not what those tests should execute against. For a service that depends on databases, queues, and a dozen other services — which describes most real software — MetalBear argues that is the bulk of the problem.

If the checks run against local fakes, a passing run only proves the code works against the fakes. A human developer can calibrate how much to trust them, remembering that the mock billing service predates an authentication change or that the fake search endpoint never paginates. An agent has none of that context; it sees green tests and reports the task complete.

MetalBear also observes that the entire artifact chain consists of things people wrote down. Nothing in it shows the live system: what an upstream service actually returns today, what messages sit on the queue, or whether the staging database's schema matches the branch the agent is working from.

mirrord's proposed answer

MetalBear, unsurprisingly, sells a remedy. mirrord lets code run locally, in CI, or in an agent sandbox while proxying traffic, environment variables, secrets, and files to and from a shared staging cluster, so the agent's checks execute against real dependencies instead of mocks. The same connection lets the agent inspect actual API responses and queue contents rather than relying on documentation.

The playbook also suggests running several Claude Code sessions in parallel, each in its own git worktree, with subagents inside a session. MetalBear points out that worktrees isolate code but not infrastructure: five agents pointed at one staging service will collide with each other and with the engineers using it. Its commercial mirrord operator addresses this by filtering traffic by header so each session receives only its own requests, splitting queue topics into private slices, and branching databases per session. mirrord itself is open source; the operator ships as part of the paid product. MetalBear names monday.com, National Australia Bank, and SurveyMonkey as users.

Why it matters

The playbook formalizes a shift many engineering teams already feel: when code generation is cheap, the costly parts are capturing intent, verifying results, and reviewing output. Its artifact-chain approach — every stage deposits a machine-readable file for the next — is a concrete, tool-agnostic pattern teams can adopt immediately. But MetalBear's critique marks a real boundary: the playbook governs files in a repository, while the truth about a system partly lives in the infrastructure it talks to. Teams building agent-heavy workflows will need to decide early what their agents verify against, and whether that environment is realistic, isolated enough for many concurrent agents, and trustworthy enough that a green test run actually means something.