The ADLC Loop

The agentic development lifecycle — ADLC — replaces the phase-gate relay race with one continuous loop. A developer expresses intent; agents carry it through implementation, testing, documentation, deployment, and monitoring; humans stand at two stations where judgment matters; and what the loop learns feeds the next turn.

Around the loop once

1. Express intent — the developer states what to build: a feature, a fix, an outcome. This is the prompt, but at lifecycle scale.
2. Plan + implement — agents translate intent into a plan and then into code.
3. Test + docs, inline — tests run as part of implementation, and documentation is generated alongside the change — not reconstructed afterward from memory.
4. Human review — the developer reviews the plan and the diff, approves, redirects, or asks for fixes. The loop does not proceed without a yes.
5. Deploy + ship — after approval, agents handle the release.
6. Monitor + remediate — agents watch production continuously. Something breaks at 2 a.m.? Roll back to the last stable version first, report to the humans in the morning.
7. Learn + iterate — the run's outcomes update memory: what broke, what worked, what the next plan should know.

Then around again. Cycle time collapses from weeks-or-months to hours — not because any single step got magically faster, but because the loop stopped waiting. In a traditional lifecycle, most elapsed time is handoff: work sitting in a queue for the next human. Agent-to-agent handoff has no queue.

The beat inside every station

That is the loop at lifecycle scale. Zoom into any one of its stations and there is a smaller loop running inside it, and getting that inner one right is what makes the outer one survivable.

Anupam Mishra states it as the first principle of AWS's AI-DLC method, and it starts from an observation about model behaviour rather than about process: asked to do a job, a model "tries to be very, very helpful," and being very helpful is how you end up with authentication, log management, and three applications you did not ask for. The control is not a better instruction. It is seeing the intent before the work:

We ask AI to create a plan. We humans will validate the plan, and that's where we do course correction… AI executes the plan, and human again verifies the output.

Four beats — plan, validate, execute, verify — and the important part is the stated reason for them. It is not quality control. It is alignment: "this brings AI's brain and human brain at the same level." A plan is the cheapest possible representation of a decision. Redirecting one costs a sentence; redirecting the same decision after it has become nine hundred lines costs a review nobody has time for.

A named instance: AI-DLC

AWS ships the loop above as a method with a name. It has three phases — inception, construction, operation — and, in Raja SP's words, "typically the nine stages represented there are very typical of these number of stages." Each stage runs the four beats. Each stage's output becomes the next stage's input, and the claim made for that chain is worth isolating: "the context that each stage produces gets richer and richer semantically as you go down the stages, and the AI's output is far improving as you go down those stages."

That is a claim about context assembly, not about the model. The last stage produces better code than the first stage would have, from the same model, because by then it is reading a specification rather than a wish.

The stages are chosen, not run

The part that separates this from a workflow diagram is that the sequence is not fixed. A defect fix does not need all nine stages. A business-rich feature on an existing codebase needs most of them. A greenfield build needs all of them. So the method does not prescribe the path — it plans it, and asks.

In the session's worked example — adding support for the HTTP QUERY method to FastAPI, taken from a real issue on the repository — the agent runs a workflow planning stage whose entire job is to decide which later stages apply, and then shows its decisions for approval before executing any of them:

Seven of ten stages fired. The three that did not were skipped for reasons a reviewer can disagree with — which is the property that matters. A fixed workflow that always runs everything is not more rigorous; it is a workflow whose skipped steps have become rubber stamps.

The method is configuration

Here is the detail that decides whether any of this is architecture or just advice. AI-DLC is not delivered as a document engineers are asked to follow. Raja SP: "we have distilled the AI-DLC methodology into steering files… it's a way to take an agentic coding tool, customize it to follow our workflow. Without it, that agentic coding tool might do managed approach and whatever."

A lifecycle methodology, historically, is a book, a training course, and a poster. This one is a directory of rules the agent reads at the start of a run, published open source. The nine stages, the four beats, and the skip logic are all instructions — the harness primitive — pointed at a team's process rather than at a single task.

Which is the quiet reveal this pillar closes on: nothing in the paragraph above required a different model.

In the wild

The key differences, side by side: sequential handoffs become fluid agent flow; humans-write-code becomes agents-write, humans-review; docs-as-afterthought becomes docs generated inline at every phase; manual midnight incident response becomes agent-assisted remediation — self-healing rollback before anyone wakes up.

The loop is the easy part

Drawing the loop takes a whiteboard. Running it raises a harder question — one every team hits the moment agents can plan, code, test, and deploy: what, exactly, do the humans still own?