Earned Autonomy: Governing AI Coding Agents Across the SDLC

What does earned autonomy mean for AI coding agents?

The idea fits in one sentence: an agent earns autonomy where automated checks can prove its work, and loses it where they cannot. Autonomy is not a setting you choose once. It is a status the agent holds for a given kind of work, and evidence decides whether it keeps it.

Why is one global setting the wrong approach?

Most teams pick a single position. Either a human reviews everything, which does not survive the volume an agent can produce, or the agent is trusted everywhere, which works until the first change nobody understood reaches production. Both are global answers to a question that varies by task.

A documentation tweak and a change to how personal data is stored do not carry the same risk, and a well-tested module and a brand-new domain do not offer the same safety net. The agentic-sdlc framework, a working framework I maintain, sets autonomy per stage and per risk level, and ties each level to the evidence required to grant it. It rests on three commitments:

• Accountability stays human: a named person owns intent, architecture and each release decision.
• Autonomy is granted by evidence: more autonomy needs more automated verification, not more optimism.
• Every stage leaves an artifact: if it is not written down, tested or recorded, it did not happen.

What are the autonomy levels, and what does the human still own?

The framework defines four levels, from L0 to L3. The table below follows its own definitions. Autonomy is set per stage, never above L1 on data or actions you cannot undo, and it drops one level after any incident.

How does the framework structure accountability across the lifecycle?

The levels say how much the agent may do. The stage contracts say what must exist before work moves on. Each of the eight stages has an exit criterion and a proof, so accountability is attached to an artifact rather than to a conversation.

• Intent: problem, users, testable acceptance criteria and non-goals, recorded in a SPEC.md.
• Architecture: boundaries, data flow, risks and decisions, recorded as decision records.
• Agent build: a small change against the spec, with tests alongside, delivered as a pull request.
• Human review: the diff is understood, and security and data handling are checked against a checklist.
• Verify: tests, evals and regression checks pass, shown by CI and an eval report.
• Release gate: criteria met, limits documented and rollback known, in a release record.
• Deploy: a versioned, reproducible release, shown by the pipeline log.
• Measure: usage, quality, cost and incidents recorded, with post-mortems.

How does NOVA's Engineering feature apply it?

NOVA is my personal product agent, a public beta repository with no licence, and used by 800 employees at Devoteam. Its Engineering feature takes an intent or a GitHub issue and turns it into a specification, a design, code, tests, a pull request, a review, CI repairs and a merge, behind approval gates.

It offers two modes. In Guided mode, a human validates the plan and the merge. In Autopilot, NOVA goes on its own up to the merge. In earned-autonomy terms, that is the difference between keeping the human at two decision points and removing them. My own reading is that Autopilot should be a promotion a project has earned, not a default, and that the framework's rule about irreversible data and actions applies to it fully.

The framework's README places NOVA at stages 1 to 4, orchestrating plans, approvals and deliverables. It relies on ORBIT for governed context, FORGE for evaluation at stages 5 and 6, and TrustRail for controlling what agents may do. NOVA, ORBIT, FORGE and TrustRail are public betas, and I make no claim of production validation for them.

What should you measure before raising autonomy?

Evidence is the currency, so decide what counts before you promote anything. The framework suggests a short cycle: set a starting level per stage, defaulting to L1, run for two weeks, measure, then promote or demote a stage. Its metrics are defined in the repository and are marked not yet measured until they are, and I keep that label.

Beyond that, the following checks are my own suggestions, not framework requirements. I would not raise a level without answers to these:

• How often review found a problem the automated checks had missed, because that gap is the real limit of autonomy.
• Whether the tests exercise behaviour or only the arithmetic of the code, since an agent can write tests that pass without proving anything.
• Whether the real stack was run end to end, not just the unit tests.
• How large each change was, and whether reviewers could still understand it.
• What an incident cost and whether the level dropped when it should have.

What are the failure modes to plan for?

The framework lists agent-specific risks on top of classic SDLC risks: scope drift, tests written to pass, invented dependencies, leaked secrets, runaway cost, unreviewed volume and context rot. Three of them are, in my experience, the ones that quietly defeat governance.

• Review fatigue: when an agent produces more diffs than people can read, review becomes a click. The remedy is smaller changes and a lower level, not a longer checklist.
• Unowned agent output: code nobody accepted responsibility for. The first commitment answers it, because a named person owns each release decision.
• Silent scope creep: the agent does a little more than the spec asked, and nobody notices because the tests still pass. A written spec with non-goals is the control.

Is it open source, and has it been validated?

agentic-sdlc is a framework, version 0.1, under the MIT licence. It is the only project of mine that I call open source. It was distilled from building NOVA, ORBIT, FORGE, TrustRail and several prototypes, and its README states that it has not been validated by an independent study.

Its case studies are drafts reconstructed from public commit histories. One pattern they report is that the defects that cost most were found by executing the real thing, not by the test suite. That is a reason to treat the framework's levels and thresholds as judgment calls to adjust to your own risk, and to read my numbers as a starting point, not a standard.