Skip to content
Tech News
← Back to articles

The AI-Native SDLC Starts with Your Infrastructure

read original more articles
Why This Matters

This article highlights the importance of integrating robust testing and verification infrastructure into the AI-native Software Development Lifecycle (SDLC). By emphasizing self-checking agents and automated evaluations, it underscores a shift towards more resilient and reliable AI-driven software processes, which are crucial for both industry innovation and consumer trust.

Key Takeaways

Anthropic published a playbook for restructuring the software lifecycle around coding agents. Its premise is that the traditional SDLC was designed when writing code was the slow part, agents made that part fast, and the constraint moved to the stages around it.

The framework has six stages, and each one commits an artifact the next stage can read. Planning produces an intent.md . Design turns that into a spec.md . Build produces a plan.md before any code is edited. Deploy puts the review policy in a REVIEW.md .

It is more specific than most process documents, but it also leaves out an important detail that can decide whether the rest of the process actually works, which is what the agent’s code runs against when it checks itself.

Stage 4: where the agent checks its own work #

Stage 4 is the feedback loop, where the agent checks its own work before an engineer sees it. The playbook asks you to give it something to check against, whether tests, a build, or a screenshot diff. It tells you to stop the agent from turning a red test green by editing the test, using a hook that blocks edits to test files during a fix. For UI work it suggests wiring in a browser or screenshot tool over MCP.

Then it goes further than most organizations have, and asks you to treat the coding agent’s own configuration as software: evals running in CI that re-test CLAUDE.md , the skills, and the hooks whenever any of them change, with every production incident turned into a permanent eval.

What Stage 4 asks you to have in place before any of that works is a test suite and a build that run locally with one command each.

That prerequisite is where the playbook stops and your infrastructure starts. It tells you the agent needs tests it can run. It does not say what those tests should run against, and for a service that talks to a dozen others (plus databases, queues, third-party APIs, etc.), which describes most real-world software, that is most of the question.

Why verification is the hard part #

If the tests run against fake copies of those dozen services on the agent’s machine, then tests passing tells you the code works against the fakes. Whether it works against the ones in the cluster is a different question.

... continue reading