All posts

February 25, 2026

What Happens When You Vibe Code Without a PRD

Vibe coding is fast until it isn't. The point where it breaks is almost always the same: no specification, no shared model of what you're building, and an AI that's been improvising from the start.

The vibe coding discourse has a predictable shape. Somebody builds something impressive in an afternoon. They post about it. The comments split between "this is the future" and "wait until you try to add a second feature." Both sides are right, and they're talking about different moments in the same project.

The first afternoon is real. Vibe coding tools — Lovable, Bolt, Replit, Cursor, v0 — are genuinely fast for the first 60–70% of most standard products. Auth, CRUD, dashboards, forms, API integrations: a focused session can produce a working prototype of a recognisable SaaS application in hours. This is not a trick. It works.

The second afternoon is also real. And the third. The point at which the project stops feeling fast and starts feeling like archaeology — digging through AI-generated code to understand why changing one thing broke something else — arrives with surprising consistency, regardless of the tool.

The reason is almost always the same. There was no PRD.

What "no PRD" actually means in practice

Nobody sits down to vibe code and thinks "I've decided not to write a PRD." It's not a decision. It's an omission — the natural result of a workflow that makes generation so fast that specifying feels unnecessary.

You open the tool. You describe what you want. Something appears. It's close enough. You refine it. Something else appears. You keep going.

At no point does the AI ask: what is this product for? Who uses it? What are the three core flows? What happens when the user does something unexpected? What does the empty state look like? What are the constraints? The AI doesn't ask because it doesn't need that information to generate the next screen. It only needs to know what you want right now.

This is the problem. "Right now" and "the whole product" are different things. The AI is optimising locally — generating a plausible response to the current prompt — while you are trying to build something with global coherence. Those two things are compatible when the product is simple. They diverge as soon as it gets complex.

The threads

This isn't theoretical. The pattern shows up constantly in public discussion — often from people who started enthusiastic and hit the same wall.

A post that circulates regularly on Hacker News describes it this way: you build the happy path first. It works. You add an edge case. The AI implements it, but the implementation makes an assumption that breaks the original flow. You fix the original flow. The fix introduces a new edge case. You are now in a loop where every session produces new surface area and resolves none of the underlying inconsistency. The project is getting larger without getting more complete.

The "last 30% problem" is the vibe coding community's name for this. The first 70% is fast because it's additive — you're building new things. The last 30% is slow because it's integrative — you're making things work together, which requires understanding the whole, which nobody wrote down.

What makes it worse is that the AI doesn't signal when it's lost. It continues generating confidently. It produces code that compiles, interfaces that render, flows that mostly work. The degradation is subtle: a constraint that was established in session one gets quietly violated in session four. An assumption that made sense for one flow creates an inconsistency in another. The product accumulates technical and logical debt invisibly, expressed as bugs and weird behaviour that feel unconnected but share a root cause: the AI improvised, and the improvisations don't add up.

The giga-prompt as symptom

The developer community's response to this has been instructive. Rather than slow down and write a spec, many experienced vibe coders have started writing what they call "giga-prompts" — massive context files (CLAUDE.md, AGENTS.md, .cursorrules) that front-load the product context the AI needs to make consistent decisions.

These files run to hundreds or thousands of lines. They document architectural decisions, naming conventions, constraint lists, user journey summaries, resolved edge cases. The goal is to reconstruct, manually, the product model the AI should have had from the start.

This is a workaround, not a solution. The giga-prompt works for the current session. It degrades as the product evolves and the file goes out of date. It requires technical fluency to write and maintain — a PM or designer can't own it. It has to be manually updated every time anything changes. And it still doesn't give the AI genuine product understanding; it gives it a summary of decisions already made, which is useful but not the same as a model of why those decisions were made and what other decisions they constrain.

The giga-prompt exists because people noticed the absence of the spec and tried to reconstruct it after the fact. It's the right instinct in the wrong direction.

What a PRD gives the AI that a prompt doesn't

A PRD is not a longer prompt. It's a different kind of artifact.

A prompt tells the AI what to do next. A PRD tells the AI what the product is — its purpose, its users, its flows, its constraints, its edge cases — persistently, as a foundation that all individual prompts are expressed against.

The difference shows up in cross-flow reasoning. If a user completes onboarding in state A, they should see a different empty state than a user who lands in state B. If a user has a free account, certain actions should be disabled with an upgrade prompt. These dependencies span screens and sessions. An AI reasoning from the current prompt has no model of them. An AI reasoning from a PRD does — because the PRD defines the relationships between states, flows, and user types before any of them are built.

It also shows up in what the AI notices. Without a spec, the AI has no basis for flagging when a requested change would break a constraint established earlier. With a spec, a well-implemented generation pipeline can recognise that "add a share button here" contradicts the privacy model defined in the PRD and flag the conflict before building it in.

This is the difference between an AI that executes instructions and an AI that understands what it's building. The spec is what creates the latter.

The pattern in public discourse

What's striking about the vibe coding discussion in 2025–2026 is how consistent the failure mode is across tools, languages, and project types. The complaints that circulate on Reddit, in build-in-public threads, and in "I tried vibe coding for 30 days" posts share a common structure:

  • Starts fast, impressive first results
  • Hits a wall around the 60–70% mark
  • The wall is not a technical limitation of the AI — it's a coherence problem
  • Fixing one thing breaks another, repeatedly
  • The project either gets abandoned or requires a significant rewrite from a human who actually understands the whole

The rewrite is the tell. When the AI-built product requires a human to sit down and understand it as a whole before it can progress further, what that human is doing is reconstructing the spec that should have existed from the start. They are reading the code, inferring the intent, and writing down the model of the product that was never written.

This is expensive. It's expensive in time, in motivation, and in the trust of anyone who was relying on the project to ship. It is also entirely avoidable.

The spec as a precondition, not an overhead

The argument against PRDs in a fast-moving vibe coding workflow is that they slow you down upfront. This is true in the same way that measuring twice slows you down before you cut. The question is what it costs to cut wrong.

For a simple project — a landing page, a utility tool, a personal side project — spec-less vibe coding is often fine. The coherence requirement is low, the surface area is small, the cost of rework is manageable.

For anything with multiple user types, multiple flows, meaningful state management, or the expectation that other people will use it: the spec is not overhead. It is the precondition for the AI doing useful work beyond the first session. Without it, every session is partial; together, the sessions don't add up.

The irony is that vibe coding tools are fast enough that the cost of this failure is often paid early. You build quickly, hit the wall quickly, and then face the choice of reworking quickly or abandoning quickly. The PRD, written upfront, converts that rework cost into design time — which is cheaper, faster, and produces something you can share and validate before writing a line of code.

The tools that will pull ahead in the vibe coding space are the ones that make the spec the starting point rather than the afterthought — not because specs are virtuous, but because they are what make the AI's speed durable rather than momentary.

We wrote more about why spec-driven development is the future of AI-assisted building — and how Mowgli keeps the spec in sync automatically — in this post.

Sources