You do not need a better model. You need better habits.
The thing about agent assisted coding is that the agent codes faster than I can read, let alone review.
No exaggeration. Give it a task, it does its chain of thought thing, and a few minutes later… code that works. Tests pass. Features rendered. Happy path covered. By any reasonable standard, the job is done.
But is it?
At this point what we really have is working code. Just because it works, doesn’t mean it’s ready. Did the agent solve the problem I described? Undeniably. However, the problem is that it didn’t solve the problems I did not describe. Empty inputs I forgot to mention. Concurrent access I did not anticipate. Those annoying edge cases when a user does something slightly unexpected.
Sometimes I feel like I spend more time reviewing and correcting than the agent spent writing my instructions. And for every three or four bugs I fix, a new one appears.
It’s obvious. I am the bottleneck. The agent would happily spit out tens of lines of code per second, but I am the one who has to verify that fast code is also right code.
Sound familiar?
The Four Levels
I recently watched a video by Jason on the four levels of coding with AI. It put a name to what I was experiencing.
The framework is simple. At Level 1, you work with a single agent. You read everything it does. You learn the fundamentals. At Level 2, you start using multiple agents. Maybe you use git worktrees to keep their work separate. You are juggling sessions, switching context, and babysitting every step. At Level 3, you define specifications up front and have verification at the end. The agent executes autonomously. At Level 4, the agent works while you sleep.
Most of us are stuck at Level 1 or Level 2. That is not a failure. It is a stage. The pain I described above? That is the Level 2 ceiling. It is a known phenomenon. Jason has been there. I am there right now.
The jump from Level 2 to Level 3 requires three things. Not a better model. Not a faster machine. Three specific capabilities that change how you work with the agent.
Jason’s video is worth watching in full. He explains the progression better than I can, and he has the production experience to back it up. Go watch it. I will wait.
The Three Techniques
I have been thinking about what it would take to move from Level 2 to Level 3. Not in theory. In practice. These are the three areas I am focusing on.
1. Specification Quality
Every time an agent asks me a clarifying question, that is a gap in my specification. Every revision cycle is a specification failure. The time I invest in the prompt saves me time in the review.
The shift is simple. Spend more time defining the work before the agent starts. Not longer prompts. More complete prompts. What is the feature? Where should the change happen? What should the agent not touch? What does success look like? What should happen when things go wrong?
One technique I have found useful: ask the agent to explain the task back to me before it implements. If its explanation does not match my intent, I have caught a misunderstanding cheaply. Better to catch it in the specification than in the review.
2. Test-Driven Delegation
I cannot write TypeScript. But I can require the agent to write tests before it writes code.
This is not about me reading the tests. It is about giving the agent a self-verification mechanism. The agent defines the expected behaviour as tests, confirms the tests fail, implements the feature, then confirms the tests pass. When it reports completion, I have some confidence that the work is actually done.
The test suite also becomes a regression safety net. When I make changes later, the existing tests will tell me if something broke. That is especially valuable when multiple agents are touching the same codebase at different times.
Bonus: I can ask the agent to report test coverage after it finishes. If it reports 60 percent coverage, I know there are untested paths. I do not need to read the code to know there are gaps.
3. Edge Case Prompting
This one came from my own observation. The agent optimises for the happy path. It implements what I asked for. It does not spontaneously think about what could go wrong.
The fix is to force edge case thinking into the specification phase. Before the agent implements, I ask it: what could go wrong with this? What assumptions are you making? What happens if those assumptions are wrong?
I do not need to evaluate the agent’s list for completeness. The act of asking forces the agent to think about edge cases, which improves the implementation even if the list is not exhaustive.
When I run my adversarial reviews, I now give the reviewer a specific focus. Not “review this code.” Instead: “review this code with a focus on edge cases. Look for unhandled error states, missing null checks, race conditions, and assumptions about input format.” Focused reviews catch more than general reviews.
Why I Am Publishing This
I am not writing this as an expert. I am writing this as a practitioner who is actively working through the progression from Level 2 to Level 3.
I created a study guide for myself covering these three techniques. Detailed enough to work through, specific enough to apply to my own projects. And then I thought: if I am going to talk about these techniques, I should be using them. Publishing this is my way of holding myself accountable.
If you are at Level 2 and feeling the same pain, these three techniques are worth trying. If you are ahead of me and have thoughts on what I am missing, I would genuinely like to hear them.
The agent is not going to get slower. The question is whether we can get better at verifying that fast is also right.