Scales measuring AI autonomy levels have been proliferating over the past two years, and they all look alike. One of the first, Dan Shapiro’s, ranges from handwritten code to the “software factory,” where no human touches the code at all. The first time I read it, I placed myself at level 3 within thirty seconds—the one Dan sums up as “your life is diffs.” The agent produces the feature, the tests, and the pull request, and I spend my days reviewing the result. What took me longer to wrap my head around was the next step. At Level 4, you write the specification, let the agent do the work, and simply verify that the tests pass. You no longer read the code you’re delivering. Honestly, I thought that was a little crazy. I spend my days with agents, and I still see the absurd things they’re capable of, even when they’re loaded with instructions and safeguards.
To be clear from the start, I use these tools every day, and I won’t go back. The question that’s on my mind isn’t whether we delegate to the machine. It’s to what extent, and on what?
A scale like that isn’t interpreted the same way by everyone who reads it. A manager looks to it for a roadmap: where the organization stands, and where it could go. Pier-Luc Rodrigue, vice president and CEO of Nexapp, mapped one out inTwo Years of AI at Nexapp, inspired by Dan’s. In it, Pier-Luc talks about levels. Since then, we’ve started calling them “agent modes.” On the other hand, the developer who experiences this scale daily is looking for another answer: How do I approach the task I’m starting this morning? That’s the question I’ll start with here.
Everywhere you look, stopping to read the code is presented as the real leap you need to take. The message this sends—whether we like it or not—is that if I take the time to reread everything, I’m falling behind on something. That unease is what sparked this article. Is reviewing everything I ship a sign I'm falling behind... or a choice?
On these scales, one rung stands out from the rest. Up to mode 3, I review the code the AI produced before I ship it. At mode 4, I validate. I no longer read the code; I just check that the tests pass and that the feature does what we wanted. That's where things get radical. You go from reading everything to reading nothing at all.
Let me describe a normal task in my day. I work on large-scale enterprise solutions: systems that always have to run, have to be fixable fast, and will keep me busy for years.
Before I write any code, I generate an architecture plan with AI. I review it, challenge it, then validate it with my peers. A set of skills encodes our standards for architecture, code, test writing, and more. I even have tools where agents challenge the first agent’s proposal, and that agent has to show its solution will do the right thing, for instance by already planning automated tests. During implementation, the agent loads additional skills and gets challenged again by other agents. Across the flow, you’ll find machine-readable plans, agents supervising agents, and proof through tests. On Pier-Luc’s scale, that machinery belongs to modes 3 and 4.
And yet, before anything goes to production, I keep the same habit: I review what was done. Not evenly. I move fast through the trivial parts. For architecture, I check that it conforms to the plan we already approved together. And I put a lot of focus on the generated tests. Are they clear? Do they test the right thing, the right way? Tests have become even more important in the age of AI. Nexapp’s article on our two years with AI has a name for this way of working. The top of the scale is often compared to a “dark factory,” a plant so automated you can turn off the lights because nobody is in the room anymore. The article adds a mode 4.5, the “lit factory”: all the machinery is running, but because a human stays in the loop, the lights never go off. It’s a zone I spend time in now and then.
That daily routine showed me what I was looking for. The scales merge two dials into one. The production dial measures how much the machine produces without me. The verification dial measures how much I verify what it produces. The scales turn both up together, as if one implied the other. But in practice, nothing forces you to couple them. You can push production automation very high without ever signing off on handing over verification. So reviewing isn’t a sign of missing tooling, because I use the machinery of the higher modes every day. I’ve simply separated the two dials.
DORA talks about a “verification tax”: the time saved writing code gets spent reviewing it. That image assumes a naive code review, where every line is read equally, then read again. That’s not what I do. More importantly, it only shows one side of the coin. Reading the code you ship isn’t just verification. It’s also a way for developers to share knowledge, the kind that will help us put out fires in production. Stop reading the code, and you also stop understanding the system. So is code review really a tax... or an investment?
Tip: Set the two dials separately. You can push the production dial all the way up without touching the verification dial.
If I’m not missing tooling, that leaves the trust hypothesis: the reflex of a cautious developer who can’t let go. To test that one, I have to go back in time.
I shipped my first mobile app about ten years ago. On Christmas morning, an event was supposed to trigger in the app to give users gifts. But at 2 a.m., just as I was heading to bed, I got a text from the client saying it wasn’t working. I went and fixed the problem before falling asleep. It’s the only time that ever happened, because that night I decided to be much more vigilant about what I ship.
That text is my answer to the trust question. Reading code before production isn’t distrust of the tool. It’s accountability, lived firsthand. If something breaks in the middle of the night, a developer is the one who gets up to fix it. Not the AI vendor. Nexapp’s two-years-of-AI article says it too: whatever the mode, accountability stays human.
In practical terms, what’s still holding me back? Three things.
The state of the tool. As I write this in 2026, AI hasn’t yet reached the point where I can trust it to succeed on the first try in large-scale enterprise software. I often interrupt it mid-generation because it’s heading in a direction I wouldn’t have chosen. I’ve even seen an AI “fix” a test by replacing the assertion with ` expect(true).toBe(true)`. That was in 2025, and the models have improved significantly since then. This observation becomes less true with each generation. Things are moving forward, and that’s a good thing. But we’re not there yet.
The nature of the work. Building a bridge is complicated. There are many unknowns, but once they’re resolved, the bridge stands. Developing software is complex. The unknowns are endless, starting with what users really want. That’s why we move forward by making assumptions, delivering continuously, observing, and adjusting. AI is no exception to this reality. It, too, makes assumptions. Non-deterministic, it chooses its context, tries a solution, and sometimes gets it wrong—just like us. The difference is that where a colleague says, “I think,” AI moves forward with complete confidence, as if doubt didn’t exist. In a world of hypotheses, a tool that never doubts needs someone to doubt on its behalf.
The location of information. Some of the answers aren’t found in the ticket or in the code. They’re found in conversations between people, in the business context, in what the Product Owner told the client last week. When information is missing, developers pause and go find it, by asking the Product Owner a question or seeking confirmation from users. AI, on the other hand, fills the gap with an assumption and keeps moving forward. Some might argue that a second AI can evaluate the work of the first. But it will make that evaluation based on the same missing information. No model, no matter how good it is, can validate information it doesn’t have. And the higher up the hierarchy you go, the more the AI operates on its own. There are fewer and fewer people left to notice the questions that were never asked. This observation remains true regardless of the models used.
These observations change the way we work with an agent daily. Letting the agent work alone in a corner and checking everything at the end is asynchronous review, with the same flaw we’re already familiar with among humans. Comments arrive at the moment when they’re most costly to implement. If the agent heads in the wrong direction and we don’t notice it until two hours later, all the subsequent work is compromised, from the code to the tests, including the agents that challenge each other and the tokens consumed. Interrupting the process midway is like pair programming with a machine. The earlier a comment arrives, the less it costs, whether from an agent or a human. I explored this idea from a human perspective in Breaking Down Silos. The idea still holds true when the teammate is a machine.
Reviewing is therefore neither a lack of tools nor a lack of trust. I still needed to understand what it really was, and the answer came as I looked at the rest of my week.
I have to be honest. While I was defending reviewing in my head, my weeks were spent contradicting that very idea on everything that didn’t touch the core of the product.
To evaluate one of our product’s agents, industry experts had filled out an Excel file with 300 real-world cases, and we needed a script to convert it into the format the agent uses. The AI generated it from start to finish, then refined it with each new version of the file, with little oversight on my part. The day the evaluation ends, that script dies. No one will stay up all night for it.
And it’s not just me. Nexapp built an internal product to track its projects, and with every new feature, the same conversation comes up: Does this touch the core of the product or its data, or is it a support task? If it’s critical, a developer takes it on, assisted by AI. If they’re superficial improvements, we’re perfectly fine with a manager who doesn’t code adding them themselves using an agent and delivering them.
Look at what these stories have in common. The decision was never made by team or by product. It was made on a task-by-task basis. Whether it’s morning or afternoon, I use the same agents. What changes is what I do with the result. In the morning, I review the core domain code. In the afternoon, I approve the disposable script without reading a single line of it. Reviewing has never been something I felt strongly about at all costs. It was the setting for those tasks: the ones that will live for years, and that someone will get up in the night for.
That’s the answer to the question that opened this article. Reviewing everything I deliver was neither a hindrance nor a defining trait. It was a setting. And that’s the whole trap of scales read like a ranking system, where moving up is equated with progress. That’s why I prefer the word “mode” to “level.” You don’t climb toward a mode: you choose it. Maturity isn’t about being at Mode 5. It’s about knowing which mode to choose for each task. A team that no longer reads anything without asking itself this question can be just as immature as a team that reviews everything out of reflex.
If the mode is chosen task by task, you need to be able to decide quickly. Here are the four questions we ask ourselves, and that I’d suggest to any team.
Recommendation: Make these four questions a reflex during backlog refinement, just like estimation. A task’s mode is a team decision, open to revision, not a policy set in stone.
I’ve never been to mode 5. Not on principle, and not out of caution. Nothing in my current context has justified it so far. But I keep watching for it. Every time a throwaway task comes along, one that can’t break much and that nobody will get up in the night for, I just validate, and happily. Those opportunities come up more and more often as the tools improve.
That’s what I’d tell anyone today who, like me reading my first scale, wonders whether the way they work means they’re falling behind. The map is useful. Pier-Luc’s scale shows which modes exist; it gives an organization a heading and a shared vocabulary. But the map will never tell you which mode to pick for Monday morning’s task. For that, you need a compass: the four questions, asked task by task. And that compass is in your team’s hands.
So stop asking your team what level it’s at. Ask it how it chooses the mode for each task. If it can answer, you’re in good hands, whatever mode it spends its days in. It already knows who needs to read what before production.
The question of trusting code nobody has read is already spilling beyond software engineering. Stanford Law School is publicly asking who can trust software built and tested by agents. The conversation is just getting started.
Meanwhile, one thing doesn’t change: whatever level the scale says you’re at, the 2 a.m. text still lands on a human’s phone.