The first essay in this series argued that CMMI's core insight survives and its quiet assumption does not: process maturity still predicts delivery reliability, but the model was sized for code written by people at a human pace. This essay is about what takes the place of that assumption. A lifecycle built for agents is starting to take shape, in published methodologies and in the day-to-day practice of teams that have moved past the pilot stage. Its outline is consistent enough to draw. Agents execute the work. Humans govern intent, validation and outcomes. And two artifacts that used to rot between releases, the specification and the evaluation set, become the durable core of the project.
I will draw the lifecycle in the abstract and then, in every section, point at where each box lives in one concrete implementation: Explyt, an agent that runs inside JetBrains IDEs and uses the IDE as its source of facts about the project. I work at Explyt, so treat those passages as an author's worked example. The argument does not depend on the product; the product makes the argument easier to check.
The problem with drawing the old diagram faster
The first instinct of most teams is to keep the SDLC diagram and put an agent inside the box labelled "implement". Nothing else moves. Requirements are still written as prose for a developer who will ask a follow-up question in stand-up. Review is still sized for one or two diffs a day per reviewer. Tests are still written after the code, by the person who wrote the code. Deployment still waits for the end of a two-week cycle.
Then the agent produces a working change in twenty minutes, and every box around it starts to queue. The requirement was too loose to check against, so the reviewer reconstructs the intent from the diff. The tests the agent wrote pass, but nobody has decided whether they test the right thing. The two-week cycle now holds forty changes instead of eight, and the review step is where the sprint actually happens. This is the throughput gap from the first essay, now visible as a lifecycle problem rather than a staffing one. The shape of the process, not the speed of the coder, is the constraint.
You can watch this happen inside a single IDE session. Give an agent a one-line task in a Spring service and let it run in the default mode: it edits the service, touches a test, reports done. The diff is small and plausible. What you do not have is the question it should have asked about which callers were in scope, a record of which run configuration it used to claim the tests pass, or any reviewer output that was produced independently of the author. Every missing piece is a box on the old diagram that the agent skipped because nobody redrew it. The rest of this essay is about redrawing them.
What the emerging lifecycle looks like
Drawn without vendor labels, the lifecycle that keeps appearing has five stages and two lanes. Humans own the top lane. Agents own the bottom lane. The arrows between lanes are where the work actually gets accepted.
![ADLC lifecycle: two lanes and five stages. Humans govern Intent, Specification, Validation and Outcome; agents execute Plan, Generate and Evidence. Specification hands off to Plan, Evidence hands back to Validation, and the failure loop returns to the specification rather than the code.]
The lifecycle without vendor labels. Durable artifacts along the bottom: intent record, spec, eval set, change record, runtime evidence.
Three things in this picture are new relative to a classic SDLC diagram. The specification is written before generation and is the thing agents plan against, so it cannot be a loose paragraph. Validation is a distinct stage with its own artifacts, the evaluation set and the change record, rather than a gate inside "review". And the failure loop goes back to the specification, not to the code: if a regeneration fails validation, the fix is usually a more precise spec or a stricter eval, because regenerating code is now the cheap step.
Here is the same diagram with Explyt's names on the boxes, so each one points at something you can open. Intent and boundaries: the task you type plus Edit Scope, the list of files and directories the agent is allowed to modify for this task. Specification: the output of Plan mode, a plan with related files that you read and edit before implementation starts. Plan and Generate: the built-in agent working through the IDE's project model, symbol resolution, Find Usages, native Rename, Move and Delete, run configurations, inspections. Evidence: named run configurations executed by name, Debug mode where a failure is reproducible, and Agent Changes, the full diff of what was touched. Validation: Auto Review, a separate read-only agent that receives the original task and the final diff, and your decision on its findings. Outcome: the application running under the configuration you named. The lanes are the same; the boxes just stopped being abstract.
Where AWS AI-DLC fits
The most explicit published version of this pattern so far is the AI-Driven Development Lifecycle (AI-DLC) from AWS, described by Raja SP on the AWS DevOps blog on 31 July 2025. It is worth reading because it names the moving parts.
AI-DLC has three phases. Inception: "AI transforms business intent into detailed requirements, stories and units through 'Mob Elaboration', where the entire team actively validates AI's questions and proposals." Construction: AI "proposes a logical architecture, domain models, code solution and tests through 'Mob Construction', where the team provides clarification on technical decisions and architectural choices in real time." Operations: AI "applies the accumulated context from previous phases to manage infrastructure as code and deployments, with team oversight."
The operating rule underneath all three is the same one the diagram above draws: "AI creates a plan, asks clarifying questions to seek context, and implements solutions only after receiving human validation." AI proposes and executes; humans decide. The post also states that AI "saves and maintains persistent context across all phases by storing plans, requirements, and design artifacts to your project repository", which is the durable-artifact point made concrete: the spec lives in the repo, next to the code it produced.
At the scale of one developer and one task, Plan mode is Mob Elaboration with a team of one: the agent studies the project and the task, asks its clarifying questions, and writes a plan with related files that you approve before any code is generated. The plan is a file in the project, which is AWS's persistent-context point in its smallest form. What Explyt adds to the AWS sketch is the boundary. AI-DLC describes what the agent proposes; Edit Scope describes what it is allowed to touch while proposing it, so the Inception hand-off carries both the intent and its limits.
What the AWS post does not do is use the word evaluation. It talks about tests, generated in Construction. I treat that as a vocabulary gap rather than a disagreement: an eval set is a test suite whose purpose is to accept a regeneration, and once code is cheap to regenerate, that is what most acceptance tests become. AI-DLC is cited here as evidence that the lifecycle is being drawn the same way by people who arrived at it independently. It is not an endorsement of any tool, and the AI-DLC white paper was not reviewed for this essay.
Bolts versus sprints: what changes when the cycle is hours
AI-DLC replaces sprints with "bolts", which it defines as "shorter, more intense work cycles measured in hours or days rather than weeks", and replaces epics with units of work. The renaming matters less than the reason behind it.
A sprint is two weeks long because that is roughly how long a team of people needs to implement a coherent slice of work and get it reviewed. The sprint ceremonies exist to protect that human implementation window: planning at the start so people are not interrupted, review at the end so stakeholders see a batch, retrospective so the team adjusts. When implementation takes hours, the window the ceremonies protect no longer exists. Running planning, review and retro for every four-hour bolt is impossible, and skipping them means the bolt has no validation at all.
That is the fork every team hits. One branch keeps the sprint cadence and accepts that agents idle for most of it, which is safe and slow. The other branch adopts bolts and lets validation lag behind generation, which produces the tell from the first essay: throughput without verified output, reported as velocity. The branch that works is the one where validation is mostly automated, as an eval set that runs per bolt, and human attention is spent on the two things automation cannot do: deciding what the intent is and deciding whether the outcome meets it. Bolts without evals are simply a faster way to accumulate unverified change.
In practice a bolt in Explyt is one chat: Plan at the top, the approved plan as the spec, generation against Edit Scope, the named run configurations executed and their results in the transcript, then Auto Review starting automatically in the same chat when the main agent finishes. The ceremonies did not disappear; they collapsed into artifacts that are produced per bolt without a meeting. Planning became a file you approve. Review became a separate agent's findings tied to lines of code. The retrospective became the question you ask when validation fails: was it the spec, the eval, or the code. That is the only cadence at which bolts stay verified, and it is the reason the reviewer has to be a separate agent with no write access rather than the author re-reading its own diff.
Humans govern three things
The phrase "human in the loop" is too vague to design a lifecycle around. The emerging pattern is more specific about what humans keep.
Intent. What is being built, why, and what must not change as a side effect. This is written before an agent plans anything, and it is what a reviewer later checks the result against. If intent lives only in someone's head or in a chat thread, the agent will guess, and the reviewer will reconstruct. In Explyt the "must not change" half of intent has a mechanical form: Edit Scope is set per task, directly in the agent, and an agent that cannot write to a directory does not need to be trusted about it. The "what and why" half is the plan you edit before approving it.
Validation. Deciding what counts as evidence for this change, and then reading that evidence. The decision part happens before generation, as the eval set. The reading part happens after, and it is the only place where a green result gets turned into an accepted result. A passing eval that nobody has looked at is a claim, not a decision. Auto Review is built for the reading part: it receives the original task and the final diff, reads the code, uses the IDE's inspections, and returns findings tied to lines. It has no write access. Running it on a model from a different provider tends to surface a different set of mistakes. You decide which findings are valid, check the fixes, and re-run the affected checks; the merge decision does not move.
Outcomes. Whether the delivered behaviour, in operation, does what the intent said. This closes the loop back to intent and is where the next unit of work usually comes from. When an outcome is wrong and the failure is reproducible, Debug mode is how the agent is asked to confirm the cause before touching code: breakpoints, variable values and the call stack, then a minimal fix, then the original scenario and the related tests re-run. One such run confirms the fix for the scenario that was run, and nothing wider, which is exactly the boundary a validation lane should have.
Everything else, proposing a plan, breaking intent into units, generating code, generating tests, refactoring, drafting the change record, is work an agent can execute under those three controls. Where teams get into trouble is when they hand one of the three to the agent as well: letting it infer intent, letting it decide its own acceptance criteria, or treating "tests pass" as the outcome.
Specs and evals become durable artifacts
In a classic SDLC, code was the only artifact that reliably survived. Specifications were written to start the work and drifted the moment implementation began. Tests were owned by the code and rewritten when the code was. Six months later the code was the documentation, because it was the only thing that had been maintained.
In an agent-driven lifecycle the economics invert. Code is the cheap, regenerable output. The specification is the input to every regeneration, so it has to be correct or every regeneration is wrong in the same way. The eval set is how any regeneration gets accepted, so it has to be maintained or nothing can be accepted. The change record ties a spec to a change to the evidence that the change behaves, and it is what makes the whole thing auditable. These become the artifacts a team cannot afford to let rot, and the code becomes the one it can afford to throw away.
Look at which of these an IDE-native agent produces for free and which it cannot. The plan from Plan mode is a spec in the repository. The named run configurations are the eval set in the form the IDE already understands, so "run the evals" is a real operation rather than a summary. Agent Changes is the change record: the full diff, reviewable before you accept it. The Auto Review findings are the validation record for that diff. What the agent does not produce is the judgement that the plan is the right plan and the run configurations are the right evals. Those two stay human, which is why they are the two artifacts worth maintaining by hand.
This is the CMMI practice of a defined, measured process, rebuilt for a fast producer, which is the bridge back to the first essay of the series. It is also the reason the rule for choosing a first agent task is what it is: the tasks that fit first are the ones where a spec and an eval can be written before generation, an owner can be named, and the cost of an error is bounded. A team that cannot yet write those two artifacts for a task is not ready to hand that task to an agent, whatever the demo looks like.
Questions for an engineering lead
- Where is intent recorded in a form an agent can plan against and a reviewer can check against? If the answer is a ticket title, the agent is guessing. If the answer is an approved plan file and an
Edit Scope, you have the first two boxes. - What is the validation artifact for a change, and does it exist before the change is generated? If it is written after, it tests what was built rather than what was meant. A named run configuration chosen before the bolt is the simplest version.
- If a bolt finishes in four hours, what happens in the next four? If the answer is "wait for review", the cadence is still a sprint with an agent inside it. If a separate review agent has already returned findings, the human step is a decision rather than a reading.
- Which of your artifacts would you keep if the code were regenerated tomorrow? Whatever you would keep is what has to be maintained now.
Conclusion
The lifecycle that is taking shape is not the old diagram with an agent inside one box. Its stages look familiar, but the ownership has moved: agents execute planning, generation and evidence collection, and humans keep intent, validation and outcomes. The cycle shrinks from weeks to hours, and that only works if validation is automated per cycle and human attention is spent where automation cannot go. The artifacts worth maintaining change from code to the specification and the evaluation set that accept it.
The practical next step is small. Pick one unit of work. Write the intent and the eval set before any generation, run the unit as a single bolt, and note which artifact you had to fix when validation failed. If it was the spec or the eval and not the code, you have drawn the new lifecycle for yourself, on your own repository.
If your team works in JetBrains IDEs, that bolt is one Explyt chat: Plan for the spec, Edit Scope for the boundary, named run configurations and Debug mode for the evidence, Auto Review before you make the call. Documentation and download are at explyt.ai.
Series: from the 40-year playbook (BR-BR-SDLC-01), to the lifecycle taking shape (this essay), to how individual steps in the IDE change under it. Bridged to the R-08 anchor and to R-07, the rule for choosing a first agent task you can verify.
Top comments (0)