Vibe Coding vs Engineering: Where to Draw the Line in Real Projects

#ai #webdev #programming #productivity

Last month a client sent me a message that started with "it was working yesterday" and ended with "can you fix it today." In between those two lines was a login system that an AI tool had generated in about four minutes, that nobody had actually read, and that had quietly been letting a password reset link work even after the password was already reset.

Nobody caught it because nobody looked. The code ran. The demo worked. The client was happy for exactly nine days.

This is the story behind almost every vibe coding horror story you have read this year, and it is also the reason half of Twitter is fighting about whether AI just killed software engineering or just made it faster. Both sides are a little bit right and mostly missing the point 🙂

What vibe coding actually is

Andrej Karpathy coined the term back in February 2025, and his original definition is worth repeating because most people online have already forgotten it. Vibe coding is describing what you want to an AI and accepting what comes back without really reading it. You are steering by feel, not by understanding. That is not an insult, it is literally what the word means.

Used the way Karpathy meant it, vibe coding is genuinely great. Spinning up a throwaway prototype over a weekend, testing whether an idea even has legs, learning a framework by watching an AI build something and asking it questions along the way, none of that needs a senior engineer's discipline. Speed is the entire point. If it breaks, you throw it away and try again in twenty minutes.

The problem is that the term escaped its original meaning. Now every AI-assisted line of code gets called vibe coding, whether it is a weekend hackathon project or a payment flow running in production for paying customers. That is where the real argument starts.

Where engineering actually earns its name

Simon Willison, one of the more clear headed voices in this whole mess, drew a line that I think is the most useful one floating around right now. He calls the disciplined version vibe engineering. Same AI tools, completely different process. Version control. Tests that actually catch regressions. Code review, even if the reviewer is you five minutes later with fresh eyes. A written plan before the agent starts typing. Observability so when something breaks in production you find out from a dashboard and not from a client's angry message.

None of those practices are new. They are the same things engineering teams have argued about since before AI existed. The only thing that changed is speed. The AI does the typing, you still have to do the thinking.

I have started treating every piece of AI generated code exactly like a pull request from a junior developer who is fast, confident, and occasionally makes things up with total conviction. I would never merge that PR without reading it, so why would I ship AI code without reading it either.

The real cost nobody tweets about

Here is the part that does not make it into the hot takes. The failures from skipping engineering discipline are rarely dramatic. They do not crash the app in a way you notice immediately. They are quiet. A permission check that only covers the happy path. An API call with no retry logic that fails silently under load. A database query that works fine with ten rows and falls apart with ten thousand.

I have shipped client work fast using AI for boilerplate, CRUD screens, repetitive UI, the stuff that genuinely is faster and just as reliable when AI writes it. That part of the hype is real, not exaggerated. But the moment real users, real payments, or real data show up, I switch modes completely. Same tools, different process, different level of paranoia.

That switch is the entire skill now. Not typing code faster. Knowing exactly when speed stops being an advantage and starts being a liability.

A rough way to draw the line yourself

Ask what happens if this breaks in front of a real user. If the answer is you shrug and fix it later, vibe coding is fine, go fast, enjoy it. If the answer involves a client email with the words "urgent" and "production" in the subject line, you need the boring stuff. Tests. Review. A second pass where you actually read what the AI wrote instead of trusting the green checkmark.

Ask who else has to touch this code in six months. A throwaway prototype only has to make sense to you, today. Anything that other developers will maintain, extend, or debug later needs to be understandable without you standing over their shoulder explaining what the AI meant.

Ask what the blast radius is. A broken internal dashboard is annoying. A broken authentication flow is a headline. Match your caution to the actual stakes, not to how confident the AI output sounded.

None of this means slowing everything down to a crawl either. Overengineering a landing page nobody will ever scale is its own kind of waste. The goal was never choosing a side. It was learning to switch gears on purpose instead of by accident.

The teams and freelancers who are actually winning with AI right now are not the ones who typed the fastest prompt. They are the ones who know exactly which mode they are in before they hit enter, and who are honest enough to admit when the code they just shipped needs a second look before anyone else depends on it.

The client's login system got fixed the same day, by the way. Took forty minutes once I actually read the code line by line instead of trusting that it worked because it looked right. Forty minutes I would have happily spent before shipping it, if I had known to look.