The Hitchhiker's Guide to Vibe Engineering
In February 2025, Andrej Karpathy coined the term:
"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."
A year later, we have enough data to separate signal from noise. Not from theory -- from building.
I wrote The Hitchhiker's Guide to Vibe Engineering as a field manual for people in the middle. Not the hype crowd who think AI replaces understanding. Not the gatekeepers who refuse to adapt. The builders who want to move fast and know what they've built.
This journal entry captures the essential insights. The full guide has 10 chapters, 7 field entries, and a lot of Douglas Adams references.

The Distinction That Matters
Vibe coding is giving in to the vibes and forgetting the code exists.
Vibe engineering is the deliberate practice of building software through AI collaboration -- describing intent, reviewing output, and iterating toward working systems. The difference is the word engineering: understanding what you build, owning what you ship, and knowing the difference between a prototype and production.
This distinction isn't semantic. It determines whether your project survives contact with real users.

The War of the Vibes
There's a war happening in software development. Not tabs vs spaces. This one cuts deeper.
The critics say AI-assisted development creates invisible debt, atrophies real skills, and produces code that nobody understands. They've been called in to fix systems built by people who didn't understand what they'd built. They know how it ends.
The advocates say the gatekeeping is over. AI is the next abstraction layer, like compilers before it. The person who couldn't code yesterday can ship today. That's a revolution in who gets to create.
Both sides have good arguments. Both sides have blind spots. The error is treating either as the only way.
The Context Matrix
| Context | Vibe Engineering | Traditional Engineering |
|---|---|---|
| Prototype to test an idea | Appropriate | Overkill |
| Personal project | Appropriate | Optional |
| Hackathon / Demo | Appropriate | Too slow |
| MVP for early users | With caution | Consider hybrid |
| Production at scale | Dangerous | Necessary |
| Safety-critical systems | Unacceptable | Required |
Neither approach is universally correct. Match your approach to your stakes.

DON'T PANIC
When you first start building with AI, you'll experience three phases:
- The Wow Phase -- "This is incredible! It wrote my entire function!"
- The Horror Phase -- "Wait, this code makes no sense and broke everything"
- The Acceptance Phase -- "Ah, I see. It's a tool, not a replacement for thinking"
Most developers get stuck oscillating between phases 1 and 2 indefinitely. The goal is phase 3.
Your towel in vibe engineering is version control. Four commands will save you more times than you can count:
git status
git diff
git stash
git checkout .

The Babel Fish Problem
The AI doesn't understand your intent. It predicts tokens based on patterns. This creates specific failure modes:
Ambiguity amplification -- vague prompts produce code that works for the wrong reasons. "Make it faster" might get you caching that hides a broken query instead of fixing it.
Confident incorrectness -- the AI generates code with the same confidence whether it's right or wrong. There's no uncertainty signal. You have to provide the verification yourself.
Context decay -- the longer the conversation, the more the AI "forgets" earlier decisions. The function it wrote in message 3 might contradict the architecture from message 1.
The fix is specificity. Not "build me an auth system" but "add JWT authentication to the /api/users endpoint using the existing User model, with 15-minute token expiry and refresh token rotation."

The Risk Classification
Every piece of code carries a risk level. Match your vibe level to it:
- Mostly Harmless -- If it breaks, nothing bad happens. Vibe freely.
- Caution Advised -- Annoying but recoverable failures. Read before running.
- Danger -- Real problems occur if this fails. Understand every line.
- Here Be Dragons -- Catastrophic consequences possible. Don't vibe. Engineer.
A landing page is Mostly Harmless. A payment processor is Here Be Dragons. Most code falls somewhere in between, and the skill is knowing where.

The Honest Questions
Before shipping anything AI-assisted, ask yourself:
- Can you debug it? If the code breaks, can you fix it?
- Can you explain it? Could you walk someone through what it does?
- Can you extend it? When requirements change, can you modify it?
- Can you own it? Are you willing to be responsible for this in production?
If you answered "no" to most of these, that's fine -- for prototypes. For production, keep learning until the answers change.

When Vibed MVPs Meet Reality
Here's the part nobody talks about at hackathons: what happens when the prototype gets users.
The vibed MVP works at 100 users. At 10,000, the accumulated decisions -- made by an AI optimizing for immediate function, not long-term quality -- start breaking. Database queries that ran fine now take 800ms. Environment variables with real secrets sit in .env.example. Background jobs share the same server as web traffic. One user uploads a 50MB CSV and the whole sign-up flow crawls.
The street rule:
Vibes get you to market. Systems get you to scale. Know when to switch.
This isn't a failure of vibe engineering. It's the natural lifecycle. The mistake is not recognizing the transition point.

The Synthesis
Here's where I land after a year of building this way:
Vibe engineering is real. It produces working software. Dismissing it as "not real engineering" is gatekeeping that ignores outcomes.
Vibe engineering has real risks. Technical debt, security vulnerabilities, scalability cliffs, unmaintainable systems. These are not theoretical -- they're observed, repeatedly.
The solution is awareness, not sides. Know what you're building, know what you don't know, and grow in both directions. Use AI to ship faster and develop deeper understanding.
The future belongs to engineers who can use AI to accelerate without becoming dependent. Who can read and understand generated code critically. Who know when to vibe and when to verify.
This is harder than picking a side. It requires judgment. But that's what engineering has always required.

Read the Full Guide
The complete guide is now hosted right here on this site. Read all 10 chapters and 7 field entries -- from version control as survival tool to what happens when your vibed MVP meets production reality.
Read the full Hitchhiker's Guide to Vibe Engineering
Also available on GitHub.
DON'T PANIC. But do think.
-- Ormus