Three Names, One Shift: What AI SDLC Literacy Means

You have heard this called the agentic SDLC. You have also heard it called the AI SDLC, and you have heard it called agentic software development. Anthropic, publishing the AI-Native SDLC playbook in August 2026, is blunt about it: the labels differ, but they describe the same thing.

That is where literacy starts. Not with a tool decision. With the recognition that three terms circulating in your board deck, your vendor briefings and your engineering all-hands are pointing at one shift, and that the shift has now been described publicly, in detail, by a major model vendor.

Which makes reading it table stakes rather than an edge. Nobody owns this category. What is still scarce is the ability to look at your own delivery organization and say, precisely, which stage of it has become the constraint.

This piece gives you the model to do that.

The six stages were designed around a bottleneck that has moved

The traditional lifecycle runs six stages: plan, design, build, test, deploy, maintain. Each one is a discrete phase owned by a different role. Product managers write requirements, architects turn them into designs, engineers build, QA verifies, release teams ship, operations watches production. Work crosses the gaps between phases as documents, tickets and sign-offs.

That design was not arbitrary. It was optimized for a world in which writing and implementing code was the most time-consuming and expensive stage. Product requirement documents, estimation rituals and product security reviews all existed to force alignment up front, because the thing they were aligning on would take weeks, months or quarters to build. Front-loading the argument was cheaper than discovering the disagreement halfway through.

There is a second assumption baked in, and it is the one that matters more now: the traditional lifecycle assumes every step is performed by a human.

Change the cost of the build stage and both assumptions come apart at once.

What breaks when build gets faster

Anthropic’s framing names three consequences, and they arrive together rather than in sequence.

The bottleneck moves to the steps on either side of build. Plan, review, test and deploy still run at human speed. They keep their original length while build collapses. If you have ever watched a team ship more code and deliver no faster, you have watched this happen; it is the same shape as the engineering velocity trap, where local throughput rises and system throughput does not.

Line-by-line controls stop matching reality. Reviewing every line by hand was a sensible control when a person wrote every line. It becomes intractable once agents write most of the diff. The control does not fail loudly. It quietly stops being performed properly, which is worse.

Governance cost rises. Exceptions still route through committees that meet weekly or monthly. When the work in front of those committees multiplies, the queue in front of them multiplies too, and the meeting cadence does not change.

Anthropic’s own research on AI’s impact on software development points at the same pressure from a different angle: developers increasingly delegate work to agents rather than working alongside them, while human oversight persists as a feedback loop of reviewing outputs and sending corrections back. The oversight does not disappear. It concentrates.

The worked example: security

The playbook’s illustration is security, and it generalizes well.

Security teams are sized for human output. That is not a criticism, it is arithmetic: headcount was set against the volume of change a human engineering team could produce. When agents multiply that volume, one of two things happens. Either the review queue builds, and security becomes the visible constraint on delivery, or code ships under-reviewed and the constraint stays invisible until it is not.

A regulated organization can accept neither. So its checks have to run at the pace of the thing being checked, which means they have to be enforced somewhere other than a weekly meeting.

The framework: six stages, two ends of a spectrum

Here is the model. Read each row as a spectrum, not a binary. Anthropic states explicitly that most organizations sit somewhere between the two columns, and that is the point of the exercise.

Notice what the right-hand column is not. It is not “the same process, faster.” Every row moves a human activity from performing the work to defining the standard the work is held to, and then reviewing against it. Planning is the clearest case, which is why the product manager role changes shape before anyone else’s does.

The thread running down the right-hand column is the committed artifact. Each stage ends by writing one to version control, and the next stage begins by reading it. Intent accepted, design triggered. Spec approved, plan triggered. Plan approved, build triggered. The chain of commits becomes the audit trail: who asked for what, what the agent produced, who approved it. Humans stay accountable for every judgment call. What moves is where their attention sits.

How to locate yourself

The framework earns its keep as a diagnostic. Take the six rows, mark your own organization on each one honestly, then find the queue.

One of those answers is worse than the others. That one is your constraint, and it is the only row worth acting on first.

For most brownfield enterprises the answer clusters in two places. Either plan, because nothing is specified crisply enough for an agent to be pointed at it, or deploy, because review capacity is fixed and everything upstream got faster. Those two failure modes call for opposite responses, which is exactly why locating yourself matters more than adopting a general-purpose “AI strategy”.

What the framework does not tell you

Three limits, and they are worth stating plainly.

It does not give you an adoption order. Stage order and adoption order are not the same thing; the sequence in which the six stages run tells you nothing about which one to change first. That is what the diagnostic above is for.

It does not account for the state of your existing system. The right-hand column assumes an agent can be given accurate, current context about the software it is working on. In a greenfield repository that is close to free. In a twelve-year-old production system with departed authors and stale documentation, it is the whole problem, and it is why a semantic layer matters even with a very good coding agent. Anthropic’s research notes that startups have moved on agentic coding faster than enterprises have. The gap is not appetite. It is the weight of the systems already running.

And it does not tell you who builds and runs the thing. The framework describes a target operating model. It is silent on whether you should stand that model up with your own people, on your own timeline, against your own existing delivery commitments.

The decision underneath the diagnostic

Once you can read the shift and locate yourself on it, you face a straightforward question with an uncomfortable answer: do you build and run this lifecycle yourself, or do you have it run for you?

Both are legitimate. They optimize for different things, and the right answer depends on how much of your engineering capacity you are prepared to point at building delivery machinery instead of product. That is a subject in its own right, and it is the one we will take up next. If you want to see what the second option looks like in practice, governed lifecycle delivery on existing production systems is where to start.

For now, do the smaller thing. Take the six rows, mark yourself on each, and name the constraint out loud