Four levels of agentic software development in the enterprise
Steps on a path to a world of fully autonomous agents
I have now been working “agent first” for several months. Not that I didn’t use LLMs before but I am now forcing myself to de-facto not leave an IDE tuned for orchestrating agents in 95% of cases. Even the most trivial tasks I’ll have a model do, just to make sure I’m gathering insights on how to automate this the next time I have to do it and really become “agent literate”. And the longer I do this the more clear it becomes to me that the majority of those tasks, if done again and again and evaluated against clear conditions until the output meets the success criteria, can be done by an agent.
Yet most people I interact with work in brownfield enterprise setups. In their world LLMs are used to auto-complete, they are often sceptical and very far away from any real use or concrete productivity gains. There’s even the question coming up: will this ever be reality in large scale setups? Having the benefit of talking to many of the front runners to I can confidently say: it is the reality now, you’re just not there yet.
Over the next months I want to spend lots of time actually providing a conceptual way of thinking about the design of what I call “Agentic Development Platforms” and the required “Agentic Infrastructure” that powers these platforms.
But before I go that deep I feel like we should align on the various levels of agentic software development that we are seeing at the moment. I recently wrote a longer whitepaper on Weave Intelligence that you can find here.
The levels are defined by one thing: how much of the work humans still need to initiate and approve. As you move through them, the human role shifts from execution engine to reviewer to orchestrator to system designer.
At Level 1, the human is still the execution engine. Agents assist but humans approve everything. At Level 2, agents begin executing work in parallel and humans verify outcomes rather than inspect every line. At Level 3, the platform runs continuously in the background and human review becomes exception-based. At Level 4, the system initiates its own work in response to environmental signals, within guardrails that humans define.
Each level demands more from the underlying platform but as we can see, none of them are achievable by choosing a better model, they require deliberate platform architecture decisions. Let’s walk through them one by one.
Level 1: Human in the loop
Most enterprise software teams are here today. At that stage, Agents suggest and humans approve everything. The developer truly remains the execution engine.
In practice this looks like AI autocomplete, prompt-driven code generation, and using agents to understand unfamiliar parts of the system. The developer takes the output, modifies it, decides what goes into the codebase. The platform does not need to change to support this.
The gains at this level are of course real but they are limited. Output is still restricted by human review bandwidth and that means one person, one keyboard, one PR at a time.
Level 2: Humans on the loop
This is where things get genuinely different, and where most organizations underestimate the platform work required.
At Level 2, agents stop being a private tool on a workstation and become participants in the value stream. The human dispatches agents to do chunks of work on their behalf. This concretely means: Multiple agents work in parallel in the background. At all times, multiple PRs advance simultaneously, the human is no longer the execution engine but the human still decides what to advance.
This is the first real parallelization. Not more developers, but more work items moving forward at the same time because agents are doing the execution.
The platform has to change meaningfully to support this. A new golden path appears: we call it “dispatch work to agents”. The platform must now manage agent identity, provision sandboxed environments per agent session, enforce resource limits, and package context in a way that agents can actually act on. Without this infrastructure, agents collide, consume unbounded compute, and produce outputs the system cannot safely evaluate.
The most important structural change at Level 2 is what happens to validation. At Level 1, validation is a gate: a human walks a PR through CI, reviews the diff, approves it. At Level 2, that model breaks immediately. Agents generate changes at a volume and cadence that human review cannot match. And so in order to support that, validation has to become a loop. The loop is really such an important concept if it comes to the design of agentic platforms. It really is, if architected carefully and executed against secure guardrails, the thing that allows the model to iteratively come to the correct outcome. Burns through some tokens but gets the job done.
The agent generates output at volume. The platform runs automated checks: tests, security scans, policy evaluation. If the output fails, the failure is routed back to the agent, which modifies and retries. The human reviews aggregate results, not individual diffs. Instead of reading code line by line, the human is verifying behavior: does this work the way it should?
This shift is in reality harder than it sounds. It requires comprehensive automated testing, security scanning integrated into the pipeline, policy enforcement as deterministic gates rather than manual audits. If you think about it you have to balance the slight randomness of probabilistic systems with somewhat dumb predictability of deterministic ones. Getting this right is what makes Level 2 sustainable instead of chaotic. Organizations that skip this work and just start dispatching agents at scale hit a wall fast: CI pipelines saturate, review queues explode, teams lose trust in the outputs.
The jump from Level 1 to Level 2 is the hardest transition in the model, and the one with the biggest payoff.
Level 3: Humans as orchestrators
At Level 3 the platform starts to run continuously in the background. Agents no longer wait for a human to send them work. The system itself begins to generate work based on what it observes.
A failing dependency check triggers an agent to generate a fix. A security advisory lands and agents begin assessing exposure across the codebase and generating patches. A recurring operational anomaly gets routed automatically into an agent workflow. The human defines the rules and the platform goes on to execute this.
Human review becomes exception-based. Instead of approving individual changes, humans design the policies that determine when the system may advance work on its own. Low-risk changes, dependency updates, small performance improvements, well-understood operational fixes, can be promoted automatically once validation evidence is sufficient. Humans review the exceptions and the rules, not every change.
There are already a surprising number of organizations at Level 3, or approaching it, particularly for their frontend estates. And this is not a future state. It is already a reality for teams that have done the platform work.
The constraint at this level shifts from review bandwidth to architectural maturity and cost management. Token economics becomes a real concern. An organization running agents continuously in the background on thousands of changes needs to govern what that costs, not just whether it is safe.
Level 4: Fully autonomous
Level 4 is where the production system becomes partially self-adjusting. Agents monitor environmental signals, customer behavior, operational telemetry, security findings, cost anomalies, and initiate new paths autonomously within predefined guardrails. They open tickets, propose changes, remediate issues, and adapt configurations without waiting for a human to ask.
Let’s be clear this isn’t happening too much at the moment. I have done some experiments with agents reacting to traces in customer calls and fixing non critical things autonomously but it’s early days. Yet again I don’t see a technical reason why we wouldn’t get there. In hindsight it feels obvious that you can have automated trading systems moving markets at high speed. At the time that idea felt utterly absurd, we believe the same applies here. Given the deterministic nature of software this is a question of inference, balance of power with guardrails and a high frequency of recurring attempts.
What makes Level 4 structurally significant is not the autonomy itself. It is what the autonomy enables: Continuous large-scale refactoring that would never get prioritized when humans have to execute every step. Or proactive security patching at the speed of CVE publication rather than quarterly cycles. Demand-responsive infrastructure adaptation without a human interpreting a dashboard first and definitely self-improving validation loops that update their own rules based on failure patterns.
At Level 4, platform engineers stop thinking primarily about software development as a human workflow. They think of it as an autonomous production process that continuously adapts software to the environment inside a set of deterministic guardrails they design and own. To stay in our high frequency trading analogy: we’re going from being traders to being system builders.
So now what?
Well first it’s just important to realize that your differentiator is not the model. I recently had a CIO of a Fortune 500 telling me they are making great progress, they had just procured Microsoft Co-Pilot. And you can tell that this is clearly missing the point. If your competitive advantage is the speed at which you are procuring a tool accessible to all you are in big, big trouble. The actual differentiator is as always the platform. Hard to overstate how relevant platform engineering is these days…
And with that, all the best to you from spring time Brandenburg and I’ll soon be back with some very interesting reference architectures for Agentic Development Platforms - stay tuned!
Kaspar