Agentic SDLC vs STLC: What Changes in Each Life Cycle

What Is Agentic SDLC?

An agentic SDLC is a software development life cycle in which AI agents do the work inside the classic phases instead of assisting the human who does. Planning, design, implementation, testing, deployment and maintenance all remain. What moves is the actor.

The term now appears in the literature rather than only in vendor copy. A 2026 arXiv paper by Happy Bhati, Agentic AI in the Software Development Lifecycle, proposes a six-layer reference architecture for these systems and explicitly contrasts the traditional SDLC with an emerging Agentic SDLC.

Each shift below lands a downstream cost on testing.

• The unit of work shrinks - planning moves from a two-week sprint to a task an agent finishes between coffees, so the number of independent changes arriving at the test gate per day goes up by an order of magnitude.
• The developer becomes a reviewer - the scarce resource stops being the ability to write the code and becomes the attention needed to check it, which is a different constraint with a different ceiling.
• Behaviour stops being fixed at build time - a prompt change, a truncated context or a model update can alter what the system does on identical inputs, so the assumption that behaviour is specified once and validated once no longer holds.

For the classic version of these phases before agents entered them, the software development life cycle guide covers each stage and its deliverables.

What Is Agentic STLC?

An agentic STLC is the software testing life cycle re-derived for software an agent wrote. The six phases hold. Their inputs change, because the specification, the code and often the tests now come from the same non-deterministic source.

In Assistance to Autonomy, a systematic literature review by Spyridon Alvanakis Apostolou, Jan Bosch and Helena Holmstrom Olsson, a synthesis of 92 manually verified primary studies found that output verifiability is the primary enabler of agentic AI.

The same review reports that later life cycle phases, whose outputs are objectively evaluable through executable feedback, show the highest maturity and industrial presence, while earlier phases remain almost exclusively academic proofs-of-concept. Alvanakis Apostolou and colleagues also name the Planner-Executor-Reviewer split as the dominant architectural pattern.

Agents are good at the phases where something can be run to check them. That makes the STLC the machinery keeping an agent’s output checkable at all, and our software testing life cycle guide covers the six phases in their original form.

Agentic SDLC vs STLC: Key Differences

The two cycles overlap on vocabulary and diverge on what counts as done. Reading the difference off the table is faster than arguing it from first principles.

One row carries the rest. When the primary actor on both sides is the same model instance, the STLC column collapses into the SDLC column and the pipeline stops producing information, because a system cannot independently confirm its own reading of a requirement.

If the classic distinction is what you need first, SDLC and STLC compared sets out the phases and differences without the agentic layer on top.

Phase-by-Phase Remap of the Testing Life Cycle

Each STLC phase keeps its name and loses an assumption. Walking them in order shows exactly where the work moves.

• Requirement analysis - the phase assumed a human-authored spec to test against. When the requirement arrives as a prompt and the agent expands it into acceptance criteria, the test basis and the implementation share an origin, so a misreading is invisible to both. Capture the acceptance criteria as a separate artifact before the agent starts building.
• Test planning - scope used to be set per release. With agents opening changes continuously, the plan has to be expressed as a standing policy about which changes need which depth of check, because no human is sizing each batch.
• Test case development - authoring stops being the bottleneck and review becomes it. The question moves from how many cases you have to whether any of them would fail if the feature were wrong, which is the property an agent-authored suite most often lacks.
• Environment setup - reproducibility now decides whether an investigation is possible at all. A run you cannot replay is a run you cannot investigate, and agent runs vary on identical inputs, so the environment has to pin what it can and record what it cannot.
• Test execution - the count of runs per day rises with the count of changes, so execution has to be non-interactive, parallel and machine-readable end to end, with the summary rendered for the calling system before it is rendered for a person.
• Cycle closure - closure used to report pass rates. It now has to report what was actually proven and what was left uncovered, since a pass rate over agent-authored cases measures the agent’s self-consistency rather than the product.

Requirement analysis and cycle closure are the two phases that need a system of record, because both depend on a link between a requirement and the run that exercised it. TestMu AI’s Test Manager generates structured test cases from natural language, pulls manual and automated results into one pass or fail view, and traces every requirement through to its tests, runs and defects with two-way JIRA and Azure DevOps sync.

That traceability link is what turns cycle closure back into a statement about the product. The Test Manager documentation covers repositories, plans, cycles and the execution view.

Note: Trace every requirement to the test, run and defect that covers it, and close an agentic cycle on what was proven rather than on a pass rate. Try TestMu AI free!

Entry and Exit Criteria Under Agents

Entry and exit criteria were the most procedural part of the STLC and are now the most important. They are the only points in an agentic pipeline where something outside the agent gets a vote.

An exit criterion survives the shift when it satisfies three properties. It is machine-readable, so a pipeline can branch on it without glue code. It is reconstructable, so a reviewer can see months later why it passed. It is attributable, so the result points at the requirement it covers.

This is where an independent verifier earns its place. TestMu AI’s Kane CLI is positioned as an agentic quality verifier rather than a browser driver: it validates rendered UI in a real Chrome browser from a natural-language objective, and its agent mode emits plain NDJSON, one JSON object per line, alongside an evidence pack of per-step screenshots, a HAR network log and failure records.

The strictness of that gate is a flag rather than a convention, which is the part that matters when an agent is calling it. Running the installed binary on my Windows machine shows the run contract directly.

$ kane-cli --version
0.8.10

$ kane-cli run --help
  --mode <name>                Run mode: 'action' (strict - hard-stop on
                               auth/blocked/error) or 'testing' (lenient - fall
                               through). Overrides config; default: testing.
  --assertion-mode <mode>      Assertion mode: 'dom' (default - DOM-based
                               extraction & assertions, vision fallback) or
                               'visual' (vision model only). Overrides config.
  --final-validation <on|off>  Final validation: append the system cp_final
                               checkpoint verifying the objective as a whole.
                               Overrides config (default: off).
  --agent                      Agent mode: plain NDJSON output, no colors/UI

Two flags in that output are the agentic STLC in miniature. --final-validation appends a checkpoint that verifies the objective as a whole rather than the steps individually, and --agent makes the result parseable by the calling system instead of by a person.

Getting started with the command surface is covered in the Kane CLI documentation, and the wider pattern of gating a merge on agent-produced proof is covered in evidence-based QA for agentic test runs.

A fair objection arrives at this point. Teams already running an autonomous coding agent ask why that agent cannot run the check itself, since it can open a browser, execute code and report what it found.

The capability is genuinely there. An autonomous coding agent plans its own work, runs what it wrote and reports the outcome, which covers most of the mechanical surface of a test run. The open questions are who pays for the exploration and who signs off on the result, and both come into focus once you price an authoring agent against a verifier.

How to Adopt an Agentic Life Cycle

Adoption fails when a team turns on agents across the SDLC and leaves the STLC as it was. Sequencing the change in this order keeps the gate ahead of the volume.

• Write the acceptance criteria down before the agent starts, in a place that is not the prompt. This is the only step that stops the test basis and the implementation sharing a misreading.
• Pick one flow that already fails expensively in production and put an independent check on it. A single gated flow teaches more than a broad rollout with nothing gating.
• Make the verdict machine-readable before you scale the number of runs, because the day agents open thirty changes is the day nobody reads a human-formatted report.
• Separate the reviewer from the author at the system level, not the prompt level. A second call to the same model with a different instruction shares the original misreading.
• Record what each run proved against which requirement, so cycle closure reports coverage of the product rather than agreement within the agent.

Teams already running this loop tend to arrive at it from the quality side rather than the delivery side, and agentic quality assurance covers the practice end to end.

Conclusion

Pick the one flow whose failure costs you the most and put a check on it that the authoring agent does not control. That single gate tells you more about your agentic readiness than any maturity model will.

From there, wire the verdict into the pipeline and the requirement link into your test records, so closure reports what was proven. TestMu AI’s Test Manager holds the traceability half and Kane CLI returns the verdict half.