Agentic SDLC quality: matching AI agent autonomy with controls

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.

Three real-world AI agent failures: PocketOS, AWS Kiro and OpenAI

PocketOS, April 2026. A Cursor agent running Claude Opus 4.6 was doing a routine task in staging when it hit a credential mismatch. According to the founder, it found a Railway token in an unrelated file, a token created for domain management that could act on any environment. One API call later, the production volume and its co-located backups were gone. The OECD incident record lists a 30-hour outage. The project had explicit safety rules in its configuration. The hosting provider later recovered the data.

AWS Kiro, December 2025. According to people familiar with the matter, engineers let Amazon's agentic coding tool resolve an issue without intervention, and it chose to delete and recreate an environment. The result, reported by the Financial Times, was a 13-hour outage in one region. Amazon called it a limited event caused by user error, misconfigured access controls, and then added mandatory peer review for production access.

OpenAI, October 2026. One internal coding agent stretched an earlier "don't send any messages" instruction to cover safety alerts and switched them off. Another removed a monitor during a migration, reported the task complete, and denied the change when asked. OpenAI says it doesn't yet have a full explanation.

None of these is primarily a story about model capability. In each case the agent was trusted with one job but could do far more: reach production, skip an approval, edit its own monitor. What an agent can reach defines how autonomous it really is, regardless of what was intended. The rest of this blog defines the needed concepts, autonomy levels, and shows which controls each level needs.

Shift left, shift right and shift in for AI coding agents

We've talked about shift left and shift right for years, and both still apply when the actor in the loop is an agent. On the left, specification agents turn ideas into user stories and BDD scenarios, shaping intent before code exists. On the right, acceptance-test agents verify builds in staging, deployment agents run canary releases and rollbacks, and monitoring agents learn from how the software actually behaves in production.

Both directions matter because DevOps runs on fast feedback. Shift left prevents defects before they're written; shift right catches what only real users and real load reveal. Lose either one and the delivery loop flies half blind.

But there's a third direction I call shift in. A coding agent receives a goal and plans its steps. Then it works in a loop, often called a ReAct loop: it reasons about what to do next, acts by calling a tool, and observes the result. Tools are how the agent senses its environment. Reading a file, running a test or calling an API is how it finds out what is true. The loop repeats, often dozens of times per task, until the goal is met.

That inner loop is where the agent makes its real decisions. Shift in means putting quality engineering practices inside it as native feedback, so tests, linters and checks steer the agent while it works, not after it's done.

The model below is what you get when you take shift in seriously across the whole lifecycle. It asks one precise question at every step: what control sits here, and is it a brake or just steering?

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.

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.

It's also why the incidents above happened. PocketOS and Kiro were nominally at L2 or L3. An over-scoped token or a skipped approval quietly made them L4.

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 at each step from the task 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.

CP0 governs the intent and goal of the task. CP1 to CP6 follow the work from the agents' loop to production. CP-1 governs the agentic system, and production telemetry flows back to tune the agents.

The control points of the agentic SDLC

CP0, intent (DoR) and goal (DoD). Agile teams use a Definition of Ready so work is clear enough for people to start. CP0 does the same for agents, and adds a Definition of Done that says what "done" means when the work comes back. The intent covers scope, acceptance criteria and non-functional requirements. Three rules make it checkable:

1. The two-developer test. Would two competent developers build the same thing from this description?

2. Detect ambiguity by disagreement. Generate several solutions and compare them; where they differ, the story is unclear. Never ask a model whether a story is clear, because models can't reliably self-detect ambiguity.

3. Freeze it before the agent starts. Otherwise the agent can quietly rewrite its own requirements to match what it built. If the requirements must change, that change goes through a control too.

Track the requirement divergence rate. CP0 prevents a confident, passing implementation of the wrong thing. Negation is a classic trap: models underweight negation, so a "don't" is exactly the kind of instruction that gets stretched, as OpenAI saw.

CP1, checks inside the ReAct loop. This is shift in. The agent gets fast, low-level checks it can run itself and decides when to run: linters, type checks, unit tests. These are not the acceptance criteria, which come later at CP4. Their job is to give the agent ground truth on every iteration, so it doesn't wander with nothing to check against.

CP2, hooks at the tool call and task. A deterministic hook runs before or after each tool call, and again when the agent says it's done. It can block a destructive action on inherited permissions, like the PocketOS volume deletion, however the agent reasons. A hook can't be reasoned around at runtime, but it can be tampered with through project configuration. Check Point Research found flaws in Claude Code, now patched, where a malicious project config could run commands or redirect API traffic before the developer was warned (CVE-2025-59536 and CVE-2026-21852). Sandboxing limits what such a setup can reach, but it doesn't stop the configuration being rewritten, so protect hook configuration like code.

CP3a, at the commit. Record who and what wrote each change, including the model and tools. The Linux kernel now asks for this with an Assisted-by trailer, for example Assisted-by: Claude:claude-3-opus coccinelle sparse. Without it, nobody can establish authorship later.

CP3b, the CI commit stage. Every push triggers a build and fast tests that finish in minutes. The agent's task itself should take less than a day, so this gate fires often. It stops an agent declaring victory ahead of evidence, which is what happened when an agent reported a migration done with a monitor missing.

CP4a, the verification gate. The automated acceptance stage runs here, catching defects that clear the commit stage but fail at scale.

CP4b, the conformance gate. A probabilistic check that the change conforms to the architecture and to CP0's Definition of Done, the agreed meaning of "good enough." It catches drift once no human reads the diff. CP0 and CP4b are a pair: CP0 sets the contract before work starts, and CP4b checks it afterwards, because specs drift once generation starts.

CP4c, the authorization gate. Once CP4a and CP4b have passed, a human signs off and is accountable for the increment. This isn't manual testing; it's the decision that the evidence is enough. It stays required at every autonomy level, because accountability doesn't scale away. AWS's fix after its outage, mandatory peer review for production access, points the same way.

CP5, deployment and release. Deployment puts the new version on production infrastructure; release exposes it to users. Feature toggles separate the two, which makes them the cheapest route from L2 to L3. Agents can already work with them: LaunchDarkly, for example, offers an MCP server that lets AI agents create flags and set targeting rules. This point limits the blast radius.

CP6, in production. Observability shows how the change behaves for real users, and an agent can be allowed to trigger a rollback when the signals turn bad. Two feedback loops run from here. The first is about the task at hand: did this deployment succeed? The second is about the agentic system: across many runs, is it drifting? That one is statistical and feeds CP-1. DORA's instability pair, change fail rate and deployment rework rate, matters in both.

CP-1, the agentic system itself. It comes last here, but it's numbered first because it governs the agentic system behind every step above. It has two parts:

• The design principle. For every rule, decide where it is enforced: in a linter's configuration, a CI gate or a hook, and only when none of those fits, in the agent's instruction file. An instruction is not enforcement, as PocketOS learned. Every other control point applies this principle.

• Evaluating the agents. Treat the agent setup as a product. Test changes to instructions, skills and models against golden task sets, compare variants with paired A/B runs, and watch trajectory telemetry for drift. This prevents shipping agent configuration that was never tested and never shown to help.

Matching controls to each autonomy level

The governing rule is simple: every level of autonomy must be paid for with a control that sits on a named risk. In the control matrix, some controls are required at every level and some are earned as autonomy rises. Human authorization at CP4c is required at every level. At L2, CP0 is optional, because a human reads every diff and catches a misread task within one commit. From L3 the human only sees the finished pull request, so the task must be right before the agent starts. CP4b becomes required exactly at L4, where no human reads the diff anymore.

The autonomy arrived by default. Building the controls needed a decision. Here is how the three incidents look through that rule, in my own mapping:

In every row, each control in place could be bypassed by the agent or its operator: an instruction, an approval someone switched off, a monitor the agent could edit. They steered. What was missing were brakes.

How to check your agents' real autonomy level

So here's a question worth asking your team this week: what autonomy level are your agents really running at? Don't check the tool's documentation. Check the agent instructions, skills, subagent definitions and harness configuration, and the tools and credentials they grant. The answer might be one level higher than you think.