Vibe Coding Is Real, But Vibe Thinking Isn't
Andrej Karpathy named it in early 2025: "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." Accept all diffs. Don't read them. When you get an error, paste it back in with no comment. The code grows beyond your comprehension. It mostly works.
He was describing throwaway weekend projects, and he said as much. But the term escaped that context immediately, and now "vibe coding" gets used to describe everything from a Saturday prototype to a serious development approach. Those are not the same thing.
For a weekend project or a proof of concept, vibe coding is fine. The goal is to find out if something is worth building, not to build the thing. If the code is comprehensible to you, that's overhead you don't need yet. Move fast, see what you learn, throw it away or start over properly if it turns out to matter.
The failure mode is treating that mode as a development philosophy. Production systems evolve. Other people have to work in them. Requirements change in ways nobody predicted. Code that grew beyond your comprehension during a weekend session will not hold up to any of that. The question isn't whether it works now. It's whether it's something you can maintain, explain, and build on.
The name is the tell. It's called vibe coding, not vibe thinking. The vibe is in the coding part specifically, because that's what got offloaded. The thinking didn't go anywhere.
Architecture, system design, what to build and what not to build, how the pieces fit together, what happens when this breaks at 2am — none of that is captured in "vibe." The developers who are genuinely productive with AI aren't thinking less. They're thinking about different things. One engineer put it plainly: just because he doesn't write the code anymore doesn't mean he doesn't think hard about architecture, dependencies, and how to delight users. Using AI meant expectations of what to ship went up, not that the thinking requirement went down.
Simon Willison reframed this usefully. He pointed out that the skills needed to manage AI agents well map closely to the skills needed to manage engineers: clear task definition, knowing when to course-correct, understanding what good output looks like, reviewing work critically rather than accepting it. Almost all of those are characteristics of senior engineers.
If vibe coding means delegating typing, that's fine. If it means delegating judgment, you're not a developer using AI. You're a rubber stamp on a stochastic process.
The vibe coder's career path is the version of this that concerns me most. A junior developer who spends two years accepting diffs without understanding them hasn't spent two years building experience. They've spent two years getting output. Those aren't the same thing, and the difference shows up the first time the model is wrong and they can't tell.
Part 12 of 14 — What I Think About AI Engineering**
← Don't Delegate the Thinking The Junior Developer Pipeline Problem →