The 4 Levels of AI-Assisted Software Engineering

Okay, in today’s age of software engineering, you can’t avoid hearing about AI and its effect on software engineering. Even if you refuse (or are unable) to use it, you can not avoid hearing or reading about it. So, I thought I’d throw another log on the fire. I hope you enjoy!

IMHO, there are four levels of using Artificial Intelligence while sitting at a computer, with the hopeful outcome of generating code that will be reusable in some form, whether for a website, mobile app, or cross-platform video game. They are as follows:

• LEVEL 0: The “No Thank You” Engineer
• LEVEL 1: The “Gimme a Coding Butler” Engineer
• LEVEL 2: The “Agentic Ninja” Engineer
• LEVEL 3: The “Vibe Coder” Non-Engineer

Each of these has a distinct persona and has its benefits and shortcomings. I will express my opinion on what these are. Note: this is MY OPINION and NOT based on actual data. It’s just how I see things based on my narrative and experience.

LEVEL 0: The “No Thank You” Engineer

Persona: This is a plain old software engineer doing what they do, like it was 3 years ago. Sitting down, writing code (and hopefully writing tests), and making stuff. No AI. Whether it’s due to a company restriction or a personal preference, it doesn't matter. The code they write goes to production, and AI is never involved. Nine times out of ten, it’s personal preference. Whether it is pride or politics, or if it’s that they are averse to change and say they have secret knowledge. It doesn’t matter, and you will probably not convince them otherwise.

Benefits: You know what you are getting, based on the person’s skill. They may suck, to be honest. They may be great. Either way, it is a known quality that will grow over time. Unless they move into a project manager role, you will know the quality of their output and how long it will take. You can make estimates on delivery. There are decades of processes that measure this. It is predictable. It is how the software industry has been running for a very long time.

Shortcomings: They may suck. Just because it is predictable doesn’t mean the output will be good or will be done when it’s expected. There will be bugs. There will be missed deadlines. For it not to suck, you have to hire experienced and actually good engineers. That can be an expensive crap shoot. Even if you find the right person, compare an actual hotshot engineer’s salary to a $200/month Anthoropic subscription and a junior engineer’s salary, and you will see why companies are no longer finding this option appealing.

LEVEL 1: The “Gimme a Coding Butler” Engineer

For complete transparency, this is the level I identify myself as.

Persona: The "Gimme a Coding Butler" Engineer just needs a ridiculously fast junior engineer to do the busy work and annoying tasks like writing tests, boilerplate code, documentation, refactoring, and finding solutions for type errors in overly complex TypeScript. But to be honest, 90% of their usage is using it as a wickedly good autocomplete. Something like GitHub CoPilot hooked up to some Claude model. I like to call this the [TAB] - then correct style of coding. This engineer will accept a chunk of code from auto-complete or a simple prompt, then read it and fix issues before moving on.

Benefits: The Coding Butler approach improves productivity by turning boring tasks that slow them down into small chunks of code reviews and quasi-paired coding with an AI. It can reduce errors by removing human error from repetitive tasks (read: copy/paste errors). It takes the less fun parts of coding out of a job and gives it to an uncaring robot that, for the most part, knows what you want to do.

Shortcomings: The ease with which this can work may be its downfall. It can lead to what I call: “Tab-itus.” The disease of just tabbing through source code or config files without reviewing and trusting the outcome too much. You may end up with a hardcoded GUID (rather than an env var reference) that the model hallucinated from something it was taught while being built (read: some source code with a similar config pattern with hardcoded GUIDs).

LEVEL 2: The “Agentic Ninja” Engineer

More Transparency, I had an AI write most this chunk.

Persona: The Agentic Ninja has moved well beyond coding butlers. They've embraced AI as part of the system itself, orchestrating Multi-Agent Systems in which models collaborate, delegate, and produce results that no single prompt could achieve. They live inside tools like Cursor or Claude Code, wiring up MCP (Model Context Protocol) services that give agents real-world reach: querying databases, calling APIs, pushing commits. MCP is the connective tissue that turns a language model from a smart text box into something that can actually do things. Layered on top is the ReAct pattern (Reason + Act), a feedback loop in which the agent thinks, acts, observes the result, and thinks again, making it dramatically more capable of solving complex, multi-step problems. But what separates the Ninja from a reckless cowboy is knowing when to insert a Human in the Loop. Deleting prod records? Human checkpoint. Deploying? Absolutely a human checkpoint. An autonomous agent with unchecked permissions is a liability, not a superpower.

Benefits: The productivity ceiling here is dramatically higher than Level 1. Tasks that would take a Level 1 engineer hours can be handed off to an orchestrated agent pipeline that just... handles it. You can build internal tooling, run complex code migrations, spin up entire feature scaffolds, and have agents cross-check each other’s work. All with you in the director’s chair rather than in the weeds. MCP services give your agents real context about your environment, not just generic knowledge. This is the level where AI stops feeling like a shortcut and becomes genuine leverage.

Shortcomings: The complexity here is real and bites hard. Multi-agent systems fail in spectacular, non-obvious ways: one agent passes bad output to the next, errors compound, and suddenly you're three layers deep in a mess harder to debug than anything you'd write yourself. MCP configs can be brittle; your Human-in-the-Loop safeguards are only as good as the places you remember to put them (and you'll forget one). The tooling is evolving so fast that it makes JavaScript framework churn look stable. There's also a subtler trap: code written entirely by agents may work, but it's often more readable to another AI than to a human. Agents optimize for outcomes, not patterns. This can produce massive pull requests that a review bot clears in a minute, but a human engineer would need a day to untangle. It works. But good luck maintaining it.

LEVEL 3: The “Vibe Coder” Non-Engineer

Persona: Ah, the vibe coder. Whether it’s somebody who has never seen actual code, or an engineering director who has dipped their toes in the coding world many moons ago, this is a non-engineer who prompts an AI to build something. Whether it is a website, a mobile app, or something else, the code is just a byproduct of the end goal: Gimme what I want. They keep entering prompts as if they were talking to their own engineering and design teams, tweaking design, functionality, and user experience until they get what they want. There is little to no concern about the code, where or how it is hosted, the technologies used, security, or code quality. Just build it.

Benefits: This has been a miracle for non-engineers to materialize their ideas without the time, money, or the back-and-forth of dealing with actual engineers. From zero to hero in a weekend. This is the big promise of AI: to build something by just describing it.

Shortcomings: Most of the time (not all), this results in insecure slop that is nowhere near ready for production. When handed off to a team of engineers to secure, productionize, and host, it's most often a horror show of passwords stored in clear text in a backend using SQLite, all the styles are inline CSS classes in every single HTML element, or any number of issues that make it insecure, unstable, or flat-out unusable.

Conclusion

None of these levels is the best or the worst. They are just different. Also, code from a Vibe coding manager is not always worse than code from a non-AI coding senior engineer. There are always exceptions and edge cases. These are just new and different options from getting from “Point A” to “Production Code.”

Also, these are not distinct buckets that a person is exclusively in. There are days when I personally will take on all 4 personas. Think of these as a sliding scale that a person building something may use to get stuff done. You don’t have to be JUST a vibe coder.

AI has affected how code is generated from idea to product. When used where the benefits outweigh the shortcomings for a particular case, it is a win. But the reverse is also true. So, watch out for the cases where those shortcomings might bite you in the ass.