What does AI-native SDLC mean?

It means a software lifecycle designed on the assumption that an agent drafts most artifacts: specs, designs, code, tests, and documentation. Humans shift toward deciding scope, approving designs, writing or approving tests, and reviewing risky changes. The stages stay familiar, but the bottleneck moves from writing code to verifying it and keeping the system coherent.

Should Claude Code write the tests too?

It can draft them, but approve them before implementation starts. Tests written after the code by the same agent often confirm what the code does rather than what it should do. Test-first keeps a human judgement in the loop at the point where it is cheapest, and gives the agent an objective target instead of a vague request.

How do you stop the agent from ignoring past decisions?

Make past decisions retrievable. Keep short decision records, index them alongside architecture notes and the codebase, and have the agent search that index before proposing a design or change. Pasting history into prompts does not scale, and a long instruction file is paid for on every request while still missing the specific record that matters.

Where should humans stay in the loop?

At scope decisions, design approval, test approval, review of changes touching security, data, money, or public interfaces, and release or rollback. Those are the points where a confident wrong answer is expensive. Everywhere else, let the agent draft and let checks such as tests, linters, and type systems catch the routine mistakes.

How to Run an AI-Native Software Lifecycle With Claude Code

An AI-native lifecycle gives the agent a defined job at every stage: drafting specs from requirements, proposing designs against real constraints, implementing in small slices, writing tests first, reviewing diffs, and summarising incidents. Humans own decisions and acceptance. What decides quality at every stage is the same input: retrievable project context the agent can read before it writes.

What changes when an agent does the drafting

A traditional lifecycle assumes writing code is the expensive step, so the process is built to protect developer time: long specs up front, heavy design reviews, and testing near the end. When a coding agent drafts code in minutes, the expensive steps move. Deciding what to build, checking that the result is right, and keeping the system coherent become the bottlenecks.

An AI-native lifecycle reorganises around that. The stages stay recognisable, but each one gets two explicit roles: what the agent produces, and what a human must decide or verify before the next stage starts. Teams that skip the second half get speed for a few weeks and then a codebase nobody can explain.

The stages, and the agent's job in each

Treat each stage as a handoff with a defined output.

Requirements and specification

The agent turns a request, ticket, or conversation into a written spec: scope, acceptance criteria, edge cases, and open questions. The human job is to answer the open questions and cut scope. A spec the agent wrote and nobody challenged is a guess with formatting.

Design

The agent proposes an approach against the existing architecture: which modules change, which interfaces are touched, what data moves. This only works if the agent can read how the system is actually built. Without that it designs a clean system that is not yours.

Implementation

Work in vertical slices small enough to review in one sitting. Start each slice with a fresh session, commit at every green state, and restart early when a session drifts. Long sessions accumulate stale assumptions.

Testing

Write or approve tests before the implementation, then let the agent make them pass. Tests written after the fact by the same agent tend to encode whatever the code already does, including its mistakes.

Review

The agent can pre-review its own diff against conventions and flag risk, but a human reviews anything touching security, data, money, or public interfaces. Review time is now the scarce resource, so protect it with small diffs.

Release and operations

Agents are useful for release notes, runbook drafts, log triage, and incident summaries. Keep deploy approval and rollback decisions with people.

The shared failure: every stage starts from zero

Look across those stages and the same problem repeats. The spec agent does not know last quarter's decision about the billing module. The design agent does not know which service is being retired. The implementation agent reinvents a helper that already exists. The reviewer agent approves a pattern the team banned after an incident.

None of that is a model quality problem. It is a context problem. Most teams patch it by pasting the same background into every session, or by growing an instruction file until it costs real tokens on every request and still misses the detail that mattered.

The fix is structural: index the material each stage needs once, and let every stage retrieve from it. Decision records, architecture notes, API contracts, past incident write-ups, and the codebase itself become chunks the agent searches before it writes. The spec agent finds the old decision. The design agent finds the retirement plan. The token cost of re-explaining the project on every request drops, because the answer is retrieved instead of regenerated.

A working setup

One source of truth per stage. Specs in the repo or a vault, decisions as short records, runbooks next to the services they cover.
Index it. Put that material and the codebase behind a retrieval layer that any agent session can query, so context is fetched on demand rather than pasted.
Keep instruction files short. Commands that work, hard constraints, and a pointer to where deeper context lives.
Define the handoff artifact per stage. Spec, design note, slice, tests, reviewed diff, release note. If a stage has no artifact, nobody can check it.
Measure review load. If reviewers are drowning, shrink the slices before adding more agents.

The teams that get lasting value from an AI-native lifecycle are not the ones with the cleverest prompts. They are the ones whose agents can find what the team already knows.

Frequently asked questions

What does AI-native SDLC mean?: It means a software lifecycle designed on the assumption that an agent drafts most artifacts: specs, designs, code, tests, and documentation. Humans shift toward deciding scope, approving designs, writing or approving tests, and reviewing risky changes. The stages stay familiar, but the bottleneck moves from writing code to verifying it and keeping the system coherent.
Should Claude Code write the tests too?: It can draft them, but approve them before implementation starts. Tests written after the code by the same agent often confirm what the code does rather than what it should do. Test-first keeps a human judgement in the loop at the point where it is cheapest, and gives the agent an objective target instead of a vague request.
How do you stop the agent from ignoring past decisions?: Make past decisions retrievable. Keep short decision records, index them alongside architecture notes and the codebase, and have the agent search that index before proposing a design or change. Pasting history into prompts does not scale, and a long instruction file is paid for on every request while still missing the specific record that matters.
Where should humans stay in the loop?: At scope decisions, design approval, test approval, review of changes touching security, data, money, or public interfaces, and release or rollback. Those are the points where a confident wrong answer is expensive. Everywhere else, let the agent draft and let checks such as tests, linters, and type systems catch the routine mistakes.

Key takeaways

Each SDLC stage keeps its purpose; what changes is who drafts and who decides.
Specs and tests become the main human artifacts, because they are what makes agent output checkable.
Review load rises as generation gets cheap, so slice size and contracts matter more than prompts.
Every stage fails the same way without context: plausible output that does not fit the system.
A shared retrieval layer serves every stage once, instead of re-explaining the project per session.