{"slug": "the-ai-native-sdlc-starts-with-your-infrastructure", "title": "The AI-Native SDLC Starts with Your Infrastructure", "summary": "Anthropic's AI-native SDLC playbook restructures software development around coding agents, but its verification stage depends on infrastructure the playbook does not specify, leaving agents to test against fakes that may diverge from production systems. The playbook's six stages commit artifacts like intent.md, spec.md, plan.md, and REVIEW.md, yet it stops short of defining what tests run against, which is critical for real-world services with multiple dependencies.", "body_md": "# The AI-Native SDLC Starts With Your Infrastructure\n\nAnthropic published [a playbook](https://claude.com/blog/the-ai-native-sdlc-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.\n\nThe framework has six stages, and each one commits an artifact the next stage can read. Planning produces an `intent.md`\n\n. Design turns that into a `spec.md`\n\n. Build produces a `plan.md`\n\nbefore any code is edited. Deploy puts the review policy in a `REVIEW.md`\n\n.\n\nIt 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.\n\n## Stage 4: where the agent checks its own work [#](#stage-4-where-the-agent-checks-its-own-work)\n\nStage 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.\n\nThen 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`\n\n, the skills, and the hooks whenever any of them change, with every production incident turned into a permanent eval.\n\nWhat 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.\n\nThat 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.\n\n## Why verification is the hard part [#](#why-verification-is-the-hard-part)\n\nIf 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.\n\nA developer running those same tests knows roughly how far to trust them. They know the fake billing service was written a year ago and that the real one changed its auth header two months ago. They know the fake search endpoint always returns the same three results, while the real one paginates. And they know that nothing in the fake set has ever rate-limited them or timed out. The agent knows none of that. It sees the tests pass and reports the work finished.\n\nThis is not a flaw in the playbook so much as the edge of what it can cover. Every other stage works on files in a repository, and Anthropic can be specific about those because Claude Code is theirs. The services, the databases, the queues, the message brokers, and everything else the code talks to are yours. No model vendor can tell you what those look like, so the playbook tells you to have a check and stops there.\n\n## The agent never sees the running system [#](#the-agent-never-sees-the-running-system)\n\nLook at what the artifact chain holds: `intent.md`\n\n, `spec.md`\n\n, `plan.md`\n\n, `CLAUDE.md`\n\n, the skills, `REVIEW.md`\n\n. Each one records something a person decided and wrote down.\n\nNone of it lets the agent look at the system as it runs right now in production (or staging). Not what the upstream service returns when you call it, not what is sitting on the queue, not what the staging database’s schema actually is today, which may be several migrations behind the branch the agent is working on. `CLAUDE.md`\n\ntells the agent what the organization decided, not what is actually running.\n\n## What mirrord does [#](#what-mirrord-does)\n\nmirrord lets the agent’s code run against the real services in your staging cluster instead of fakes on its machine.\n\nThe code still runs locally, or on a CI runner or sandbox. What changes is everything around it: the process reads the same environment variables and secrets as the service it is standing in for in the cluster, its outbound calls go out through the cluster’s network, and traffic inside the cluster can be routed to it.\n\nWe built this for developers, who mostly use it to shorten their feedback loop by cutting out the deploy-and-wait cycle. Agents get more out of it, because a developer can still judge how stale a set of fakes has become but an agent cannot. Running the check against the services in the cluster means nobody has to make that judgment.\n\nIt helps before the check, too. The same connection lets the agent see what the API actually returns and what the messages on the queue actually contain, rather than working from documentation.\n\n## Running several agents against one cluster [#](#running-several-agents-against-one-cluster)\n\nThe playbook suggests running several Claude Code sessions at the same time, each in its own git worktree, with subagents inside a session.\n\nWorktrees keep the code separate. They do nothing about the cluster those sessions check against. Point five agents at the same staging service and they interfere with each other and with the engineers already using it, which is usually where an organization decides that agents and shared staging do not mix and goes back to giving each agent its own (slow, expensive, shallow) copy.\n\nThe mirrord operator solves this. Traffic is filtered by header so each agent’s session only receives its own requests, queues are split so each session gets a private slice of a shared topic, and databases are branched so a session that writes does not disturb anyone else. One staging cluster serves as many agent sessions as you need to run against it.\n\n## Where to start [#](#where-to-start)\n\nIf you are adopting the playbook, the question worth answering first is the one it doesn’t ask: what will the agent’s code be running against when it checks itself?\n\nmirrord is open source. The operator, which is what handles the concurrent sessions above, is part of our commercial product. If you want to see what Stage 4 looks like running against your cluster, start at [metalbear.com/mirrord/docs](https://metalbear.com/mirrord/docs).\n\n### What is mirrord?\n\nmirrord is a Kubernetes development platform that lets developers and AI coding agents test code in a production-like environment before deploying it. Your service runs wherever you're working, locally, in CI, or in an agent's sandbox, while mirrord proxies its traffic, environment variables, and files to and from a shared staging cluster, so it behaves as if it were deployed without actually being deployed.\n\nEngineering teams at [companies like](https://metalbear.com/customers/) monday.com, National Australia Bank, and SurveyMonkey use mirrord to iterate and ship faster, while spending less on dev environment infrastructure.", "url": "https://wpnews.pro/news/the-ai-native-sdlc-starts-with-your-infrastructure", "canonical_source": "https://metalbear.com/blog/ai-native-sdlc-infrastructure/", "published_at": "2026-08-31 10:57:30+00:00", "updated_at": "2026-08-31 11:23:36.168580+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure", "ai-research"], "entities": ["Anthropic", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/the-ai-native-sdlc-starts-with-your-infrastructure", "markdown": "https://wpnews.pro/news/the-ai-native-sdlc-starts-with-your-infrastructure.md", "text": "https://wpnews.pro/news/the-ai-native-sdlc-starts-with-your-infrastructure.txt", "jsonld": "https://wpnews.pro/news/the-ai-native-sdlc-starts-with-your-infrastructure.jsonld"}}