Vibe coding is real. Here's what nobody is telling you.

"Vibe coding" went from a meme to a job posting in about nine months.

If you're not deep in the AI corner of Twitter, here's the short version: you describe what you want, the model writes the code, you don't really read it, you just check if it works. The phrase started as a joke. Now there are courses, books, and a half-dozen YC companies built on the assumption that this is the new default.

It mostly is. It also isn't. Both things are true at the same time, and that's the part nobody seems to want to say cleanly.

Rule of thumb

Vibe coding works in inverse proportion to how many people will have to live with the result. Solo weekend project: pure vibes, ship it. Team codebase touched by five engineers: plan, name, document, then vibe.

What's actually happening

Look around any dev team that's been allowed to use AI freely for the past year. Roughly:

• Quick scripts, prototypes, internal tools: almost entirely vibe-coded now. Reading them feels like a waste of time even when you should.
• Production application code: hybrid. Most of it generated, then reviewed, then often partially rewritten.
• Critical infrastructure (auth, payments, anything touching user data): still mostly written by hand. Read three times by humans. AI used for review, not authorship.

That spectrum is the actual reality. The people screaming "vibe coding will ruin software" are mostly looking at the first column. The people promising 10x output are conveniently forgetting the third.

The two failure modes nobody is warning you about

One is the obvious one: the code looks fine, runs fine, and is quietly wrong. The agent picked the wrong abstraction. The function handles 95% of inputs but corrupts the data on the other 5%. You don't notice for a month.

The second is more interesting. When you vibe-code for long enough, you stop developing the mental model of the system you're building. You stop knowing where the load-bearing decisions are. You stop being able to predict where the next bug will come from. The codebase becomes a black box you co-author with the model, and the moment something breaks at 2 AM, you don't have the intuition to find it fast.

This is the thing that should worry junior engineers more than the "AI is taking my job" headline. The job isn't going away. The career path is just getting steeper. The fast climb you used to get from grinding through CRUD apps for two years — the climb that turned curious 22-year-olds into useful 24-year-olds — that climb is shorter and slipperier now.

What's actually changing in hiring

I've sat in on a lot of interviews in the last six months. Two things have shifted:

The take-home is dead, or close to it. Nobody can tell if you did it yourself, and everyone knows that. So we're back to live coding, and live coding is back to caring about how you think out loud.

What we're testing is different. We don't really care if you can write a binary tree traversal anymore. We care if you can read 400 lines of unfamiliar code, find the bug, and explain it back to us in a way that proves you understood what you read. That's the skill that didn't get automated. That's the skill that probably can't be.

When you're…	Vibe coding is	What to do anyway
Prototyping for yourself	Honestly fine	Keep going. Ship the demo.
Building a side project	OK if you'll throw it out	Decide that up front, not after launch.
Working in a team codebase	A liability disguised as speed	Plan the API surface first. Vibe the implementation.
Writing infra / migrations	Dangerous	Write the rollback before the change.
Touching auth or money	Don't	Pair with a human. Bring code review.

What to do this week

If you're worried, this is the boring practical advice that actually works.

Use AI for everything you're trying to ship. Stop pretending you're not going to. Just commit to it.

But for at least one hour a week, code something hard by hand. Not for productivity. For practice. Pick something where you have to read other people's code, understand it, and modify it without the agent. This is the only thing that keeps the muscle warm.

When you do use the agent, force yourself to read what it wrote. Not skim. Read. If you can't explain a function it wrote, you don't get to merge that function.

That's it. That's the whole strategy. It's not glamorous. It works.

Closing

Vibe coding is real. It's also been a part of how engineers work since the first time someone copy-pasted from Stack Overflow without reading the answer. The tooling got better. The risk got better-disguised. The fix is the same it's always been: care enough about your craft to keep your hands on it, even when you don't have to.