The 7 Levels of AI-Assisted Coding: From Vibe Coding to CI-Enforced Specs

Last month, I asked an AI agent to add pagination to a users list. It returned a 900-line diff touching 14 files, refactoring my API layer and adding a caching system no one asked for. That's when I realized the problem wasn't the AI—it was how I was asking.

That experience pushed me to think about AI coding workflows as a spectrum. After six years building full-stack projects, I've settled on seven rough levels. They aren't official industry standards, and you don't have to climb them in order. Think of them as a maturity ladder: use Level 1 for a five-minute script, Level 4 for a feature that could break production, and anything in between as the situation demands.

Vibe coding is where almost everyone starts. You open a chat, type "build me a login page with JWT" and take whatever comes out. If it's wrong, you type "no, fix the redirect" and hope. There's no plan, no document, and the only record of your intent is a chat history you'll never find again.

For prototypes and throwaway scripts, this is fine. I still vibe-code small tools all the time—last week I made a script to rename 400 screenshot files this way, and it took four minutes. The trouble starts when you build real projects like this. The AI slowly drifts from your original intent, forgets rules you set twenty messages ago, and six months later no one on your team knows why a piece of code exists.

Imagine saying: "Build a dashboard that shows users and lets me delete them." The AI creates the page. Then you add search, then mobile friendliness, then "don't let admins delete themselves," then loading states. The application might work, but where are those decisions written down? Buried in a conversation. The code may be good, but the memory of why the code exists isn't.

One small change fixes half of that pain: make the AI show its plan before writing code. Tools like Claude Code and Cursor have this built in. You describe the task, and the AI lists what it will do—which files it will touch, what approach it will take. You read the plan, fix it, approve it, and only then does it write code.

That 900-line pagination disaster? In plan mode, I would have seen "Step 3: refactor API layer" and said no before a single line existed. The plan disappears after the session, though; nothing gets saved. It's a checkpoint, and a good one, but it leaves no trail.

In practice, instead of "Add pagination to the users list," I might say: "Before changing anything, inspect the users list, API endpoint, and existing pagination patterns. Give me a plan. Do not modify files yet." The AI might respond: add page and limit to the users API, return pagination metadata, update the users hook, add pagination controls to the existing table, and add tests for page boundaries. Now I can catch bad ideas before they become code. Maybe I don't want a new pagination library; maybe the project already has one. Maybe the API already supports pagination and the frontend just isn't using it. The plan gives me a chance to say that.

This is probably the cheapest AI workflow improvement you can make. You don't need a new framework—just stop letting the AI code immediately.

Here you flip the order. You (or the AI) write failing tests first, then the AI writes code until every test passes. This works well with AI because the agent now has a clear finish line. It can run the tests, see red, fix, and repeat without you babysitting every step.

One warning from experience: AI can cheat. I've watched an agent make a test pass by hardcoding the expected value. The test went green, but the feature was garbage. So you still read the code. Tests describe behavior, but they don't capture intent—why the feature exists or what it must never do.

For example, instead of "Build password reset," define what must happen: the endpoint must accept an email, generate a one-time token, send an email with a reset link, expire the token after 30 minutes, and reject reused tokens. Then turn those rules into tests. Now the AI has a target it can repeatedly check.

This is where things get serious, and where hiring managers start paying attention in 2026. The idea is simple: before any code, you write a spec—a short document describing what you're building, why, and how you'll know it works. That spec lives in git, right next to the code. When requirements change, you edit the spec and regenerate the affected code. The spec's git history becomes your change log.

A real example: a lunch-voting app for your team. The spec says members propose spots, vote once per day, voting closes at 11:30, and ties go to a runoff. No mention of React or Postgres—the spec is about what, never how. Tech decisions come later, in a separate plan step, and the work gets chopped into small tasks the AI executes one by one. Tools like GitHub Spec Kit and AWS Kiro are built around this flow.

A small file quietly does most of the work here: the constitution file. It holds your permanent rules—"all timestamps in UTC," "never touch the payments module without a flag"—and the AI reads it every session, so you stop repeating yourself.

I had to use this for a few weeks before I got it. Writing a spec feels slow the first time. Then a requirement changed, I edited three lines in the spec, regenerated one slice of the code, and the whole change took twenty minutes with a clean paper trail. That's when the overhead started looking cheap.

The difference between levels is subtle but significant. At Level 1, you tell the AI "build a lunch voting app." At Level 2, "here's the plan I want you to follow." At Level 3, "here are the tests that must pass." At Level 4, "here is the specification for what this product must do." A spec gives the AI something it can return to tomorrow. The chat can disappear, the model can change, the developer can change—but the spec remains in the repository. And because it's in git, you can see how the requirement itself changed over time, which is a much better record than reconstructing a decision from an old AI conversation.

Now it gets a little strange. Instead of one AI, you run several, each with a role. One agent acts as the PM and writes requirements. Another plays architect. A few developer agents implement. A QA agent tests. They pass documents to each other like an assembly line. Frameworks like BMAD-METHOD ship with twelve-plus role agents ready to go.

I'll be straight with you: I'm not fully convinced this is worth it for small teams yet. The coordination cost is real—each agent needs exactly the right slice of context, and if the architect's decisions never reach the developer agent, you get chaos with extra steps. On the projects I've tried it on, the setup ate most of the benefit. For large, multi-service systems? Different story, probably. I just haven't lived that one myself.

Here's where I think people get this level wrong: adding more agents doesn't automatically make the system smarter. Imagine a workflow where a Product Agent says "Users can have multiple active sessions." The Architect Agent doesn't receive that detail. The Developer Agent assumes one session. The QA Agent tests the developer's assumption. You now have four agents working very efficiently toward the wrong result. That's the multi-agent problem. Coordination becomes an engineering problem of its own. You need clear inputs, clear outputs, shared documents, and you need to decide which agent is allowed to make which decision. Sometimes one well-contextualized agent is better than five poorly coordinated ones.

Here's the shift that surprised me most. You stop sitting with the AI at all. You write a ticket, assign it to an agent, and walk away. The agent works alone in a sandboxed container, on its own branch. It codes, runs tests, fixes its own failures, and sends you a pull request. You might have four of these running while you're in a meeting. GitHub Copilot's coding agent and Claude Code's cloud sessions work this way today.

The catch is big, though: your bottleneck is no longer writing code; it's reviewing it. If your tickets are vague, you get garbage PRs because at this level, the ticket is the prompt. Sloppy ticket, sloppy code, and now it's sitting in your review queue at 5pm on a Friday.

Think about the difference: at Level 2, you might spend ten minutes with an AI agent while it works. At Level 6, you give it a ticket at 10 AM and see the pull request at 2 PM. That's a completely different relationship with AI—you're supervising the work package, not every keystroke. A good ticket for a background agent might be: "Add pagination to the users list. The API already supports page and limit. Update the users hook to pass these params. Add pagination controls to the existing table component. Add tests for page boundaries. Do not refactor the API layer or add caching." That's much better than "make login more secure," which gives the agent a huge playground. The first one gives it boundaries.

The top of the ladder, at least right now. Your specs stop being documents people read and become contracts machines enforce. Concretely: when a PR opens, your pipeline doesn't just run tests. An AI validator also checks the code against the spec. Does the API match the contract? Did someone break a rule the spec defines? If yes, the build fails—the same way it fails on a broken test.

This solves the oldest problem in software: documents that lie. Every team has a wiki page describing how the system works that stopped being true two years ago. At this level, the spec physically can't drift from the code, because drift breaks the build.

Very few teams are here. A JetBrains survey from January 2026 found 90% of developers use AI at work, but only 13% use it across their whole development cycle. The gap between those numbers is basically this ladder.

A simple example: suppose your specification says all timestamps must be in UTC, all API responses must include a request ID, and no external service calls are allowed in the payment module. A normal code review might catch those rules, but what if the reviewer misses them? At Level 7, you move those rules into the pipeline. The CI system can inspect the PR and check: are all timestamps in UTC? Does every response include a request ID? Are there any new dependencies on external services in the payment module? If any check fails, the PR fails.

I'm not saying AI validation will understand every sentence in a specification perfectly. It won't. The useful idea is narrower: take the parts of your requirements that can be checked automatically, and make them checks. That's much more realistic than expecting an AI validator to magically understand an entire product specification.

Here's the part that took me longest to accept: higher is not automatically better. I use Level 1 for throwaway scripts, Level 2 for everyday changes in code I know well, and Level 4 for new features where building the wrong thing would cost days. The skill isn't climbing the ladder—it's knowing which rung fits the task in front of you.

If you're at Level 1 for everything, try Level 2 this week. That's it. One habit: read the plan before the code exists. It costs you thirty seconds per task, and it would have saved me that 900-line diff.

What is vibe coding? Prompting an AI conversationally and accepting the output with no written plan or spec. Fast for prototypes, painful for production projects.

What is spec-driven development? A workflow where a version-controlled spec—living in git next to your code—is the source of truth. Code is generated from the spec, and changes start by editing the spec.

Should I let AI agents write code without review? No. Every level of this ladder keeps a human review step. The levels change when and what you review—a plan, a spec, or a PR—but never remove it.

Do I need to use all seven levels? No. I don't. A five-minute script doesn't need a specification, a multi-agent workflow, and CI-based AI validation. That would be ridiculous. Use the simplest workflow that gives you enough confidence for the task.

Is Level 7 the future of AI coding? Maybe partly. I think the bigger trend is that developers will spend less time telling AI how to write every line and more time defining what must be true when the work is finished. That's a much more interesting shift than simply asking AI to generate more code.

Your AI coding workflow probably formed by accident, sometime in 2023, and never got questioned again. Mine did. The fix isn't a new tool. It's noticing which level you're on and asking whether today's task deserves a better one. Because the future of AI-assisted development probably isn't "AI writes all the code." It's closer to "I define the boundaries. AI does more of the work inside them." And the better those boundaries become, the less time I spend fixing code I never wanted in the first place.