What "Level 5" Actually Means
Dan Shapiro's five-level model for agentic coding gives a useful map for the journey.
Level 0: AI as a better search engine. You write the code yourself, AI maybe completes a function. Every line gets reviewed.
Level 1: AI for boilerplate. You prompt for something specific and review it immediately, line by line.
Level 2: AI as pair programmer. The AI handles defined tasks on its own. You still review thoroughly, but not every single character.
Level 3: AI as a team member. The AI generates most of the code. You review pull requests. You are no longer the developer, you are the tech lead with an AI contributor.
Level 4: An engineering team made of agents. The AI runs autonomously for hours. The system verifies itself. Enough trust infrastructure exists that autonomous operation is realistic.
Level 5: Goal manager. You describe what the system should do, in plain language, user stories, customer requirements. You don't see the code. What matters: does the output match the spec? Can you trust it enough to ship it?
The jump from Level 3 to Level 5 is not a tool upgrade. It is a paradigm shift.
What We Learned at ex-nihilo
Sebastian and Christian both started at Level 0. Both went through every level personally, not by switching tools, but by developing a different relationship to the AI's output.
Today we build Zedl mostly at Level 4, with parts already at Level 5. Our goal is to run fully at Level 5. What we learned along the way:
The progress is personal, not just technical. Every developer had to build their own intuition for when to trust output, when to verify, and when to step in. That is not something you install. It is something you develop.
Spec quality is everything. At Level 5, your specification is your product management. A vague spec produces unpredictable output. We invest heavily in clear intent, acceptance criteria, and boundary definitions, not because a framework demands it, but because the quality of the input directly determines the quality of the output.
The boring parts matter most. The exciting conversation is about models, agents, and capabilities. The productive conversation is about test design, verification strategy, evidence packages, and escalation protocols. Real autonomy gets built in the unglamorous infrastructure of trust.
Tools change. Principles don't. We have used different models, IDEs, and configurations over the past months. What stayed constant: specify clearly, verify independently, build evidence, create feedback loops, know your trust boundaries.
The Trust System, in Detail
If you are now asking "how do I replicate this?" and looking for the right open-source framework, you are repeating the mistake from parts one and two of this series.
The right questions are different ones.
What evidence do I need to trust this output?
When a human developer submits a pull request, you don't trust them blindly. You trust them because of signals: the code compiles, tests pass, the PR description makes sense, the approach fits architectural decisions, a reviewer confirms it looks right. Trust comes from evidence, not from belief.
The same has to hold for AI-generated output, with even stronger evidence. The AI does not bring the implicit institutional context an experienced engineer carries.
What does my verification system actually look like?
Not "which test framework do I use," that is a tool question. The system question is: which categories of evidence need to exist before output moves forward? Tests? Spec compliance? Behavior validation? Performance? Security checks? And who or what checks each of them?
Where are my trust boundaries?
Not every task is Level-5 ready. Some tasks have ambiguous requirements, involve novel architectural decisions, are security-critical, or touch customer-facing experience that needs human judgment. A mature system knows where its limits are and escalates cleanly at that point.
How does my feedback loop work?
When output is wrong, and it will be, how does that information flow back into the system? Does the spec get refined? Does verification get tightened? Does the agent get better context next time? Continuous improvement is not a Toyota buzzword. It is the mechanism that turns a fragile experiment into a reliable production line.
What "We Don't Care About the Code Anymore" Actually Means
When we say the code no longer interests us at Level 5, that is deliberately provocative. But it needs to be precise.
It does not mean we don't care about quality. It means the primary object of control has shifted. We no longer control quality by reading every line of code. We control it by making sure the specification is precise, the verification is rigorous, the tests are comprehensive, and the evidence package is complete.
That is not less control. It is different control. The same way a manufacturing CEO doesn't control quality by inspecting every single product, but by designing a system that catches and prevents defects.
Who Benefits
- Teams working with autonomous agents who want to build a systematic foundation for trust
- Tech leads shaping the transition from "AI tool" to "AI production system"
- CTOs who need to understand the implications of Level 4/5 development for governance, quality, and accountability
- Anyone currently asking "which framework should I use?" and starting to suspect that's the wrong question
Frequently Asked Questions
What level does ex-nihilo operate at today? We build Zedl mostly at Level 4, with parts already at Level 5. Our goal is to run fully at Level 5. It's an ongoing process, not a state you simply switch on.
What does this transition cost? The biggest investment is time, for building verification systems, clear specification processes, and the personal development of both founders. There is no shortcut through a better tool.
Which tools do you actually use? Mostly Claude Code right now. But that's secondary. What's primary: the principles that stay constant even as the tools change. That is the difference between a tool strategy and a system strategy.
Is Level 5 reachable for every team? Yes, but not by jumping straight there. The model describes a progression. Teams that try to jump from Level 1 to Level 5 will fail, not for lack of tools, but for lack of trust infrastructure.
What happens when AI agents make mistakes at Level 5? That's exactly what the verification system exists for. Mistakes are not a failure of Level 5 as a concept. They're a signal that a trust boundary was set incorrectly, or that the verification system has a gap. That information feeds back into the specification and the verification rules.
Can we talk to ex-nihilo about building this? Yes. We share what we've learned because the most important conversations in the industry right now should be about systems and principles, not tools. Reach us at info@ex-nihilo.digital.