There’s a specific kind of productive feeling that AI-assisted development delivers. You know the one. Tab to accept. Tab to accept. A whole function appears. You didn’t write it exactly, but it’s roughly right, and you move on. An hour passes. You’ve shipped more lines of code than you used to write in a day. You feel like a senior engineer with a tailwind.
The feeling is real. That’s what makes it worth looking at closely.
The intoxication is the point
“Vibe coding” — the term that’s been floating around since Karpathy coined it in early 2025 — isn’t really about laziness. It’s about flow. When AI collapses the friction between intention and implementation, you get to stay in the creative headspace longer. You’re thinking about what you want the product to do instead of fighting with how to make it do that. For experienced engineers, this is liberating in ways that are hard to overstate.
But flow is a psychological state, not a quality signal.
You can be deeply in flow building exactly the wrong thing. You can feel productive while accumulating a kind of debt that doesn’t show up in your error logs — not technical debt in the traditional sense, but something quieter: product debt. A growing surface area of features and interactions that work but were never really thought about. Code that answers the question you asked, not the question you should have asked.
What speed actually costs
When implementation was slow and expensive, you had something you didn’t appreciate: natural checkpoints.
Writing a component from scratch forced you to think through its states. Connecting an API by hand meant you understood the data shape before you wired it to the UI. Building something the slow way created friction — and friction, it turns out, was doing some important work. It made you sit with the problem long enough to notice the edge cases, the wrong assumptions, the feature you were about to build that nobody actually needed.
AI has mostly removed that friction. Which is mostly great. But “mostly” is carrying a lot of weight in that sentence.
What you lose when implementation becomes fast is the forcing function to stay honest with yourself about whether what you’re building is right. The resistance of the craft used to push back on bad ideas in real time. Now bad ideas implement just as smoothly as good ones. Faster, sometimes, because they’re simpler.
This is the hidden cost of vibe coding at scale: not that the code is bad, but that the decision to write it was never really pressure-tested.
Feeling productive vs. being productive
There’s a distinction worth making precise, because conflating these two things is where teams get into real trouble.
Feeling productive is moving fast on a defined task. AI is extraordinarily good at helping you do this. Given a clear spec, a reasonable context, and a sane codebase, modern AI coding assistants will help you implement at a speed that would have seemed like science fiction three years ago.
Being productive is moving in the right direction. AI has no opinion on this. It will help you build a beautiful, well-tested, highly performant version of something nobody wants with exactly the same enthusiasm it brings to building something that matters.
The companies that are going to have a rough year are the ones that confused the first for the second. They shipped faster than ever, accumulated product surface area faster than ever, and now have a large, complex thing that doesn’t quite fit the problem. Rebuilding it is slow, because complexity doesn’t vibe code as well as greenfield does.
What the feedback loop was teaching you
Nobody talks about this much, but slow, manual, friction-filled development taught you things.
When you built something the hard way and it still didn’t work — not technically, but experientially — the cost of that failure was high enough that you paid attention to why. You developed intuitions about what kinds of things fail and why. You got better at pattern-matching bad ideas before they became expensive implementations.
Vibe coding short-circuits some of that education. When any idea can be prototyped in an afternoon, the feedback loop from “this seemed like a good idea” to “this was not a good idea” has to come from somewhere else — from user testing, from usage data, from someone looking at what you built and telling you it doesn’t work. Those signals still exist, but they require you to actively look for them. They don’t arise naturally from the resistance of the craft anymore.
This isn’t an argument against moving fast. It’s an argument for keeping your judgment engaged when you do.
What vibe coding is actually good for
To be clear: this is not a piece about slowing down.
AI-assisted development is an extraordinary tool for the people who know how to use it — and knowing how to use it means knowing what it’s for.
Use AI to execute on decisions that have already been made well. When you know what you’re building, who it’s for, and why it matters, AI is the fastest path from that clarity to working software. Let it rip.
Slow down at the decision layer. The question of what to build — which features to add, which flows to invest in, what the core experience should feel like — deserves human time proportional to its importance. The fact that implementation is cheap doesn’t make these decisions cheaper. It makes them more consequential, because the cost of acting on a bad decision has never been lower.
Treat rapid prototyping as hypothesis testing, not delivery. The best use of AI speed is to make your assumptions visible faster. Build the thing quickly, then examine it skeptically. Don’t ship it because it was fast to build. Ship it because you built it, looked at it hard, and it was right.
A simple diagnostic
If you’re not sure whether you’re in flow or in a productivity illusion, here’s a question that tends to cut through it:
Can you explain, in one or two sentences, what problem this feature solves for a specific person?
Not in the abstract. Not “it improves the user experience.” For a specific person, in a specific situation, with a specific before-and-after.
If the answer comes easily, you’re building with intent. If you have to reconstruct the reasoning — or if the honest answer is “it seemed like a natural extension of what we already had” — you might be experiencing what vibe coding at full speed, without judgment in the driver’s seat, tends to produce.
The code is fine. The thinking is the problem.
AI has shifted the locus of skill from implementation to judgment. Writing code was never the point — it was the medium. The point was always the problem being solved, the person being helped, the experience being created. AI just made the medium cheap enough that you can’t hide behind it anymore. The vibe is good. The flow is real. But somewhere upstream of the tab key, someone has to be asking whether this is the right thing to build at all. That part doesn’t tab-complete.