What Are the 8 Levels of AI Coding, and How Do They Map From Basic ChatGPT Prompting to Full Agent Orchestration?

Most debates about AI coding skip a step, arguing over which tool is best before asking what you are actually doing with it. A more useful lens, popularized by the engineer Steve Yegge, sorts AI coding into eight levels that run from pasting prompts into a chat box to running a fleet of agents you coordinate yourself.

Where the ladder comes from

The framework is less a rulebook than a map of increasing autonomy and coordination. Each rung hands more of the loop to the machine and asks more verification and orchestration skill from you in return. Yegge and others have described the climb in detail. The honest version includes a fact the marketing leaves out, which is that higher is not automatically better. Treating it as a maturity map, rather than a race to the top, is the only way to read it well.

Levels one to three: prompting and assistance

Level one is the copy-paste era. You describe a problem to a general chat assistant like ChatGPT and shuttle code back and forth by hand. Level two adds inline autocomplete, where the model finishes the line or the block as you type. Level three brings chat into the editor itself, so the assistant can see the open file and apply an edit without a trip through the browser. Each step shortens the distance between asking a question and getting working code. None of these levels writes much on its own, and all of them keep you firmly in the driver seat.

These three levels cover where most developers actually spend their day. They are low-risk, high-frequency, and easy to adopt without changing how your team works. For a small, tidy codebase they already capture a large share of the value AI has to offer. That is worth remembering before you chase anything fancier, because the extra gain from climbing higher shrinks fast on simple projects.

Levels four and five: the agent enters the editor

Level four is the single in-editor agent that edits across several files toward a goal rather than fixing one line. Level five gives that agent tools: it can run your test suite, execute commands, and reach external systems, which is where it starts to behave like a real coding agent instead of a smarter autocomplete. Ask it to add an endpoint and it can write the route, the handler, and a test, then run that test and fix what failed. The leap from level three to level five is the one most teams are living through right now. It is also the point where a single bad change can reach far past one file.

This is where the surface you work on, editor or terminal, begins to shape what the agent can reach and how you review it. The diff you approve grows from a few lines into a whole feature. The temptation to rubber-stamp it grows at exactly the same rate.

Levels six and seven: delegation and orchestration

Level six is delegation by specification. You write a clear spec or plan and hand the whole task to an agent that works largely on its own, then you review what comes back rather than steering each step. Level seven adds a second tier, where an orchestrator model dispatches work to several worker models in a hub-and-spoke pattern, each handling a slice of the job in its own isolated context. This is the point where single-agent coding becomes multi-agent coordination, and the productivity ceiling rises sharply. So does the cost of verifying parallel output you never watched being produced. Two agents finishing at once is only a win if you can trust both results without redoing the work.

Getting real value at these levels depends entirely on the discipline of tests and review that turns raw speed into shipped software. Without that scaffolding, more agents simply means more unverified code arriving faster. The skill stops being how to write code and becomes how to specify and check it at scale.

Level eight: building the orchestra

Level eight is where you stop using orchestration built by someone else and build your own, coordinating many agents through a system you designed for your codebase and workflow. It sits at the far end of these maturity models as the active frontier. Very few teams have any real reason to be there, and fewer still can staff the verification it demands. Reaching it is an achievement, not a target every team should aim at.

How high should you actually climb

A ladder tempts you to treat the top rung as the goal, which is the wrong instinct. Each level up adds verification burden, token spend, and coordination overhead. Teams on small, well-factored codebases often capture most of the return by level three and pay a tax if they push further. The right level is the one where the value you gain outruns the overhead you take on, not the highest one you can technically reach. Making that call honestly is the same skill as cutting through the hype to measure what actually helps.

Climbing has a real cost, and the bill arrives as review time and token spend. Spend it only where the work clearly justifies the return. On most days, for most teams, that ceiling is lower than the hype suggests.

Read your own rung first

Before you adopt the next tier, figure out which level your work actually needs. A well-run team at level three can outship a chaotic one flailing at level seven, because the higher rungs punish weak testing and loose process. Match the rung to the job in front of you, and treat the climb as optional rather than inevitable. The best engineers pick a rung on purpose and stay there until the work itself demands more.

Common questions