Andrej Karpathy coined “vibe coding” in early 2024. The idea: let AI write your code, don’t worry too much about understanding it, just see if it works.
It went viral. Everyone was vibe coding.
Most of them shouldn’t be.
There’s a crucial distinction that gets lost in the hype: vibe coding and vibe engineering are not the same thing.
TL;DR: Vibe coding is accepting whatever AI produces without scrutiny. Vibe engineering is using AI while staying suspicious—watching, catching mistakes, redirecting. One produces demos. One produces production code. Know which you’re doing.
What Vibe Coding Actually Means
Here’s Karpathy’s original description: You prompt the AI. It writes code. You don’t really understand what it wrote. You run it. If it works, great. If not, you paste the error back and try again.
Vibe coding treats AI as a black box. Input a problem, output a solution. Don’t look too closely at what’s inside.
For certain use cases, this works. Karpathy was building a one-off tool for personal use. It didn’t need to be maintainable. It didn’t need to handle edge cases. It just needed to work once.
But vibe coding has become shorthand for all AI-assisted development. That’s where things go wrong.
What vibe coding looks like:
- Accept the first output
- Trust AI suggestions without reading them
- Debug by pasting errors back to the AI
- Ship when the demo works
- Assume the AI knows what you meant
This is fine for throwaway scripts. It’s dangerous for production code.
What Vibe Engineering Means
Vibe engineering is something different. You’re using AI to code. But you’re not trusting it.
“Vibe engineering: when you’re using agents to code all the time, like you don’t touch the code, but you just look at your screen like, ‘Hm, I’m going to catch you.’”
You’re watching. You’re suspicious. You know the AI is going to make mistakes, and your job is to catch them before they ship.
What vibe engineering looks like:
- Review every suggestion before accepting
- Understand what the code does, even if you didn’t write it
- Catch architecture mistakes early
- Redirect when the AI goes off track
- Know when “good enough” is actually good enough
The AI does the typing. You do the thinking.
The Crucial Difference
The difference isn’t about tools or prompts. It’s about stance.
| Vibe Coding | Vibe Engineering |
|---|---|
| Trust the AI | Supervise the AI |
| Accept outputs | Question outputs |
| Debug by retrying | Debug by understanding |
| Works until it doesn’t | Catches problems before shipping |
| Treats AI as expert | Treats AI as fast but fallible assistant |
Here’s the thing: managers have been “vibe coding” forever. They tell developers what to build, test the app, and never read the code. That’s fine—it’s their job. They’re delegating to people they trust.
The problem is when developers vibe code. Because developers are the last line of defense. If they accept everything the AI produces without scrutiny, nobody is checking the work.
Vibe engineering keeps you in the loop. You’re delegating the typing, not the thinking.
When Each Works
Vibe coding works when:
- You’re building a one-off script
- The code won’t be touched again
- Edge cases don’t matter
- Nobody else will maintain it
- Security isn’t a concern
- Scale isn’t a concern
- It’s a prototype or demo
Vibe engineering is required when:
- The code goes to production
- Other people will maintain it
- Edge cases matter
- Security matters
- It needs to handle load
- It needs to be reliable
- You’re building something that lasts
The problem isn’t vibe coding itself. It’s vibe coding things that should be vibe engineered.
How to Vibe Engineer
Vibe engineering isn’t complicated. It’s disciplined.
1. Start with clear intent.
Before prompting the AI, know what you want. Not a vague idea—specific requirements. Architecture decisions. Edge cases. Error handling.
Bad: “Add user authentication.”
Good: “Implement email/password auth using NextAuth. Store sessions in database. Middleware for /dashboard routes. Rate limiting on login attempts.”
The AI executes what you describe. If your description is vague, the output will be vague.
2. Watch the first few lines.
The AI starts wrong. Regularly. Wrong pattern. Wrong architecture. Wrong assumption. If you catch it in the first three lines, you redirect. If you wait until it’s done, you’re rewriting everything.
Watch the screen. When it starts going in the wrong direction, stop it. “No, that’s not how we handle this.”
3. Question the suggestions.
Don’t accept on autopilot. Read what the AI is suggesting. Ask yourself:
- Does this follow our existing patterns?
- What happens if this fails?
- What edge cases is this missing?
- Will this be maintainable?
If you can’t answer these questions, you’re vibe coding, not vibe engineering.
4. Understand before you merge.
You don’t have to write the code. You do have to understand it. Before merging AI-generated code, you should be able to explain what it does and why.
If someone asks “why did you do it this way?” and your answer is “the AI suggested it,” you’re not engineering.
5. Know when to stop.
AI will keep generating. Keep suggesting. Keep adding. Vibe engineering means knowing when the code is sufficient. When more abstraction makes things worse. When to stop accepting and start shipping.
This is judgment. It’s the skill that makes vibe engineering work.
The Experience Spectrum
Not everyone can vibe engineer. There’s a spectrum.
| Experience Level | Typical Response |
|---|---|
| Juniors | “Hell yeah, give me everything.” |
| Mid-levels | “This will never be good enough. My code is better.” |
| Seniors | “This is a tool. Let me use it properly.” |
Juniors vibe code because they don’t know what to look for. They can’t spot when the AI is wrong.
Mid-levels resist AI because they’re protective of their craft. They see “good enough” as an insult.
Seniors vibe engineer because they know what good looks like. They catch mistakes. They know when to accept and when to push back. They have the judgment.
That’s why the best results come from giving AI tools to skeptical seniors and convincing them to use them. They have the judgment to supervise.
First Thing Tomorrow
Ask yourself: Am I vibe coding or vibe engineering?
- Check your last three AI-generated commits. Can you explain what the code does and why? If not, you’re vibe coding.
- Review your accept rate. How often do you accept the first suggestion? If it’s more than 50%, you’re probably not scrutinizing enough.
- Watch the start. Next time you prompt the AI, watch the first 3-5 lines closely. If it’s going wrong, stop it immediately.
- Add the question pause. Before accepting, pause. Ask: Does this follow our patterns? What happens if this fails? What’s it missing?
- Know your scope. Are you building a throwaway script or production code? Match your approach to the stakes.
The goal isn’t to avoid AI tools. It’s to use them with judgment.
The Bottom Line
Vibe coding produces demos. Vibe engineering produces production code.
The difference is judgment. Watching what the AI does. Catching mistakes. Knowing when to accept and when to redirect.
AI tools are amplifiers. They amplify what you already know. If you know what good code looks like, vibe engineering makes you faster. If you don’t, vibe coding makes you dangerous.
Choose accordingly.
Building AI capability in your team? The tools are the easy part. Teaching vibe engineering—that’s where results come from. Let’s talk.