"Vibe coding" gets thrown at everything built with AI, which blurs a distinction that actually matters. Simon Willison drew the useful line in March 2025: building with an LLM without reviewing the code is vibe coding, while reviewed, tested, and explainable work is software development, however much AI helped. One line, two modes, and every AI-assisted project sits somewhere between them.

Getting the distinction right protects builders in both directions. It keeps low-stakes experiments fast and guilt-free, and it stops plausible-looking but unreviewed code from quietly carrying real users, real money, or real data.

This lesson maps the full spectrum, from unreviewed vibes builds to what the field now calls agentic engineering. It shows how the same person works at both ends, why stakes rather than skill pick the mode, and what accountability looks like for builders who can't yet read the code they ship.

The review line

Every AI-assisted build lands on one side of a single line: does a human review the code before it ships? Simon Willison drew that line in March 2025, defining the vibes side plainly: "When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes." [1]

Andrej Karpathy had coined the term in early February 2025 with throwaway weekend projects in mind [2], and within weeks people were stretching it to cover all AI-assisted programming. Willison's post was a rescue mission. He worried the definition was "already escaping its original intent" and pushed back on vibe coding becoming a lazy synonym for any code an LLM touched.

The line says nothing about who wrote the code or how much AI helped. It asks only what happens after generation, and that single question sorts every build in this course into one of two modes.

Vibe coding vs. software development

Willison's corollary defines the far side of his line: "If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that's not vibe coding, it's software development." He adds that "the usage of an LLM to support that activity is immaterial." [3]

Three practices carry all the weight in that sentence: review, testing, and explanation. A developer who ships unread agent output is vibe coding no matter how senior they are. A builder who reads, tests, and can explain generated code is doing software development no matter how much of it an LLM typed.

The tool never defines the discipline; the accountability practices do. That's why the distinction survived a year of tooling churn intact. The agents changed, and the line didn't.

Floor and ceiling

Floor and ceiling

Andrej Karpathy gave the spectrum its most teachable shape at a Sequoia fireside chat in April 2026: "Vibe coding raises the floor. Agentic engineering is about extrapolating the ceiling." [4]

Raising the floor means more people can build software at all. In Karpathy's words, "Everyone can vibe code anything, and that is amazing." Extrapolating the ceiling means the best practitioners reach further than ever; he argues the old idea of the 10x engineer now undersells it, because "people who are very good at this can peak much higher than that."

The frame kills the idea that one end should replace the other. A rising floor and a rising ceiling are different jobs. The floor invites everyone in, and the ceiling protects the quality bar of professional software.

What is agentic engineering?

The accountable end of the spectrum spent a year looking for its name. In October 2025, Willison asked what to call "the other end of the spectrum, where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce," and proposed "vibe engineering" with his tongue partially in his cheek [5]. By February 2026 he conceded the naming contest: "agentic engineering" had won. A new generation of coding agents released in 2025, including Claude Code, Codex CLI, and Gemini CLI, made this end viable at scale.

Whatever the label, the work is harder than vibe coding, not just stricter. Willison describes it as operating "at the top of your game": researching approaches, deciding on high-level architecture, writing specifications, and spending heavily on code review.

The labels are still churning, so it pays to hold them loosely. The axis they sit on, accountability for the software produced, has stayed put.

One person, both ends

The clearest evidence that the spectrum isn't a personality type is that its strictest definer lives at both ends. Willison has published a collection of more than 80 single-purpose browser tools, most of them vibe coded [6]. The same person maintains production software, Datasette and sqlite-utils, where agents write much of the code under tests, review, and full accountability. His July 2026 release notes credit an agent with most of a release for about $149.25, with Willison reviewing as the accountable engineer [7].

The same builder can vibe code an experiment on Monday and engineer a production release on Thursday, because the two ends answer different questions about the same skill set. Nothing about moving between them requires a change in ability, only a change in what gets checked.

The pattern worth copying is the switch itself. Treating a starting mode as an identity is how builders get stuck; mode follows the work, not the self-image.

Stakes pick the mode

The spectrum needs a selector, and stakes are it. Willison gates the vibes mode on one question: "Think about how much harm the code you are writing could cause if it has bugs or security vulnerabilities." [8] Karpathy scoped vibe coding to throwaway weekend projects in the very tweet that coined it [9]. Low-stakes projects earn the vibes mode; real users, real money, or real data push a project toward the engineering end.

Karpathy's own MenuGen app shows why. His agent assigned purchased credits by matching a customer's Stripe email to their Google email, two addresses that can differ, when the design needed a persistent user ID [10]. The code looked plausible and ran fine; the flaw stayed invisible until someone reviewed the design.

That's the trap of letting the tool's speed pick the mode. Generation is so fast that shipping feels natural, right up until a payment bug does the deciding instead.

Pro Tip! Naming the worst realistic outcome of a bug, before writing any prompt, picks the mode faster than any capability checklist.

A spectrum, not a ranking

A common misreading turns the spectrum into a status ladder, with vibe coders at the bottom and engineers at the top. Neither end was coined as an insult. Willison, the strictest definer of the line, is also vibe coding's loudest defender: "I believe everyone deserves the ability to automate tedious tasks in their lives with computers. You shouldn't need a computer science degree or programming bootcamp." [11] He drew the line partly to stop vibe coding from becoming a negative term for irresponsible AI-assisted programming.

Karpathy's floor and ceiling completes the correction, because it makes both ends good at different jobs. The floor end is where anyone automates their own life. The ceiling end carries a rule the floor doesn't: "You are not allowed to introduce vulnerabilities because of vibe coding. You are still responsible for your software, just as before." [12]

The axis measures accountability for stakes. It says nothing about talent or worth, and the people who drew it are explicit about that.

The explainability bar

Willison's golden rule sets the bar at the engineering end: "I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else." [13] The bar is explanation, not authorship. Code someone can't explain is code they can't vouch for, whoever or whatever wrote it.

Read too literally, the rule seems to lock non-coders out of the spectrum entirely, since they can't review a diff line by line. But the underlying variable is accountability: testing thoroughly, understanding behavior, and owning consequences. A non-coder moves along the spectrum by verifying what a project does (its behavior, the data it touches, and who can reach it), by keeping stakes controlled, and by staying honest about what they can't yet vouch for.

Full code review remains the professional bar, which is why serious projects eventually graduate to someone who can clear it. Later lessons cover exactly when and how that handoff happens.

Pro Tip! A build passes the honest non-coder version of the bar when its maker can explain what it does, what data it stores, and who can access it, without opening the code.

Does more rigor mean less AI?

Rigor sounds like restraint, so a natural assumption is that the engineering end uses AI sparingly. In practice the opposite holds. Willison reports "experienced, credible software engineers who are running multiple copies of agents at once," a workflow he calls "surprisingly effective, if mentally exhausting!" [14] Karpathy dates an inflection to December 2025, when delegated chunks of work "just came out fine" and the unit of professional work shifted from writing lines to assigning whole features [15].

What grows at the engineering end isn't AI restraint but human accountability wrapped around heavier AI use. Ethan Mollick describes the shift as redistributing expertise, from writing every line to knowing enough about systems to guide, troubleshoot, and evaluate [16]. Andrew Ng is reported to have called this kind of work "a deeply intellectual exercise."

More rigor means more judgment applied to more automation, not less of either. That's the version of the engineering end this course points learners toward.