Vibe coding made building faster. It made prioritization existential.

In February, a thread hit the top of Hacker News asking whether vibe coding would plateau the way the maker movement did. 405 points, 440 comments. Founders, PMs, and engineers trading takes for days.

The thread never landed on a clean answer — but buried in the noise was something worth pulling out.

One commenter said it plainly: "The real parallel might be the early web era where anyone could make a website but finding them required Yahoo directories... right now vibe coded apps have the same discovery problem — they exist but there's no effective way to find or evaluate them."

That's the access problem. But there's a deeper one. And nobody named it directly.

The maker movement didn't die from bad soldering irons

The thread kept circling back to the same false diagnosis: the maker movement faded because the tools weren't good enough, the promises were too big, and the hype outran the hardware.

But one commenter got closer to the truth: "The limiting factor has always been the brain power designing the thing. YouTube is littered with videos of someone wanting to build a 'thing' and then spending 10–20 iterations figuring out everything they didn't know going into the project."

The soldering irons were fine. The 3D printers got cheaper every year. What didn't improve was the answer to a harder question: what should I actually build with this?

The tools enabled. The judgment lagged. The movement stalled.

Vibe coding has the same problem, one speed grade faster

Here's what's different this time: the gap between "I can build anything" and "I know what to build" closes in an afternoon instead of a year.

A solo founder in the HN thread described replacing a $250K/year enterprise software platform in two weeks using AI-assisted development. No engineering team. No sprint planning. Just Claude and a clear idea of what the business actually needed.

That's not a productivity story. That's a prioritization story.

He knew exactly what to build — the core functionality his CRM integration required — before he wrote a single prompt. The vibe coding was downstream of the product judgment. Without that judgment, he would have shipped the wrong thing very, very fast.

Another commenter named it from the other direction: "After all of this is shown not to be saving money, or creating much value because they're doing too much without market validation, then a more intelligent approach will occur and less vibe coding will occur."

The feature backlog compresses. The prioritization question does not.

When you can ship anything in a day, "what to build" is the only competitive question left

Pre-AI, the cost of building something wrong was brutal. Months of engineering time. A burned sprint. A bloated roadmap. The friction of implementation was a forcing function — you thought harder before you built because building was expensive.

That forcing function is gone.

When shipping takes hours, the only constraint left is your judgment about what's worth building. And judgment — real product judgment, grounded in user insight, business model, and ruthless prioritization — is not something Claude can generate for you.

One commenter put it bluntly: "People who can actually build great systems know that it requires careful planning, deep understanding, and ability to fill in the gaps." He was talking about AI-assisted development, but he was describing product management.

The thread's underlying consensus — unstated but everywhere — was this: the tools are fine. The problem is knowing what to build.

The new stack: AI builds it, you decide what gets built

Here's the structural shift that most vibe coding discourse misses.

The maker movement's value hierarchy looked like this:

Idea → Build → Ship → Learn

The constraint was Build. Everything upstream felt easy by comparison.

The vibe coding era flips it:

Idea → [AI builds] → Ship → ???

Build is now nearly free. Which means the weight of competitive advantage collapses entirely onto Idea. And not just "idea" in the startup pitch sense — but the ongoing, disciplined work of deciding which features to prioritize, which problems are worth solving, which users you're actually building for.

That's product management. And it's never been more load-bearing.

This is why "what to build with vibe coding" is the wrong question

Founders and PMs searching for "what to build with vibe coding" are looking for inspiration. That's not the problem. There's no shortage of things to build.

The problem is that when you can build anything, you will build everything — and most of it will be wrong.

The maker movement created a graveyard of $250 3D printers gathering dust in spare bedrooms. Not because people couldn't print things. Because they ran out of things worth printing.

Vibe coding is setting up the same graveyard at a startup scale. Dozens of features shipped in days. None of them validated. None of them stack-ranked against each other. None of them connected to a coherent product thesis.

Speed without structure isn't a superpower. It's a way to reach the wrong destination faster.

The missing layer

The HN thread had 440 comments and nobody mentioned structured prioritization once. Not once.

That's the gap.

AI coding tools give you the execution layer. Claude, Cursor, Codex — they'll implement whatever you put in front of them. What they can't give you is the upstream work: defining what actually matters, forcing trade-offs, writing specs that constrain scope, ranking features against business outcomes.

That work — deciding what's worth building before anything gets built — is exactly what most vibe coders skip. It's also exactly what separates the founders who ship products from the ones who ship features.

The maker movement didn't fail because makers couldn't solder. It failed because they couldn't figure out what people actually wanted.

Vibe coding won't fail because the tools aren't good enough. It'll fail — or plateau, or bifurcate into winners and a graveyard — because most builders will skip the prioritization layer entirely.

The ones who don't skip it will win.

StackRanked is built for the moment before the first prompt. Stack-ranked prioritization, spec writing, market analysis, and AI context for product decisions — structured thinking before any code gets written. Start for free →