A humorous yet practical guide to AI-assisted development. DON'T PANIC.
View the Project on GitHub HermeticOrmus/hitchhikers-guide-to-vibe-engineering
“The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases: Survival, Inquiry, and Sophistication—otherwise known as the How, Why, and Where phases. For instance, the first phase is characterized by the question ‘How can we eat?’ the second by ‘Why do we eat?’ and the third by ‘Where shall we have lunch?’”
Vibe engineering is currently somewhere between “How does this work?” and “Is this even engineering?”
There is a war happening in software development. Not the old wars—tabs vs spaces, vim vs emacs, Mac vs Linux. This one cuts deeper.
On one side: developers who see AI-assisted development as a revolution. The democratization of creation. A new paradigm where anyone can build.
On the other: engineers who see it as an existential threat to craft. A shortcut that creates debt. A cargo cult of “working” code written by people who don’t understand what they’ve built.
Both sides have good arguments. Both sides have blind spots.
This chapter won’t tell you who’s right. It will help you think clearly about where you stand—and more importantly, where your code stands.
Let’s start with the critics. Their arguments are not born of fear or stubbornness. They’re born of experience.
Engineering implies understanding. It implies predictable outcomes from known inputs. It implies responsibility for what you build.
When you prompt an AI and accept its output without comprehension, you’re not engineering. You’re performing a ritual and hoping it works.
“I don’t know how it works, but it works.”
This statement would disqualify you from any traditional engineering discipline. You wouldn’t accept it from a civil engineer building your bridge. Why accept it from a software engineer building your payment system?
Every line of code is a liability. It must be understood, maintained, debugged, secured. When you don’t understand the code, you can’t assess its true cost.
AI-generated code often:
The debt compounds. And unlike financial debt, you don’t get monthly statements showing the balance.
Every prompt you write instead of code you understand is a rep you didn’t do. Skills atrophy without practice.
Junior developers who start with vibe engineering may never develop:
What happens when the AI fails and you don’t have the fundamentals to fix it?
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.
The critics have seen this movie. They’ve been called in to fix systems built by people who didn’t understand what they’d built. They know how it ends.
Now the advocates. Their arguments are not born of laziness or hype. They’re born of watching barriers fall.
For decades, software creation required years of training. Formal education. Specific tools. Arcane knowledge.
Now someone with an idea can build it. Not a perfect implementation. But a working one. Something real, that users can touch.
The person who couldn’t code yesterday can ship today. That’s not nothing. That’s a revolution in who gets to create.
Nobody writes machine code anymore. We use high-level languages that abstract away register allocation and memory management. We use frameworks that abstract away HTTP parsing and database connections.
AI is the next abstraction layer. Complaining about it is like complaining about compilers.
In a world where markets move fast, the ability to ship quickly and iterate isn’t a nice-to-have. It’s survival.
A slightly janky product that exists beats a perfect product that’s still in planning. The vibed MVP captures users, generates feedback, attracts funding. The carefully engineered alternative often never ships.
Not everyone needs to understand everything immediately. You can build first and learn later. Use the working code as a map to understand the territory.
Many successful engineers learned by modifying code they didn’t initially understand. AI-generated code is just a denser version of this.
When calculators appeared, people said students would forget arithmetic. When IDEs with autocomplete appeared, people said developers would forget APIs. When Stack Overflow appeared, people said developers would forget how to think.
Every generation has gatekeepers who insist the new way is inferior. They’re usually wrong about the magnitude of the threat, even when they’re right about the tradeoffs.
Here’s what both sides often miss:
The critics are right that vibe-engineered code often has serious problems. That understanding matters. That debt accumulates. That skills atrophy.
The advocates are right that democratization is valuable. That speed matters. That abstractions are how we progress. That gatekeeping has costs too.
The question isn’t which side is correct. It’s: correct for what?
| 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 |
| Learning fundamentals | ⚠️ Risky | ✅ Important |
Neither approach is universally correct. The error is treating either as the only way.
There’s a difference between:
The conversation changes dramatically depending on which category you’re in.
If you’re doing vibe engineering, ask yourself:
If the answer is “no” to most of these, you’re dependent on a tool you don’t understand. That’s a precarious position.
Match your approach to your context.
There’s nothing wrong with being a good prompter. But don’t confuse it with being a good engineer.
Here’s where this Guide lands:
It produces working software. That matters. Dismissing it as “not real engineering” is gatekeeping that ignores outcomes.
Technical debt, security vulnerabilities, scalability cliffs, unmaintainable systems. These are not theoretical—they’re observed, repeatedly.
Don’t pick Team Vibe or Team Traditional. Instead:
Know what you’re doing - Are you vibing or engineering? Both can be valid, but they’re not the same.
Know what you’re building - Match your approach to your stakes.
Know what you don’t know - If you can’t debug it, you don’t own it.
Grow in both directions - Use AI to ship faster AND develop deeper understanding.
Not pure vibers who never understand their code. Not pure traditionalists who refuse to use new tools.
The future belongs to engineers who can:
This is harder than picking a side. It requires judgment. But that’s what engineering has always required.
This Guide doesn’t tell you vibe engineering is good or bad. It tells you:
The rest is your call.
The universe won’t care whether your code was vibed or traditionally engineered. It will only care whether it works.
But “works” has layers. Works today. Works at scale. Works when you’re not watching. Works when users do unexpected things. Works when you need to change it.
Vibe engineering can achieve “works today” quickly. Whether it achieves the rest depends on you.
“In the beginning, the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.”
Software development, similarly, keeps creating new paradigms that make people very angry.
Assembly programmers were angry about high-level languages. Waterfall devotees were angry about Agile. Backend engineers were angry about JavaScript everywhere.
And now, traditional engineers are angry about vibe engineering.
Some of that anger is warranted. Some is resistance to change. Sorting out which is which is your job.
This Guide is just a towel. Wrap it around your head if it helps you think. But the thinking is up to you.
DON’T PANIC. But do think.
Now proceed to Chapter 1: DON’T PANIC for the practical stuff.