You can't drive through San Francisco without passing a billboard of an AI company claiming that Y% of its code is written by AI. Companies are racing to announce that they use AI more than their competitors, but the statistics they use are poorly defined.
How do you really quantify AI adoption though? In terms of characters accepted from autocomplete? Code diffs that come from a chat window? The number of lines in a PR that an agent opened? As a result of this confusion, wildly different businesses can report the same figure: one where humans review every AI-generated code change, and one where AI develops features end-to-end and nothing is human-reviewed at all. In this post we propose a replacement for the statistic: a taxonomy we call levels of autonomy in software development.
In January 2026, Dan Shapiro adapted the NHTSA's levels of driving automation into six levels of AI coding. Separately, AI researchers at UC Berkeley have proposed a simpler three-level taxonomy organized around which stages of the lifecycle the AI takes over. Shapiro's levels are written for the individual developer, and Berkeley's as a research roadmap, where the upper levels are defined by capabilities that don't yet exist. What's missing is a taxonomy for a CISO today: the level of autonomous coding in a business.
We build on Shapiro's idea with a taxonomy for organizations deploying AI coding to understand their level of autonomy, associated risk vectors, and how to mitigate them. Each level represents a meaningful increase in the work done by AI, and a rethinking of the software development lifecycle itself.
The Levels of Autonomy in Software Development
- L0: No AI. Some companies haven't employed any AI coding, and some have outright banned it, usually over IP, compliance, or data-residency concerns.
- L1: AI Autocomplete. This is where most companies were when GitHub Copilot first launched, where a human accepts or rejects code generated by AI, line by line. As tools like Cursor grew a chat pane and then an agent mode, most organizations moved to L2.
- L2: AI Chat Assistance. A chat assistant writes code with a human reviewing and guiding every change before it gets written. This is where many developer teams are today, where a human signs off on every AI-generated diff.
- L3: Delegated AI Agents. The agent works unsupervised for the length of the session — reading the codebase, planning, writing, testing — and comes back with a finished PR for the human to review. The agent may run in the cloud rather than on the developer's machine, and the human's job becomes reviewing the agent's output.
- L4: Self-Reviewing AI Agents. Here, agents review agents. An autonomous coding agent still produces the PR end-to-end, but now, another coding agent acts as the PR reviewer. At this level, humans intervene only at defined gates like setting product goals, or reviewing and deploying especially risky PRs.
- L5: AI Software Factory. At L5, agents propose, design, verify, and deploy new features end to end. The goal for humans becomes watching for escalations, and defining definitions-of-done and broad product direction.
Categorizing risks in terms of levels of autonomy
Each level of autonomy carries its own risks. Companies at L0 and L1 face a competitive risk: they have no new AI threat surface, but they're giving up massive productivity gains to competitors further up the autonomy ladder. For companies at L2 and above, the risks shift from competitive risks to technical ones.
At L2, engineers are expected to review every AI-generated diff for security concerns. But as AI generates more code per engineer, the same engineer must review more diffs with the same level of scrutiny, and the risk of skimming past a significant issue grows. L3 carries the same risk, but now at the PR level: the volume of generated code has exploded while a human still bears the burden of thorough review, and more issues slip through to main. PR review bots can catch issues at this point, but in doing so create additional time and attention burden for human developers to go through.
At L4 and L5, the main risk is miscalibration of agent-automated gates. At L4, an overly restrictive review agent blocks even low-risk changes and, worse, an overly permissive one ships high-risk code without human review. At L5, miscalibration compounds throughout the entire software factory: review, planning, and deployment loops are each calibrated by agents, so an error in one propagates to the next, and so on down the chain. With observability also run by agents, large-scale security issues can go completely unnoticed.
Corridor's Path to L4 and beyond
In early 2026, during the early days of Corridor, we were at L2 and mainly using Claude Code or Cursor locally, reviewing each PR that AI produced. As cloud agents like Cursor Cloud and Devin started getting much better at working on long-running end-to-end tasks, we increased cloud agent adoption and reached L3 by July 2026. At this stage, we noticed that the number of PRs opened by AI absolutely exploded. This is when we really felt the crushing weight of PR review workloads. While we were able to reduce the workload somewhat with PR review bots, we knew that we had to do something to scale along with the number of PRs opened. This is when we seriously started thinking about how to move to an L4+ company.
To help get us there, we built an autoapprover to get humans off the critical path of code review. Doing this helped us roughly double the amount of PRs that made it into main (from ~115/week to over 220/week), and substantially decrease the amount of time from PR creation to merge (from ~21 hours to under 3 hours per PR). We also use our MCP tool to steer our coding agents to produce more secure code by default, our pre-commit security scans to auto-review diffs before a PR is even created, and our code merge policy to auto-merge low-risk changes. This puts us at what we call L4.5: most changes now merge without a human approver, but humans still originate the work.
We realize that the jump to L5 requires a lot of thought, as outlined in Dex Horthy's Why Software Factories Fail series and in our risk categorization above. Part of this work is figuring out how to "keep the lights on" in our software factory as much as possible. We're doing this by creating highly observable review, planning, and deployment loops, guiding agents to produce secure-by-design code with the tooling Corridor provides, evaluating and re-calibrating our auto-approver, re-auditing our merge policy, and shifting left as much as possible.
We plan to document our journey to L5, and we're developing Corridor to help you get there too. In the meantime, we encourage you to determine what level of software autonomy your team is at, what steps you need to take to move up the ladder, and what risks come along with it.