Agentic SDLC quality: matching AI agent autonomy with controls - a.k.a bringing Quality back to the loop

[szilardszell]

Describe the enquiry

I would like to get feedback on the below concept that I have presented at three conferences now, and what I think is helping Quality Engineers to become Quality Governors, owning the Control Points. I believe we need DevOps as a Safety net for Agentic SDLC. My Quality Model is to help that movement.
My Ask: Does this model resonate with you? Does it help to deep dive into testing topics related to AI driven SDLC? Would you add or remove any of the Control Points?
Thanks for the feedback

Agentic SDLC quality: matching AI agent autonomy with controls

"It took nine seconds." That's how one founder summed up the moment an AI coding agent deleted his production database earlier this year. Nobody had decided to let the agent touch production. It got there anyway.
That sentence captures the problem I want to unpack here. We're giving coding agents more autonomy than our quality controls were built for, and we usually do it by accident: through a token scope, a toggled approval prompt, or an instruction we assume is enforced. Our gates were designed for human authors working at human speed. Agents write faster, run longer, and fail more quietly the more freedom they get.

So the question for quality engineers isn't whether to use agents. It's where the controls must sit, and which ones each level of autonomy has to pay for. That's what the Quality Model for the Agentic SDLC answers. I presented it this autumn at HUSTEF, as a keynote at Testing Portugal, and at AutomationSTAR.

AI agent autonomy levels from L1 to L5

The car industry already has a language for handing control to a machine: the SAE levels of driving automation, from lane-keep assist to fully self-driving cars. The model borrows that idea through the five levels of autonomy defined by ASDLC.io.

An autonomy level describes permissions and loop structure, not LLM capability. The same model can run at every level. What changes is the control around it.

Level	What it looks like	Driving analogy	How it characteristically fails
L1 Assistive	Ghost text in the IDE. You type, it completes. You are still the author of every line.	Lane-keep assist	A hallucinated API parameter you did not notice, because it looked right.
L2 Task-based	"Write tests for this function." "Refactor this file." You get a diff. You read it. You accept it.	Hands on, constantly monitoring	Isolated logic bugs and localized debt that survive review because the code reads plausibly.
L3 Conditional	"Fix issue #482." Twenty minutes later a pull request exists. You never saw the forty steps in between.	Hands off, eyes on	Regression to the mean: plausible, average, architecturally mediocre code that passes every test.
L4 High	The agent triages the bug queue itself, fixes what it can, ships behind a flag. You read the telemetry.	Mind off, asleep in the back seat inside a geo-fence	Silent drift: it compiles, tests pass, and the system slowly diverges from what anyone intended.
L5 Full	Not observed in production anywhere. Roadmaps and keynote slides.	No steering wheel	Systemic alignment failure. The codebase evolves past human legibility.

Most teams sit at L2 or L3, and L3 is the practical ceiling today. Read the last column top to bottom: failures get quieter as autonomy rises. That's the whole argument for controls getting louder.

Brakes vs. steering: deterministic and probabilistic controls

The model rests on one distinction. A deterministic control, like a hook or a CI gate, stops an action no matter how the agent reasons. That's a brake. A probabilistic control, like an instruction or a reviewing agent, only influences what the agent does. That's steering. You need both, but only one of them can stop the agent.

The model places a control point around the stages of the DevOps loop from intent description to production. One more, CP-1, governs the agentic system itself. It is numbered first because it logically comes before everything, but it's easiest to understand last.

The overview of the Control Points

The below picture represents the Control Points and their relation. While they are represented as a sequence, we all know they appear within the DevOps loop, so even the agents work back and forth, improving on received feedback

Further reading and details: https://www.eficode.com/insights/blog/agentic-sdlc-quality-controls

Collaboration

No response