Vibe Coding Works Until It Doesn't. The Difference Is Underground.

There's a three-panel image going around: three buildings, three foundations. Vibe coding sits on a pit of scrap metal. Software engineering stands on concrete piers. AI-assisted engineering rests on something that looks like mission control, sensors and live readouts everywhere.

It's a good meme, and it's usually read backwards. The three aren't a skill ladder with AI-assisted engineering as the trophy on top. What separates them is the foundation, the part of the building nobody photographs, and whether you bothered to dig one at all.

What "vibe coding" actually means

The term comes from Andrej Karpathy, who described it in February 2025 like this:

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

He meant it partly as a delight, and he's right that it is one. You describe what you want, the model produces it, you run it, and you barely glance at the diff. For a weekend toy or a prototype you plan to delete, that loop is genuinely great, and I use it that way constantly.

So vibe coding isn't a slur. It's a mode: prompt, generate, accept, repeat, with your attention on the output and not the structure underneath it. The trouble only starts when you use that mode to build something that has to stand up.

Why vibe coding works until it doesn't

Here's the uncomfortable part: vibe coding works. That isn't sarcasm. The code runs, the demo lands, the feature ships, and for a while nothing pushes back.

The catch is that "it runs" and "it's sound" are different claims, and vibe coding only ever checks the first one. You didn't design the data flow, so you have no model of it. You didn't choose the boundaries, so you don't know which ones are load-bearing. The structure exists, but it exists in the model's head, and the model is gone the second the chat closes.

Then something breaks that wasn't on the happy path. A race condition, a state bug that only surfaces under real traffic, a dependency that behaves differently in production. Now you're debugging a system you never understood, and that's not really debugging. It's informed guessing.

I got into this failure mode from the model's side in an earlier post: a pattern matcher will happily "fix" the same symptom five times while the real cause sits untouched. Vibe code, and you inherit that blindness, then stack your own on top, because you can't correct a design you never learned.

What software engineering actually buys

Software engineering is the slow, expensive answer to that problem, and it's slow and expensive on purpose.

You design the system before you build it. You decide where the boundaries go and why. You know which invariants have to hold, so when one breaks, the failure is legible instead of mysterious. The foundation is deep because you dug it deliberately, and the building scales because someone thought about load before pouring concrete.

None of that is free. It's slower to start. And a real fraction of the work, the wiring, the scaffolding, the tenth variation of the same CRUD handler, is mechanical labor that never needed your judgment in the first place. It just needed doing. That gap, between the judgment that matters and the labor that doesn't, is exactly where the third mode lives.

AI-assisted engineering: the foundation, instrumented

AI-assisted engineering is not "software engineering, but the model does it." It's software engineering where you still own every decision that matters, and the model does the digging.

You set the architecture, the boundaries, the invariants, the threat model, the performance budget. Then you hand the mechanical work down: generate the handler, port the module, enumerate the test cases, refactor across forty files at once. The judgment stays with you. The typing doesn't.

Look at the third panel again. The foundation isn't a different shape from the engineered one. It's the same piers, driven to the same bedrock. What's added is instrumentation: strain gauges, load readings, a settlement monitor. That's the honest version of what the model does well here. It doesn't replace the foundation, it puts more eyes on it, faster, so you can dig deeper on the same budget of attention.

In practice that looks like asking the model to sketch three schema designs before you commit to one, to draft the tests you'll then sharpen, to translate a rough proof-of-concept into the shape your codebase actually wants. The engineer's work moves up the stack, toward the decisions that were always the point: architecture, security, performance, and the business logic no model has enough context to own.

The honest part: vibe coding isn't the villain

It would be easy to close by dunking on vibe coding, and that would be wrong.

Vibe coding is the right tool far more often than engineers like to admit. When I'm learning an unfamiliar library, checking whether an idea is even worth pursuing, or building something I fully intend to throw away, understanding the architecture is wasted effort. The point is speed, and the blast radius is one afternoon.

The mistake was never vibe coding. The mistake is vibe coding something load-bearing and then telling yourself you engineered it. A prototype that gets quietly promoted to production, with nobody stopping to dig it a foundation, is how you end up living in that first panel: a real building, occupied, resting on a pit of scrap that everyone has agreed not to look at.

Pick the mode deliberately. Match it to what you're actually building, and to what it costs you the day it breaks.

How to work in the third mode

If you want the third mode instead of the first, the shift is smaller than it sounds. It's mostly about keeping the foundation work for yourself and refusing to let the model quietly take it.

Decide the structure before you prompt. Name the boundaries, the data flow, and the invariants, in the prompt or just in your head, so the model is filling in a design you own instead of inventing one you don't.

Let the model dig, not decide. Boilerplate, translations, test scaffolding, wide mechanical refactors: hand all of it over without guilt. Architecture, security trade-offs, and the calls that are ruinous to reverse in six months: keep every one of them.

Then check the load paths yourself. Read the generated code the way you'd read a pull request from a junior engineer, because that is exactly what it is. "The AI wrote it" has never once survived an incident review.

The building you can see was never the interesting part. It's the foundation, the thing nobody photographs, that decides whether what you shipped is still standing a year from now.

Vibe coding skips it. Software engineering pours it by hand. AI-assisted engineering digs it deeper and wires it with sensors, as long as you are still the one who chose where to dig. So the next time you reach for a model, answer the one question that actually sorts these three apart: am I building something to throw away, or something that has to hold weight? Then pick your foundation to match.

If you want the companion piece, on which specific decisions stay yours once the model is writing the code, I got into that here.