What an AI-Native SDLC Actually Looks Like, Phase by Phase

Code got cheap. The process that governs it still charges the old price.

The seven boxes are still on the wall. Requirements, design, implementation, testing, evaluation, deployment, governance. The gates between them still assume a person wrote every line and another person read it. That assumption is now false for a large share of the diff, and the cost of leaving it in place shows up as the gap between a tooling budget that grew and a delivery number that did not.

One clarification before we start, because the search results for this topic are a mess. This is about building software with AI, not about training and shipping models. The MLOps lifecycle is a different article with different phases, and a surprising amount of what ranks for "AI software development lifecycle" is actually about model training. If data collection and model evaluation are the phases you came for, this is not that.

Here is the thesis, in one sentence: cheap generation does not remove the cost of building software, it relocates it, out of authoring and into specification and verification. The lifecycle keeps its phases. The work inside them inverts. The phases that used to be cheap become the expensive ones, and the phase every engineering organization optimized for a decade stops being the constraint. What follows is what each of the seven phases becomes, and how we run it ourselves.

What AI-native actually means, and what it does not

AI-assisted delivery means AI helps at a step. Someone opens an editor, accepts a completion, and the surrounding process is unchanged. AI-native delivery means the process assumes AI did the work and is built to verify it.

That is the whole distinction, and it has consequences at every gate. A code review designed for a colleague's 200-line pull request is an AI-assisted artifact. A review process that assumes the diff was generated, that the author cannot vouch for every line from memory, and that the evidence of correctness has to come from somewhere other than the author's confidence, is an AI-native one.

The software development lifecycle, or SDLC, is just the sequence that takes an idea to production. Most organizations run some version of the same phases. Anthropic's AI-native SDLC playbook (2026) frames it as six stages and argues that when the build phase runs faster than the process allows, the bottleneck moves to the steps on either side of it. That is the right diagnosis. The rest of this article is about what those steps become.

Seven phases, then: requirements, design, implementation, testing, evaluation, deployment, governance. Evaluation is listed separately from testing on purpose. That one separation is where most of the difficulty lives, and it is the phase almost nobody has built.

Why the tooling rollout did not move the delivery number

The uncomfortable pattern is easy to describe. Adoption dashboards are green. Acceptance rates look healthy. Engineers report the tools are useful and would object to losing them. And the number of things that actually reached customers this quarter looks a lot like last quarter.

None of that is mysterious once you look at where work queues. Generation got faster, so more work now arrives at the places where humans decide. Review queues deepened. Intake ambiguity that used to get resolved in a standup conversation now gets resolved by an agent guessing, which means it gets resolved wrongly and discovered later. Release criteria that were vague but survivable became a bottleneck the moment throughput upstream doubled.

Measured gains are real. They are also narrower than the headline suggests. Atlassian (2026) analysed 3,400 repositories across 2,500 customers and found a 19% increase in merged pull requests per repo per month, alongside two to three hours saved per developer per week. Those are credible numbers, and they describe the middle of the pipeline. A merged pull request is not a delivered outcome, and an hour saved in authoring does not convert to an hour saved in delivery unless the phases on either side can absorb it.

So the honest version of the diagnosis is this: the tools worked, and the process ate the gain . Which phase ate it depends on the organization. It is almost never implementation. Here is the whole argument in one table, and the rest of the article is the case for each row.

Requirements become the highest-leverage artifact you write

An agent does not walk over to your desk. It resolves ambiguity by picking, plausibly and confidently, and the wrong pick looks exactly like the right one until it reaches someone who knows the domain.

That is the whole change. A ticket used to be a conversation starter, and it could be underspecified because the person implementing it would notice and ask. Ambiguity was absorbed by the implementer. It is no longer absorbed. It is amplified, at generation speed.

Which makes the written intent the highest-leverage artifact in the lifecycle. In practice that means a document, ahead of any build work, that states five things: the problem in concrete terms, the outcome that would count as solving it, the users and systems affected, the constraints that must hold, and the questions still open. Anthropic's playbook calls the artifact an intent file. The name matters less than the discipline of writing the thing down before generation starts, because generation will otherwise fill the gaps itself.

There is an organizational consequence here that engineering leaders underrate. Writing a specification precise enough to be executed without clarification is a skill, it is unevenly distributed across any team, and it is now on the critical path. It belongs in hiring criteria and promotion conversations, not just in a process document.

The failure mode to watch for is a spec that is long instead of precise. Volume is not precision. A three-paragraph intent that names the constraint and the acceptance condition beats a three-page one that describes the feature.

Design becomes the constraint you encode, not the diagram you file

Design that lives only in a diagram does not survive contact with high-volume generation. Drift now accumulates faster than anyone reads the document.

Most architecture documents were written once, reviewed in a meeting, and then diverged quietly from the system they described. That was tolerable when the rate of change was bounded by how fast people could type. At generation speed it stops being tolerable. Design that lives as enforceable constraints survives: allowed dependencies, service boundaries, the patterns to follow, the things that must not happen. Encoding architecture as constraints is the difference between a design that shapes the code and a design that describes what the code used to be.

This raises the value of a distinction that has always mattered and now matters more. Some decisions are cheap to revisit and some are not. AI-native delivery makes the reversible ones much cheaper, because rewriting a component is no longer a two-week commitment. It makes the irreversible ones no cheaper at all. A data model, a service boundary, an authentication approach, a public API contract: these cost the same to unwind as they always did, and the surrounding speed makes it easier to blunder into them without noticing.

So the design phase picks up an explicit job it did not have before. Sort the decisions. Spend human judgement on the ones with long half-lives and let the rest be cheap.

Implementation stops being the bottleneck and becomes the easy part

This is the shortest section in the article, and saying so is part of the point.

For twenty years, implementation was the phase organizations staffed for, measured, and optimized. Velocity charts measured it. Hiring plans were sized around it. It was where the money went.

It is now throughput. The interesting question moved from how fast code can be written to how much of it can be reviewed with real attention, and the scarce resource moved with it. Review capacity is the new constraint, and reviewing generated code is a different skill from reviewing a colleague's. A colleague's mistakes cluster around the things they were unsure about, and their uncertainty is legible in how the code is written. Generated code carries no such signal. It reads uniformly confident whether it is right or wrong.

Which is why the definition of done has to change. Working code stopped being sufficient evidence at roughly the moment working code became easy to produce. What replaces it is evidence that someone or something checked the specific properties that matter, produced at the speed the rest of the phase now runs.

Testing shifts from catching your bugs to catching the machine's

A test suite is a net, and every net is sized for a particular distribution of failures. The suites most teams have were sized for human error: typos, off-by-ones, the edge case someone forgot, the misunderstanding between two developers.

Generated code fails differently. It compiles. It reads well. It uses the right idioms and the right names. And it is wrong in ways that survive a visual pass, because nothing in how it is written signals the model's uncertainty. A plausible wrong implementation of a business rule is much harder to spot than a sloppy one.

Two things follow. First, coverage of the properties that actually matter, instead of coverage as a percentage, becomes the thing worth measuring. Second, tests move earlier, and their role changes while they move. Moving tests earlier used to be about cost, catching a defect before it got expensive. Now it is also about direction: a test that an agent has to satisfy is a constraint on generation, not just a check after it. Writing the test first stops being a discipline question and becomes a control mechanism.

The teams doing this well treat the acceptance test as part of the specification, written in the same pass as the intent, and hand both to the agent together. That covers everything a test can settle. The next section is about everything it cannot.

Evaluation becomes a phase of its own

Here is the gap in almost every account of the AI-native lifecycle, including the good ones. Testing and evaluation get treated as the same phase. They are not, and the difference is the reason features pass every gate and then fail in production.

Testing is a binary judgement about deterministic behaviour. The function returns the right value or it does not, and the same input produces the same answer every time. Evaluation is a measured judgement about non-deterministic behaviour: how good the output is, how consistent it is, and whether it got worse since the last change. When outputs differ between runs , a pass or fail gate cannot answer the question you actually have.

A real evaluation phase contains four things. A dataset of cases with known-good outcomes, large enough that a few lucky runs cannot move it. A scoring method that produces a number instead of a verdict. A baseline recorded before the change, and a threshold agreed before shipping, not negotiated after a bad result. And a rerun on every change to the prompt, the model, the retrieval layer, or the surrounding code, because any of those can move the score.

The organizational consequence is sharper than the technical one. Someone has to own that number. Regression in a probabilistic system does not announce itself with a red build. A score that drifts down over six weeks while nobody is watching is indistinguishable from a product that quietly stopped working, and the first person to notice is usually a customer. Whether your process can catch that before they do is a property of the process, not of the model.

This phase is new work. It has no counterpart in the traditional lifecycle, and most organizations discover it only after their first production incident that no test could have caught.

Deployment becomes a decision about evidence

Faster generation only turns into faster delivery if the release decision also speeds up. That decision is a question about evidence: what is sufficient to let this change through, and how much of that evidence can be produced without a human assembling it.

The old release process was a checklist and a meeting. It worked because the volume of change was low enough that a weekly or fortnightly ritual could keep pace. When the answer to "what is sufficient evidence" is still "a person reads the diff and forms a view," the phase caps throughput no matter what happens upstream.

Making the decision faster without making it reckless comes down to two properties. Exposure should be progressive, so that being wrong is survivable and gets discovered on a small population instead of all of them. And reversal should be cheap in practice, which is a claim most teams believe about their system and fewer have tested recently.

What you monitor in production changes too. Deterministic software fails loudly: an exception, a timeout, an error rate. Probabilistic behaviour degrades without saying anything, and the signals that matter are things like output distribution, fallback frequency, how often users abandon or retry, and the evaluation score run against live traffic instead of a fixed dataset. Watching only for errors on a feature that fails by being subtly worse means watching the wrong thing.

Governance becomes decision rights, written down

Governance in most organizations is a policy document and an approval matrix that assumed a human author. It answers "who signs off" for a world where signing off meant vouching for work you personally understood.

The AI-native version is more specific and less comfortable to write, because it requires stating out loud what an agent is permitted to do unattended. That means a map, per phase, of three things: the decision being made, who or what is allowed to make it, and the evidence required before it counts as made. Decision rights, at the phase level, instead of principles at the organization level.

Governance also moves earlier. In the traditional lifecycle it sat at the end as a gate, which worked when the end was weeks away from the beginning. In an AI-native lifecycle the effective controls are the ones encoded in the requirements and the design, where they shape generation instead of inspecting it afterwards. PwC (2025) found that 56% of executives now have first-line teams in IT, engineering and data leading responsible-AI work rather than a central committee, and the logic generalizes: a control applied after generation is a control applied to volume, and volume wins.

The part that does not move is accountability. Thoughtworks (2026) puts trust and accountability at the center of preparing a team for an agentic lifecycle, and it is the right emphasis. Distributing execution across agents does not distribute responsibility. Someone still owns the outcome, and if the governance map cannot name that person for each phase, the map is not finished.

The failure mode is a governance document that reads as principles. "Shift left." "Keep humans in the loop." "Ensure responsible use." Those are not decisions anyone can act on at four in the afternoon with a release pending. A usable governance artifact names the decision and the evidence.

What does not change

An article that says everything is different should be treated with suspicion, so here is the other list.

Architecture decisions that are expensive to reverse are still expensive to reverse. Cheaper generation changes the cost of building the wrong thing, not the cost of having built it into everything else.

Security and data boundaries hold exactly as they did. Faster delivery of a change that crosses one is not a benefit.

Knowing what customers actually need remains unautomated. The lifecycle can produce the wrong product much more efficiently now, which is the specific risk of speeding up everything downstream of the decision about what to build.

Ownership does not distribute. Nobody has yet found an arrangement where an agent absorbs accountability for an outcome.

And the uncomfortable one. An organization that could not ship reliably before will not ship reliably now, only faster. AI-native delivery amplifies the process it is applied to. Applied to a good one it compounds. Applied to a broken one it produces more of the same, sooner, and the diagnosis gets harder because the volume obscures the pattern.

How we run this ourselves

Most accounts of the AI-native lifecycle are vendor benchmarks or survey data. A delivery process is easier to judge when someone shows you a real one, so here is ours. It is not unusual, and that is fine. What matters is that every choice in it follows from one assumption.

Our content and delivery pipelines are staged, and the stages are separated on purpose. Each one writes an artifact to disk, and the next stage reads that artifact instead of the previous stage's working memory. That single property does most of the useful work. It makes the process inspectable after the fact, it makes a failed run resumable at the stage that failed instead of from the beginning, and it makes a wrong output traceable to the stage that produced it.

Between stages sit deterministic gates. Not review meetings, and not model judgement about whether the output looks acceptable, but code that checks specific properties and returns a pass or a fail. A gate that fails triggers a repair action written down in advance, and the repair is re-run through the same gate. Two attempts, then the run stops and a human is told exactly what failed. The point is that when a gate fails, nobody is improvising.

Verification runs as its own stage instead of as a step inside review, which is the practical form of the testing and evaluation split described above. Non-critical checks fail soft on purpose. A component that cannot reach an external service degrades that run instead of stopping it, because a gate that can take down the whole pipeline eventually will.

None of that is exotic. What makes it AI-native is the assumption underneath it: generation is cheap and verification is the expensive part, so the process spends its budget accordingly.

Key takeaways

• Cheap generation does not remove the cost of software, it relocates it. The seven phases survive. What each phase is for does not.
• Requirements and design become the expensive phases. Ambiguity that used to be absorbed by an implementer is now amplified at generation speed.
• Implementation is no longer the constraint. Review capacity is, and reviewing generated code is a different skill because it reads uniformly confident whether or not it is correct.
• Evaluation is a distinct phase from testing, with a dataset, a baseline, a threshold agreed in advance, and an owner for the number. Its absence is why features pass every gate and fail in production.
• Governance means decision rights per phase, naming the decision, the actor, and the evidence. Principles are not actionable at four in the afternoon with a release pending.

Where to start

Not with a transformation program. The organizations that get this right sequence it, and the sequencing rule is simple: find the phase where your evidence is weakest, and make that one phase AI-native before touching the others.

For most teams that is requirements or evaluation. Requirements, because a specification that an agent executes without clarification is a different artifact from a ticket, and nobody has rewritten the template. Evaluation, because it is new work with no traditional counterpart, and its absence is invisible until something is quietly wrong in production for six weeks.

Pick one. Rewrite what the phase produces, what evidence it emits, and who decides on that evidence. Then look at what moved downstream, because the answer tells you which phase to take next. The bill did not disappear when code got cheap. It moved, and the only question is whether your process has noticed.

If you want that scoped against your actual delivery process instead of a generic model, a Discovery Sprint is a one-week engagement that maps where your lifecycle is absorbing the gains your tooling is producing, and what the first phase to rebuild should be.