What is an AI-driven development lifecycle?

A way of building software where AI agents do most of the planning, writing and testing, and people make the decisions: what to build, what counts as done, and whether it ships. AWS describes a version of it as AI-DLC, with phases for inception, construction and operations, and short cycles in place of sprints.

What is the most common failure when agents write code?

False greens: work reported as complete or passing when nothing real was built or tested. Tests that were never written pass trivially, and an agent can describe code instead of writing it. The fix is to define done as evidence that exists, checked by something other than the agent that did the work.

How should a team start using an agentic development lifecycle?

Pick one real feature on one repository. Write the intent and acceptance criteria first, break the work into small units, verify each unit independently, and have a named person review and approve what ships. Expand only once that loop is boringly reliable.

An AI-driven development lifecycle, in practice

In July 2025 AWS published a post on what it calls the AI-Driven Development Life Cycle, or AI-DLC. The argument is simple and, I think, right. Most teams use AI in one of two ways: as an assistant bolted onto a process designed for humans, or as an autopilot expected to produce whole applications on its own. Neither works well. AWS proposes a third shape, where AI plans, asks clarifying questions and implements, and people make the decisions.

I have been running something close to that for most of the past year. I built a multi-agent delivery system that takes a written intent and turns it into shipped software. It built this website, and it helped ship Cairn, a native iOS app now on the App Store. It has also failed in ways that taught me more than the successes did.

This is what transfers to a normal engineering team, without needing my setup.

Write the intent down before anything writes code

AWS calls this phase inception. In practice it means the most valuable human hour in the whole lifecycle is spent before any code exists: stating what you want, who it is for, and what "done" looks like as checkable acceptance criteria.

Agents are extremely good at building the thing you described. They are not good at noticing that you described the wrong thing. A vague request produces a confident, plausible, wrong result, faster than a person ever could.

The human approves the spec, not every line. That is the trade that makes the speed real.

Keep units of work small

The single biggest reliability lever I found was size. Agents handle a change that touches one or two files well. Give them five and quality drops off a cliff: they lose track, spend their effort deliberating, or rewrite things they were never asked to touch.

Small units are also easier to verify, easier to roll back, and easier for a reviewer to actually read. AWS replaces sprints with "bolts" measured in hours or days. The same instinct applies below the sprint: make each unit of work small enough that one person can understand the whole diff.

Never let the builder grade its own work

The thing that wrote the code cannot be the only thing that checks it. That sounds obvious for people. It gets forgotten with agents, because the same tool that writes the code will happily write the tests and report that they pass.

Separate the roles. One step builds. A different step checks the result against the acceptance criteria written in the spec, using evidence: the file exists, the test exists and covers the case, the page renders the right text. Review is a third, distinct step.

Distrust green

The defining failure of agentic delivery is the false green: work reported as complete when nothing real happened. I have seen every version of it.

A test suite passed because the tests were never written.
An agent explained the code it would write, in prose, and never wrote a file. The build passed, because nothing had changed.
Work was built against an out-of-date copy of the codebase, so the files it was meant to change were not there. Every check returned "could not verify", which the system treated as a pass.

The rule I run on now: green means the evidence exists, checked by something other than the agent. "No failures found" is not the same as "it worked", and a dashboard that makes those two look alike is lying to you.

Check that your guardrails actually fire

I gave every unit of work a fence: a list of the files it was allowed to touch. The plan described the fence. The logs showed it was never switched on. One step in the pipeline quietly dropped the field, so for months every unit could touch anything.

Guardrails fail silently. Test them the way you test features: make something deliberately break the rule and confirm it gets stopped.

Edit, don't regenerate

Early on, the only way my agents could change an existing file was to rewrite the whole thing. On a large file that meant dropped functions, duplicated types and a spiral of repairs. Switching to precise, anchored edits, change this exact block and nothing else, turned editing existing code from the weakest part of the system into a reliable one.

If your team's agents keep "fixing" files by regenerating them, that is the first thing to change.

Put a budget on every loop

Agents retry. Left alone, a stuck agent will retry until the bill arrives. Every loop needs a ceiling, a test for whether it is making progress, and a handoff to a person when it is not. Cheap models can afford more attempts than expensive ones; the stop condition matters more than the number.

Humans still read the diff, and see what shipped

This site has an automated loop that proposes small improvements, which I approve before they ship. For nine weeks it shipped internal links to a page that did not exist, eleven of them, and nobody noticed. I had been approving the intent ("add a link toward the contact page"), not the change itself.

The fix was not more automation. Now every change that ships sends me the exact diff. If you approve agent work at the level of intent, make sure someone also sees the result.

Know what your system is actually good at

My delivery system is excellent at web applications. When I pointed it at a backend specification, it produced a polished web front end with nothing behind it, and reported the work complete. Every check passed, because every check assumed a web app.

Before trusting any agentic lifecycle with a new kind of work, run one real piece of that work all the way through and look at what comes out.

Keep the context in the repository

AWS makes this point and it holds up: specs, plans, decisions and acceptance criteria belong in the repository next to the code. Agents start each session with no memory. Whatever context lives only in someone's head, or in a chat thread, is context the next session does not have.

How this maps to AI-DLC

AI-DLC phase	What it looks like in practice
Inception	A written intent with acceptance criteria, approved by a person
Construction	Small units of work, built by agents, verified independently against the criteria
Operations	A person sees exactly what shipped, with a way to undo it

Where to start on Monday

Pick one real feature on one repository. Not a demo.
Write the intent and the acceptance criteria before anyone opens an agent.
Break it into units small enough to review in a few minutes each.
Verify each unit with something other than the agent that built it.
Name the person who approves what ships, and make sure they read the diff.

Expand only once that loop is boringly reliable. Boring is the goal.

If you want help setting this up on your own codebase, that is what our agentic software delivery pilot does: one repository, one real feature, shipped the new way, with your team.