The Vibe Coding Hangover Is a Prioritization Problem, Not a Code Quality Problem

Two threads are dominating the vibe coding backlash conversation right now. One is a Hacker News submission titled "After two years of vibecoding, I'm back to writing by hand" — 865 points, 634 comments. The other is fast.ai's "Breaking the spell of vibe coding" — 434 points, 348 comments. Combined: nearly 1,300 upvotes and almost a thousand comments from engineers, founders, and technical PMs who tried vibe coding, went all in, and are now reckoning with the fallout.

Both threads are worth reading. Both threads are also diagnosing the wrong disease.

The dominant frame in both is this: vibe coding produces bad code. AI-generated code lacks understanding. The LLM doesn't know what neighboring patterns exist, can't maintain architectural coherence across a codebase, generates slop that looks plausible on first read but falls apart at scale. That's all true. The technical critique is valid.

But it's the secondary problem.

The primary problem — the one buried in the comments, the one almost nobody names directly — is that vibe coding removed the friction that used to gate bad product decisions.

What friction was actually doing

Before you could build anything, you had to write code. Writing code is slow. It's expensive. It forces a certain level of commitment to the idea you're implementing. That friction — annoying as it was — served as a natural filter. You couldn't afford to build every feature someone asked for. You couldn't ship the third iteration of a dashboard nobody was using. The cost of building created pressure to prioritize.

Vibe coding collapsed that cost. The question "can we build this?" went from weeks to hours. From hours to minutes. From minutes to a single prompt.

That sounds like a win. It isn't — not without a prioritization layer to replace what friction was doing.

When the cost of building anything approaches zero, the question isn't can we build this. The question is what is worth building. And most teams never got around to asking that question. They were too busy building.

The actual hangover

Read the thread comments carefully. Buried in the technical complaints about "slop" and "architectural decay" is a pattern that nobody is calling by its right name.

One commenter describes a founder who "vibe coded an entire product over three months. Filled with features no one uses, feeling very good about everything he built." Another talks about a team that built "three apps in a week" before sleeping problems set in — not because of bugs, but because of the non-stop velocity with no stopping point, no decision gate, no moment to ask whether any of it needed to exist.

The fast.ai piece quotes a developer who captured it almost perfectly: "I would end up in a loop where I would keep asking AI to 'fix' things I didn't actually understand." The code was the symptom. The loop was the problem. The loop exists because there was no clear definition of what "done" or "right" looked like before a single line was written.

This is a product management failure, not a software engineering failure.

The thing everyone keeps almost saying

Here's the sentence that doesn't appear in either thread, but is implied by dozens of comments:

When building becomes frictionless, prioritization becomes the only discipline that matters.

A team that can build anything in a day is not a more powerful team. It's a more dangerous team, unless it has a rigorous answer to: what should we build and why, ranked by evidence and impact.

Without that, you don't get a slightly messier codebase. You get a pile of features nobody asked for, built at 10x speed, each one technically functional, collectively pointing in twelve different directions.

One commenter in the HN thread put it this way: "I've lost the mental model of most projects." That's not an AI problem. That's what happens when you build without a spec, without stack-ranked priorities, without a forcing function that requires you to write down what you're building and who it's for before you start.

The friction vibe coding removed was not all useless friction

There's a distinction worth making here between two kinds of friction in the software development process:

Accidental friction — the slowness of writing boilerplate, the time spent looking up syntax, the overhead of translating a clear idea into correctly-formatted code. This friction is useless. Removing it is pure gain.

Essential friction — the commitment required to actually ship something, which forced teams to decide whether it was worth building before committing weeks of engineering time. This friction was doing work. It was badly placed — downstream, during implementation, rather than upstream, at the decision point — but it was doing something.

Vibe coding eliminated both kinds at once. The engineering community is mostly complaining about what happened to code quality when the accidental friction disappeared. They're missing that product quality degrades even faster when the essential friction disappears too.

The right response is not to restore friction in the build phase. It's to move that essential friction to where it should have always been: the prioritization stage. Before any code is written, AI-assisted or otherwise, someone needs to write the spec, stack-rank the work against alternatives, and make the case that this is the highest-value thing to build right now.

What this means for how you build

The teams that are going to win in a world where building is cheap are not the ones that build faster. They're the ones that make better decisions about what to build.

That means structured thinking before any code gets written:

• A spec that defines the problem, the user, and the success criteria
• A stack-ranked list of what to build next, with the reasoning documented
• A prioritization framework that accounts for impact, effort, and strategic fit — not just what's technically interesting or what someone asked for last
• A decision record that forces you to explain why you chose this over the alternatives

None of this is new. PMs have been arguing for this discipline for decades. What's new is the stakes. When a team could only ship a handful of features per sprint, bad prioritization decisions were recoverable. When a team can ship twenty features a week with AI assistance, bad prioritization decisions compound at a rate that can bury a product inside a quarter.

The question buried in both threads

Here's the question nobody in either thread asked directly, but that every comment is circling around:

How do you decide what is worth building when the cost of building anything approaches zero?

That's not a code quality question. It's not a software engineering question. It's a product management question. It's the central product management question of the AI-native era.

The answer is not "be more careful with your prompts" or "review every line of AI-generated code." Those are technical mitigations for a product strategy failure.

The answer is structured thinking before building. It's the discipline to write a spec before you write a prompt. It's a prioritization layer that forces you to defend why this feature, why now, why for this user, ranked against everything else you could be building.

The tools you need have changed. The thinking hasn't.

Vibe coding is not the problem. The lack of prioritization infrastructure is the problem. The two things that collapsed together — building speed and prioritization discipline — need to be decoupled. You keep the fast building. You restore the thinking.

StackRanked is built for exactly this problem. It exists for teams that want to move fast with AI-native tools without losing the structured product thinking that keeps velocity pointed in the right direction. Stack-ranked priorities. Spec writing with intent. Decision records that don't disappear when someone ships the feature.

The vibe coding hangover has a cure. It's not writing code by hand again. It's deciding what to build before you build it.