The AI-Native SDLC: What Moves When Agents Write the Code

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

A team asks an agent to add a refund limit to a payments service. In a traditional pipeline, that sentence becomes a ticket, a person writes the code, a colleague reads the diff, QA checks it in staging, and an operator releases it. In an AI-native pipeline, the agent does most of the writing in minutes. So what is left for the people to do, and where should they look?

The short answer is that the bottleneck moves. It stops being typing syntax and fixing build errors and becomes context (does the agent know what it needs to know?) and verification (how would anyone know it got it right?). Everything else in this article follows from that one move.

Five things that shift

None of these is a settled practice. They are a coherent hypothesis, and the sections below say what each one asks of you and where it can go wrong.

1. The artifact: write intent, not a story

A user story leaves room for interpretation because the person reading it brings the rest of the context. An agent brings none unless you supply it. The artifact that replaces the story is a short, structured file (call it intent.md) whose acceptance criteria are written so a test can check them.

# Intent: refund limit
Context: payments-service, see ARCHITECTURE.md section 4
Must: a refund above the account's daily limit is rejected with reason REFUND_LIMIT
Must: the limit is read from configuration, never hard-coded
Must not: change the settlement path or any public API
Out of scope: UI, reporting
Done when: tests/refund_limit.spec passes and the evals in evals/refunds.yaml do not regress

The test of a good intent file is simple: could someone with no access to the room where it was written implement it and check it? If not, an agent will fill the gap with a plausible guess.

2. Review: agents first, people where risk lives

The model of AI-native review I am proposing has three parts, and each carries a condition.

• An agent reviews first. A separate reviewer checks the generating agent’s diff against the style guide, the security rules and the original intent file. It is a filter, not an approver. Its value depends on being a different run, with different instructions, from the one that wrote the code.
• Discard, don’t iterate. If a generated change fails its tests, throw it away, fix the intent or the context, and generate a fresh one. Patching a broken attempt tends to carry its assumptions forward. This is a rule worth testing on your own work, not a law.
• People review by risk category. Regulated code, critical infrastructure, security boundaries and architectural drift always go to a person. Routine changes can be reviewed after merge, which is acceptable only where the release has automated rollback and the change cannot cross a boundary a person would have blocked. Post-merge review of anything that moves money or data is a decision to make deliberately, not a default.

The boundary between those categories is the real design work. It is the same idea as the commit boundary: decide in advance which effects need a human before they happen.

3. Testing: the tests are the boundary

When code appears in seconds, tests stop being a quality check after the fact and become the specification the agent has to meet. That makes writing the failing test first the safer default rather than a matter of taste.

• Functional and integration tests tend to carry more weight than unit tests here, because they pin behaviour the intent file describes rather than the shape of one implementation.
• Evals are automated tests for behaviour that is not deterministic. An eval set run on every change, with a threshold that blocks the merge, catches the quality drift a single passing test will not. A model can grade the output, but a grader that shares the generator’s blind spots grades its own homework, so keep a sample of human-labelled cases to check the grader itself.
• Snapshot comparison of previously accepted outputs catches silent regression.
• Static analysis and secret scanning (tools such as Semgrep and CodeQL) run on every commit, because plausible code from any author, human or agent, can contain an injection flaw or a hard-coded credential.

The failure to design against is a thin suite. With people writing the code, a weak test suite is slow. With agents writing it, a weak suite ships the wrong thing quickly and with confidence.

4. Roles and team size: a hypothesis, not a finding

The model I am proposing describes pods of three to five engineers orchestrating many concurrent agent tasks, in place of seven to ten people. Three roles recur: someone who writes structured intent, someone who decomposes work and manages the context agents read, and someone who builds the adversarial checks and watches production for drift.

I have found no controlled evidence for the team sizes, and none for the claim that agents already produce seventy to ninety per cent of production work. Treat both as things to measure in your own context. Two cautions on the roles:

• Verification is not a junior job by default. Deciding what a good check looks like takes the judgement that experience builds. Putting the least experienced people on the work that now matters most is a way to lose the benefit.
• Coordination overhead does not vanish; it moves. Fewer people means fewer handoffs, but concurrent agents need their own coordination, and someone has to own it.

What the evidence supports so far

Be wary of anyone who gives you a clean productivity number. The best controlled evidence is mixed and moving.

METR’s randomised study of 16 experienced open-source developers on 246 real tasks found that, with early-2025 tools, tasks took 19% longer when AI was allowed, even though the developers expected a 24% speed-up and afterwards believed they had been 20% faster. The authors say plainly that this is a snapshot of one setting and not a claim about most software work. Their February 2026 update, with 57 developers and more than 800 tasks, gave estimates that pointed the other way but with wide uncertainty, and METR itself calls the data “very weak evidence” because many developers declined to work without AI. It concludes developers are likely more sped up than a year earlier, without being able to say by how much.

The DORA 2025 research frames AI as an amplifier of what an organisation already has, magnifying strengths and weaknesses alike, with the largest returns from the surrounding system rather than the tools. That fits the argument here. If your intent is vague, your tests are thin and your review is a rubber stamp, agents amplify that.

The honest reading is that nobody has shown how much faster an AI-native pipeline is in general. What you can show is how much faster it is for you, if you measure it.

What to do first

1. Write one intent file for the next real change, with acceptance criteria a test can check, and see whether someone else could implement it.
2. Write the failing test before the agent starts, and make passing it the definition of done.
3. List the change categories that always need a person, and encode them so the pipeline enforces it rather than relying on memory.
4. Measure before you claim. Record time to merge, change failure rate and review time for a month before and after. Publish the method with the number.

Limits

This is design reasoning, with two research sources for the evidence section. The figure deliberately shows no latency or automation percentages: an earlier draft of the visual carried them, and I could not trace them to a source. If you have measured your own, they belong in a figure with the method beside them.

Sources and further reading

The METR and DORA pages listed above are the basis for every evidence claim in this article.