← Back to Blog 15 min read

The 6 Levels of AI-Assisted Development

The Uncomfortable Truth

AI coding tools are supposed to make you faster. So why did you get slower the first time you tried using one seriously?

You asked it to build a feature. It produced something that looked right. You shipped it. Then you spent two hours debugging an edge case the AI didn't account for. Net result: slower than if you'd written it yourself.

This isn't a bug. It's the learning curve. And almost nobody talks about it honestly.

Here's what I've observed working with engineers at every level: there is a progression to using AI for coding effectively. It's not "install the tool and go faster." It's a skill. Like any skill, it has stages. Each stage initially makes you slower as you learn it. And each stage, once you internalize it, makes you dramatically more effective than the one before.

This article lays out 6 levels of AI-assisted development, from Level 0 (you write everything) to Level 5 (you run parallel AI development streams simultaneously). Each level builds on the previous one. You can't skip ahead without paying the price later.

This is opinionated. This is one path, not the only path. But it's concrete. You can measure yourself against it. You can track your progression. And you can stop wondering whether you're "doing it right."

One prerequisite applies to every level: you must be able to break a large task into smaller subtasks. If someone hands you a feature and you can't decompose it into discrete, implementable pieces, none of these levels will work for you. Task decomposition is the foundation. Everything else builds on top of it.

Let's start with why this progression is hard in the first place.

Three Metaphors That Explain Why It's Hard

Before we get to the levels, I want to give you three mental models. These explain the specific skills you need to develop and why the transition between levels feels so uncomfortable.

Metaphor 1: From IC to Senior IC

Think about what happens when an engineer transitions from individual contributor to senior IC or manager. As a junior, you write everything yourself. You know every line because you typed every line. Your velocity is your typing speed plus your thinking speed.

Then one day, you're responsible for a team. Now your job is to break tasks down clearly enough that other people can execute them. You review their work. You determine whether their output actually fulfills the requirement, not just whether it compiles. You catch the gap between "what I asked for" and "what I actually needed."

AI puts you in the senior role whether you're ready or not.

The most junior engineer on the team, someone who just started coding six months ago, now needs to: break down tasks clearly, monitor execution, evaluate correctness, and determine if the output fulfills the actual requirement. These are senior engineering skills. And AI demands them from day one.

This is why you're slower at first. You're learning a new job, not just a new tool. That's okay. Stay the course. The AI is already good enough to write your code given a quality plan. The bottleneck is your ability to create that plan and evaluate the result.

First skill to develop: Breaking large tasks into smaller tasks that can be understood and executed by a more junior developer (or an AI).

Metaphor 2: From Synchronous to Asynchronous Thinking

Remember learning async programming for the first time? Sequential code is easy to reason about. You read it top to bottom. Each line executes after the previous one completes. Simple.

Then someone introduces concurrent execution. Suddenly, independent operations resolve at different times. Race conditions appear. Even basic addition becomes complicated when two threads read, modify, and write the same variable. Your brain hurts for weeks.

But if you figure it out? You manage 100 concurrent operations with the same effort as 1. That's the unlock.

Higher-level AI coding follows the same pattern. At the lower levels, you do one thing at a time. You write a prompt, wait for output, review it, iterate. Sequential. Easy to follow.

At the higher levels, you manage multiple AI coding sessions simultaneously. Each one is working on a different subtask. Each one produces output you need to review. The complexity isn't in the code anymore. It's in the coordination. It's in your ability to context-switch between streams, hold the overall architecture in your head, and merge independent work products into a coherent whole.

Second skill to develop: Holding multiple work streams in your head and parallelizing development.

Metaphor 3: The Art of Code Review

Senior engineers review more code than they write. This is not an accident. The highest-leverage activity in software development is ensuring that code does what it's supposed to do before it ships.

Reviewing code you didn't write is a distinct skill from writing code. It requires: understanding unfamiliar patterns and conventions line by line, recognizing good practices versus shortcuts, identifying subtle logic issues that tests might miss, and determining whether the code fulfills the TASK. Not just "does it run?" but "does it solve the problem we set out to solve?"

Critical insight: AI will always suggest code changes.

Here's why that matters: Ask it to review a file, and it will find something to change. That's how it's built. But sometimes the correct answer is to write no code at all. Sometimes the existing implementation is fine. Sometimes the task itself needs to be re-scoped. The ability to say "no, this is correct as-is" or "no, we shouldn't build this" is a skill AI won't develop for you.

For junior engineers especially: reviewing AI-generated code IS how you learn the codebase. Do not trust blindly. Read every line. Understand every line. Ask yourself why each decision was made. Yes, this is slower at first. That's the tax. Pay it upfront. It gets faster. And the understanding you build will serve you for the rest of your career.

Third skill to develop: Reviewing code for both correctness AND task fulfillment.

The 6 Levels

Each level describes: what it is, the typical workflow, the pros, the cons, how to know you're at this level, and signs you're ready to move up.

Level 0: Manual Coder

What it is: You write all your code by hand. AI is only used to explain concepts, clarify documentation, or help you understand error messages. It never touches your codebase directly.

The flow:

Your subtask
↓
You code it
↓
You test it
↓
✓ Done

Pros:

Cons:

Signs you're at this level:

Move up when: You're comfortable with your codebase and your language. You find yourself writing the same patterns repeatedly and want to speed up the routine parts. You trust yourself to review someone else's code.

Level 1: Copilot Mode

What it is: You use AI as an advanced documentation tool and snippet generator. You ask it to draft small, self-contained pieces of code. Functions, boilerplate, utility helpers. You copy the output in, review it, adjust it, and move on. The AI only has local context, whatever you paste into the prompt.

The flow:

Your subtask
↓
You use AI to help code individual pieces
↓
You review and integrate
↓
✓ Done

Pros:

Cons:

Signs you're at this level:

Move up when: You notice that your conversations with AI are getting longer. You're pasting in more and more context. You're explaining your data models, your conventions, your file structure. You're spending more time setting up the conversation than you're saving on the output. That friction is telling you something: you need a workflow where the AI understands more of the picture.

Level 2: Conversation Mode

What it is: You have an extended conversation with the AI until it understands your task, your codebase context, and your constraints. Then you ask it to implement the full subtask. You review the output, iterate through conversation, and refine until it's right.

The flow:

Your subtask
↓
Conversation with AI (context building)
↓
AI implements
↓
You review
↺ Iterate if needed
↓
✓ Done

Pros:

Cons:

Signs you're at this level:

Move up when: You find yourself repeating context across conversations. You wish you could capture the "plan" before the AI starts writing code. You want to review the approach, not just the output. You've been burned by the AI going in a direction you didn't want, and you had to start over.

Level 3: Plan Mode

What it is: You use AI to draft an implementation plan before any code is written. The plan describes what files to change, what the approach is, what the key decisions are. You review the plan. Edit it if needed. Save it. Then the AI executes from the plan. You review the resulting code against the plan.

The flow:

Your subtask
↓
AI drafts implementation plan
↓
You review and edit plan
↓
AI implements from plan
↓
You review code against plan
↺ Revise plan and retry if needed
↓
✓ Done

Pros:

Cons:

Signs you're at this level:

Move up when: You want automated verification that the code works, not just that it "looks correct." You've been in situations where the code looked right in review but had subtle bugs. You want a safety net beyond your own eyes.

Level 4: Test-Driven AI Development

What it is: Before implementation, you have AI draft tests that define correct behavior. Then you draft the implementation plan. Review the plan. Execute. Run the tests. Fix what fails. Then do a final code review. You now have three layers of verification: the plan, the tests, and your code review.

The flow:

Your subtask
↓
AI writes tests defining correct behavior
↓
AI drafts implementation plan
↓
You review plan
↓
AI implements
↓
Run tests
↺ Fix failures, revise plan if needed
↓
You review code
↓
✓ Done

Pros:

Cons:

Signs you're at this level:

Move up when: You're comfortable running Level 4 on individual subtasks and it feels routine. You look at your task list and see 3-4 independent subtasks that don't depend on each other. You think: "Why am I doing these one at a time?"

Level 5: Mastery (Parallel AI Development)

What it is: You execute multiple non-dependent subtasks simultaneously, each running the Level 4 workflow. You manage multiple AI coding sessions at once. Each session has its own plan, its own tests, its own implementation. Optionally, you use a separate code review pass (automated or manual) to review output across all streams, identify integration issues, and draft fix plans for your approval.

The flow:

Break feature into independent subtasks
↓
Launch Level 4 on each subtask in parallel
↓
Stream A: tests → plan → implement → test → review
Stream B: tests → plan → implement → test → review
Stream C: tests → plan → implement → test → review
↓
Code review across all streams
↓
Integrate
↓
✓ Done

Pros:

Cons:

Signs you're at this level:

A note on Level 5: This is not the default. Most engineers don't need to operate here most of the time. It's the ceiling, not the floor. The real value of this framework is helping you progress from wherever you are now to the next level, at whatever pace makes sense for your work.

A Word of Warning

Moving up levels too fast without proper verification isn't just risky. It can be catastrophic.

Here's the danger most people don't talk about: when you skip verification steps, the problems don't always show up immediately. AI-generated code can look correct, pass a quick glance, and even work in testing. But underneath, it may contain subtle issues. Hardcoded assumptions that break when data changes. Race conditions that only surface under load. Security gaps that no one notices until they're exploited. Logic that works for the common case but silently corrupts data in edge cases.

These aren't the kind of bugs that crash your app and get caught on day one. These are the kind that go undetected for weeks or months. They accumulate. They create maintenance nightmares. They cause the kind of production incidents where you're reading code at 2 AM thinking "who wrote this and why does it work this way?" and the answer is "an AI did, and nobody reviewed it properly."

The worst part: the faster you move, the harder these issues are to trace back to their source. By the time you discover the bug, 50 other changes have been built on top of it.

This is why each level emphasizes verification. The verification IS the skill. The AI writing code is the easy part. Knowing whether the code is correct, maintainable, and actually solves the problem is the hard part. That's your job. Don't outsource it.

Never move to the next level until your verification at the current level is solid. Speed without verification is just fast failure.

How to Measure Yourself

Self-assessment is the only assessment that matters here. Nobody is grading you. The goal is honest awareness of where you are and deliberate practice toward where you want to be.

Track Weekly

Ask yourself these questions at the end of each week:

Signs You're Ready to Level Up

Signs You Leveled Up Too Fast

If any of these resonate, drop back a level. There's no shame in it. The goal is sustainable effectiveness, not speed at the cost of quality.

The Honest Timeline

Most engineers spend months at Levels 1 through 3. This is normal. These levels are where you build the review skills, the decomposition skills, and the judgment that make higher levels possible.

Level 4 takes deliberate practice. Writing tests first is a discipline, not a natural instinct. It changes how you think about requirements.

Level 5 is where senior engineers with strong fundamentals operate. If you're early in your career, Level 5 might be a year or more away. That's fine. A strong Level 3 engineer is more effective than a sloppy Level 5 engineer every single time.

No shame in being at any level. The goal is consistent, measured progression.

The Bigger Picture

Here's something I've seen repeatedly: engineers who focus exclusively on AI coding speed without understanding the systems they're building end up going very fast in the wrong direction.

Getting to Level 5 without understanding system design is like managing 10 junior engineers who are all building the wrong thing quickly. Output goes up. Value doesn't.

The engineers who thrive aren't the fastest coders. They're the ones who understand how systems fit together. They know why you'd choose a queue over direct API calls. They understand why a cache improves read performance but introduces consistency challenges. They think in building blocks, patterns, and tradeoffs.

AI coding proficiency is a skill multiplier, not a replacement for understanding. It amplifies whatever you already know. If you understand system design deeply, AI makes you extraordinary. If you don't, AI makes you extraordinarily fast at creating technical debt.

System design understanding + AI coding proficiency = the "AI builder" role.
That's where the industry is heading. Engineers who can architect systems AND leverage AI to build them at speed.

If you want to build that system design foundation, the building blocks framework gives you a concrete, repeatable way to think about any system. Seven building blocks. Three external entities. Every system you've ever used, decomposed into patterns you can learn and apply.

The levels in this article give you the AI coding side. The building blocks give you the system design side. Together, they make you the engineer every team wants.