Six pushbacks I keep hearing on vibe coding

I keep getting pushback. Same six confusions, almost word for word, every time I post about vibe coding.

So here they are. With what I actually think when I hear them.

The short version

When I say vibe coding isn't a strategy, six pushbacks come back. Demos sell deals. We need speed. Real prototyping is too slow. Evals are overhead. Anyone can ship now. PMs are irrelevant. Each one has a kernel of truth and a tail of confusion. The kernel is real: AI tools changed what a small team can produce in a week. The confusion is everything else, mainly that output is the same as learning, that polish is the same as evidence, and that judgment got automated along with making. It didn't.

"But the demos help us close enterprise deals."

Sometimes they do. In rooms where the buyer is paying for hypothetical future capability and knows it, a polished demo earns the right to a longer conversation. Fine.

The catch is that the demos which close deals also become demos engineering has to deliver. If the prototype isn't shippable in real architecture, with real data flow, with cost economics that survive at scale, you've just sold debt. The team pays it back the next two quarters with delayed roadmaps, hot-fix theater, and an account exec who's confused about why the customer is angry.

I've been on both sides of that trade. Selling the dream is fast. Eating the dishes after the dream is slow.

My rule, if you're using a vibe-coded prototype in a sales motion: never demo something that isn't deliverable inside 90 days with the team you have. The polish has to be a forecast, not a fiction.

"We're moving fast. That's the whole point."

Speed is good. I have nothing against speed.

The problem is what counts as the unit. If the unit is "demos produced per week," AI tools made you faster. If the unit is "decisions made per week with real evidence behind them," AI tools didn't change that number unless you also changed the brief.

Move fast on the right loop. The loop is hypothesis, prototype, customer, decision. AI tools shrink the prototype step from two weeks to two days. They don't shrink the hypothesis step or the customer step. If you skip those because they didn't get faster, the loop stops being a loop and you're just churning artifacts.

This is what Instant Prototyping is meant to mean: shrink the build step radically, then spend the time you saved on the steps the tools didn't touch.

"Real prototyping is too slow when our competitors are vibe coding."

The teams I see winning aren't slower. They're prototyping ten or twelve times a quarter, and each prototype answers a real customer question. The teams I see losing are producing fifty demos a quarter and shipping whichever one got the most claps in the all-hands.

Volume of output isn't the moat. Quality of judgment is. The output of a vibe-coded sprint is fifty screenshots. The output of a prototyping sprint is fifteen decisions you can defend in a board meeting.

If your competitor is shipping fifty screenshots, congratulations, you have a competitor with worse decision quality and a hangover coming.

"Evals are overhead. A prototype doesn't need them."

An eval doesn't have to be a CI gate. For a prototype it can be one customer's reaction on a Loom recording. Three users completing a task with a stopwatch. A side-by-side comparison against last week's version of the same flow.

The point of the eval isn't compliance. The point is comparability. Without it you can't answer the only question that matters at the end of a prototype: was this better than what we had?

If a PM tells me they don't have time to write the eval question, I tell them they don't have time to build the prototype. Same time budget. Order matters. Assumption Testing covers what kinds of evals fit which kinds of prototypes.

"Designers and PMs can just ship the vibe-coded code now."

Some can, for very thin slices, behind a feature flag, with gates in front. Most can't, and the failure mode isn't new. We've always had teams that shipped code without observability, without error handling, without a rollback plan, and without anyone on call.

AI doesn't change the cost of operating bad code in production. It changes who wrote it. You still need someone whose job is to think about what happens when the model returns garbage at three in the morning, and that someone is usually not the PM who built the prototype.

I love that designers and PMs can build now. I love it less when "build" gets confused with "ship."

"AI is making PMs irrelevant. Vibe coding is the new PM role."

This one tends to come from a particular kind of executive who has never run a roadmap with consequences attached.

The PM job got rewritten, not deleted. The new job is harder. It requires you to write the hypothesis the model is about to spend compute on. It requires you to pick the customer who'll see the output. It requires you to know what "better" means before the prototype runs. None of those got easier with AI tools.

What got easier is making things. Making things was always the second-hardest part of product. The hardest part was deciding what to make. Tools that accelerate the second-hardest part don't relocate the hardest part. They just make it more obvious how few people in the room are doing it.

What I'm actually arguing

I'm not anti-vibe coding. I use Cursor every week. I've shipped Lovable prototypes my team learned more from than a six-week design sprint would have produced.

What I'm against is using the tool without the brief. The brief is the part that turns AI output into learning. Without it you have a fast machine producing slick artifacts that don't answer questions, and a culture that confuses the artifacts with the answers.

Pick one this week

If any of these six pushbacks is being pointed at you right now, here's the move.

Pick one feature you're about to brief Cursor, v0, or Lovable on. Before you open the tool, write three things on a sticky note:

1. The one-sentence hypothesis. What is this prototype supposed to teach you?
2. The name of the customer who'll see it inside seven days. Not a category, a real human.
3. The eval or interview question that decides whether the hypothesis was right.

Then build. From the outside the result will look exactly the same as a vibe-coded sprint. The difference is on the inside, in what you knew when you finished. That's the whole argument. The rest is decoration.

If you want to see how this rebuilds day-to-day product practice, the chapter on the impact loop is the next thing to read.