Run the AI-Native SDLC Yourself, or Have It Run for You

The playbook is public now, and that changes the question in front of engineering leaders.

On 21 August, Anthropic published the AI-native SDLC playbook: sixteen plays across six stages, each with prerequisites, implementation steps, governance considerations, and a way to measure whether the play worked. CloudGeometry is an Anthropic partner and we have read it end to end. It is a serious document, specific enough that the interesting question is no longer what an AI-native lifecycle should look like.

Somebody wrote that down, in public, in detail.

What remains is who builds it, who staffs it, and who is still maintaining it in eighteen months when the engineer who set it up has left. That is an operating-model decision, not a technology decision, and most organizations are making it by accident, one repository at a time.

Here are the criteria that decide it.

What you are agreeing to own

Read the plays end to end and the prerequisite chain is substantial. In rough order: an intent home with write access decided; templates encoded as skills; policy skills with named owners; a grounding file maintained per repository; hooks in version control plus managed settings pushed through device management; a one-command test and build; curated evals running in continuous integration with an API budget attached; a written review policy; branch protection; per-environment deployment tooling; a sandbox with no standing production credentials; a rehearsed rollback path; a detection script that is itself version controlled and unit tested; and a control-band configuration.

Nothing on that list is exotic. Every item is recognizable work a competent platform engineer can do.

That is why the list is dangerous. Each piece looks like a sprint. Together they are a platform product, with a roadmap, an owner, an on-call story, and a maintenance burden that does not end when the rollout does. The playbook is honest about this. Its settings example carries the caveat that it is a starting point to tailor, because every deny trades against capability. Tailoring is not a one-time act.

The prerequisite chain is the decision. Everything else is detail.

Two things to get straight before you weigh anything

Two claims circulate about this material, including in our own market. Both are checkable in one search, and both damage the argument they are meant to support.

This is not a contest about control architecture

The playbook’s controls are stronger than the summaries suggest. The governing principle for the pipeline is that the agent may act up to the production gate and cannot pass it. Separation of duties holds because the agent that wrote the code has no way to approve it. Branch protection turns anything the agent writes into a pull request with no direct path to main. The non-negotiable hooks live in managed settings, where individual engineers cannot switch them off. Even the most autonomous play keeps detection deterministic, with no model involved, and confines the response to a pull request or a pre-approved runbook.

If you were expecting us to say that a managed lifecycle gives you human gates a model vendor cannot match, we are not going to say it. The architecture is broadly the same.

The difference is who operates it. The playbook specifies the controls and leaves the buyer to build, staff and maintain them. That is an operating-model difference, and it is the one worth arguing about.

The ceiling is review capacity, not a session count

You may have heard that the guidance caps concurrency at two or three sessions per engineer. It does not. It calls two or three a sensible starting point, and then says the practical ceiling is how many streams one person can review properly, so add sessions only while review is keeping up. Its leading indicator is phrased the same way: concurrent sessions per engineer while review quality holds.

That is a harder standard than a cap, not a softer one. A cap is a number you comply with once. A review ceiling is a property of your organization that you have to measure, and it moves with staffing and code familiarity. It is also the honest constraint, because review is where velocity goes to die once generation stops being the bottleneck.

The criteria that matter

1. Greenfield or inherited estate. On a new service whose small team wrote every line, the plays land as written. On an estate you inherited through acquisition, offshore rotation, or a decade of turnover, they assume context that exists nowhere in your organization. This is the strongest single predictor of which way the decision goes.

2. Who wrote the documentation, and when. The grounding file per repository is generated once, then cut down and corrected by hand, and the stated requirement for that work is one engineer who knows the codebase well. Its maintenance rule fires reactively: when the agent makes the same mistake twice, the correction goes into the file. That loop only works if someone recognizes the mistake. On a system where the knowledge left with the people who built it, nobody in the review seat can tell a correct answer from a plausible one, so the loop never closes.

3. Platform capacity measured in maintenance, not build. Ask your platform team not whether they can build the chain, but whether they can carry it alongside what they already own. Hooks drift. Eval suites rot as the code moves under them. Managed settings need review whenever a repository changes classification. Build capacity is usually available; maintenance capacity rarely is, and maintenance decides whether the controls are real next year.

4. Review capacity, measured honestly. Count the people who can competently review a change to the hardest part of your system. Not the people with merge rights. The people whose approval means something. That number, not any tooling decision, sets how much concurrency you can absorb.

5. Regulatory exposure. Exposure does not change which controls you need. It changes the cost of finding out you configured them wrong six months ago. The playbook is strong on evidence: the pull request is the audit record, hook decisions are logged with timestamps, session transcripts are exported. That evidence holds together only while the configuration does, and somebody has to be accountable for that.

6. What happens when that person leaves. Every implementation we have seen has one person who understands why the hooks are configured as they are. Write their name down, then ask what your control posture looks like ninety days after they resign. If the controls hold but nobody dares change them, you have built a system you cannot evolve.

The criteria that look decisive and are not

Whose controls are stronger. Covered above. Broadly the same. Stop shopping on this axis.

Which model or coding tool you standardize on. The artifacts, the gates and the review policy are the durable layer; models change underneath them. Choosing on model capability optimizes the fastest-moving variable in the stack, which is the wrong thing to decide first.

Whether your engineers are enthusiastic. Enthusiasm predicts adoption in the first quarter and nothing about the second year. Governance survives on ownership, not appetite.

Seat cost. The license is not the expense. Platform engineering time, the eval budget in continuous integration, and senior review hours are, and none of them appear on the quote.

Whether you already run good DevOps. A mature pipeline gives you branch protection and deployment tooling. It does not give you an intent home, a policy skill with a named owner, or a grounding file somebody keeps current.

How to weigh them

Two criteria dominate: the documentation state of the estate, and your real review capacity. The other four adjust the answer at the margin. If both are healthy, the rest is scheduling. If either is weak, no control configuration compensates, because both failure modes are silent: undocumented context produces changes that look right and drift architecturally, and thin review produces approvals that are signatures rather than judgments.

The decision aid

Six questions. Answer them for one specific system, not for the company, because the answer legitimately differs by system.

Five or six yeses: run the playbook yourself here. The guidance is public and detailed, and you have the conditions it assumes.

Three or four: run it yourself, but narrow the rollout to the parts of the estate where the answers were yes.

Two or fewer: have the lifecycle operated for you here. Not because the controls would differ, but because the conditions the playbook assumes are absent, and building them is a platform commitment nobody budgeted.

Most organizations we talk to are split. The newer services score five or six. The system that generates the revenue scores one. That is a coexistence answer and it is the honest one: run the playbook yourself where the conditions hold, and have the inherited estate operated for you under the same gate structure, with a named senior engineer accountable at each gate.

The mistake is not choosing one side. It is choosing once, for everything, and calling it a strategy.

On 10 September we are running a joint session with Tigera on the two halves of this problem: accountability for what gets built, and enforcement of what an agent is allowed to reach. Each fails predictably without the other. Approval without enforcement is a signature on something you cannot see. Enforcement without accountability is a wall your team routes around by Friday.

If you are working through these six questions for a specific system and want a second read on the answers, have that conversation before the rollout, not after.