Not a PRD, Not a Plan, But a Secret Third Thing

The AI product tooling space has split into two camps. Neither is solving the actual problem. Camp 1: PRD Generators Tools that take your rough idea and produce a polished Product Requirements Document. Features, user stories, acceptance criteria. Formatted for Confluence. Designed for stakeholders to read and approve. What they actually do: Bring constraints at human speed—meeting speed, review cycle speed, organizational alignment speed. PRDs emerged from a world where the bottleneck was building. When development took months, you could afford weeks of requirements gathering. The constraint velocity matched the build velocity. In the vibecoding era? You can spin up an MVP in a weekend. PRD generators are bringing a knife to a gunfight. Camp 2: AI Coder Plans Cursor's plan mode. Claude's implementation outlines. Step-by-step breakdowns of how to build something. What they actually do: Assume the product decisions are already made. Zero constraints—just execution. These tools are phenomenal at "implement authentication with JWT tokens." They're useless at "should I even build authentication, or is social login enough for my MVP?" AI coder plans solve an implementation problem. They don't provide constraints. They don't challenge assumptions. They don't tell you when you're building the wrong thing. The Problem Nobody's Naming Here's the failure mode that's killing vibecoded projects: Build velocity now exceeds constraint velocity. Before vibecoding, constraints entered projects through:

• Tribal knowledge at your company ("we only ship to US buyers")
• PM traffic-copping ("we can't do that because of X")
• Customer meetings ("actually, we need Y instead")
• MVP methodology (fail fast = learn constraints fast) All of these operate at human speed. Meeting speed. Calendar speed. Vibecoding operates at AI speed. You can build in an afternoon what used to take a sprint. But your customers can't give you feedback every afternoon. Your PM can't review every afternoon. Your market research doesn't update every afternoon. The result: you ship faster than you learn. The AI makes reasonable assumptions. Those assumptions work in isolation. But they don't agree with each other over time. Your product accumulates coherence debt—decisions that made sense locally but conflict globally. What's Actually Missing PRD generators produce constraints at human speed. AI coder plans produce no constraints at all. What we need: constraints at AI speed. Not arbitrary friction. Not "slow down." But the right constraints, surfaced at the right moment—constraints that come from your accumulated context, not generic best practices. This is why the solution isn't another document format. It's a different architecture entirely. The Secret Third Thing PRDs are documents. Plans are instructions. Neither has memory. Neither learns. Neither accumulates. The secret third thing is a context graph—a persistent structure that captures your product decisions, user learnings, validated assumptions, and rejected paths. Nodes and edges, not paragraphs and bullet points. When you ask "should I build this feature?", the system doesn't start from zero. It knows:
• Which personas you've validated and what they care about
• Which assumptions you've already tested (and which failed)
• What constraints emerged from past pre-mortems
• What patterns keep appearing across your products This isn't a document you read. It's a system that remembers—and surfaces relevant constraints exactly when you need them. Vibeharshing at the Speed of Vibes We need a word for this: vibeharshing. Not killing the vibe. Not stopping vibecoding. But bringing product constraints at the speed vibecoding demands. Matching constraint velocity to build velocity. Code review tools like Greptile and Coderabbit provide constraints on how you build—code quality, security, best practices. Important, but not sufficient. Vibeharshing provides constraints on what you build—product judgment, user needs, market reality. The stuff that determines whether your beautifully-coded feature matters at all. The context graph is what makes vibeharshing possible. Without memory, every constraint check starts from zero. With a graph, constraints compound. Your second project benefits from your first. Your tenth feature benefits from your first nine. The New Stack Here's what modern product development looks like:

1. Ideation → Your brain, caffeinated, 2am
2. Vibeharshing → Context graph surfaces relevant constraints
3. Planning → AI coder's plan mode
4. Implementation → AI coder's agent mode
5. Learning → Back to the graph—capture what you learned PRD generators slot into traditional processes between steps 1 and 3. But for vibecoding, that slot doesn't exist. You go from idea to code in minutes. What you need is constraints that arrive at the speed of thought. Before you tell Cursor "build this," you need to know if "this" is worth building—informed by everything you've already learned. That's the secret third thing. Not a document. Not a plan. A context graph that harshes your vibe at the speed your vibe requires.

Ready to harsh the vibe? Try Cutline's pre-mortem and stress-test your next idea before you write a line of code.