In February 2025, Andrej Karpathy coined a term that would send shivers down the spine of every documentation-obsessed product manager: “vibe coding.” His definition? You “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Instead of writing code line by line, you explain what you want and let AI generate the technical implementation.
Fast forward eighteen months, and that philosophy has migrated from a niche developer hack into the product management mainstream with a vengeance. Product managers are now using AI tools to generate interactive prototypes in hours instead of weeks, and they’re asking an uncomfortable question: if the prototype is the specification, why do we need 40 pages of behavioral requirements?
The Spec Sheet Is Shrinking
The shift is more than a workflow tweak, it’s a fundamental reorganization of what it means to communicate product intent. Traditional PRDs exist to bridge the gap between what product managers imagine and what engineers can build. They translate vague ideas into precise behavioral descriptions: exact states, edge cases, error conditions, permission matrices.
But here’s what happens when you can generate a working prototype in an afternoon: the prototype becomes the requirements document.
Consider the workflow shared by a product manager who asked how to turn PRDs and prototypes into Jira tickets using AI. The response was telling, and frankly, a little embarrassing. One commenter’s entire process?
Open up AI app. Attach PRD. Attach prototype. Type prompt: “create JIRA tickets for this feature.” Press enter.
That’s it. No elaborate MCP servers, no custom skills for ticket generation, no business analyst round-trips. The mechanical translation work that consumed days of PM time is now a single prompt.
Spec-Driven Development: The Grown-Up Version of Vibe Coding
The tools ecosystem has responded to this shift with remarkable speed. Tools like Kiro have formalized “spec-driven development”, which sits somewhere between pure vibe coding and traditional documentation rigor. The pitch is seductive: turn prompts into executable specs, validate code correctness with property-based tests, and catch bugs that unit tests miss.
One principal software engineer reported that in “just four lines into a spec”, Kiro was able to “write user stories like a product manager and capture so many details that I didn’t even need to mention, saving me several days of work.” Another software engineer claimed to move “from concept to working prototype in a single weekend.”
This is where the promise of vibe coding gets genuinely interesting: AI doesn’t just write code anymore. It writes the thinking that precedes the code. Requirements analysis, edge case identification, dependency mapping, all of this can be delegated to a model that processes your four-line spec and expands it into something resembling a comprehensive PRD.
But before you dance on the grave of your documentation templates, let’s talk about what this automation actually costs.
The Context Gap Problem
Here’s the dirty secret about AI-generated tickets that nobody puts in the marketing materials: models have no idea how your system actually works. As one frustrated developer noted, AI ticket generation “has so many context gaps it just invents things, adds nonsensical requirements because it doesn’t understand how a system operates or how it would fit into the bigger pie.”
This is the fundamental tension at the heart of the vibe coding revolution. The tooling works brilliantly when the task is self-contained, a standalone dashboard, a CRUD interface, a carbon counter app. The tooling collapses when you’re building on top of legacy infrastructure, when you’re managing state transitions across half a dozen microservices, or when data governance constraints shape what can and can’t be stored.
One product manager working on ERP systems captured the problem perfectly. The AI tooling makes the mechanical parts faster, they noted, but “the part that has not shrunk for me is the PRD itself. On deep domain workflows a prototype shows the happy path, but what costs engineering time sits behind it: permissions, state transitions, existing data that has to be migrated, records already in flight when the change ships.”
Translation: your prototype looks great. Your tickets read beautifully. And they’re wrong.
The Three Archetypes of This New World
It’s worth distinguishing between the different species of AI-enabled product managers emerging in this landscape:
- The AI Product PM integrates AI into user-facing products and focuses on UX/UI and customer value.
- The AI Platform PM manages the infrastructure, reliability, and scalability of AI models and services.
- The AI Powered PM uses AI tools for rapid prototyping, prompting, and speeding up product workflows.
That third archetype, the AI Powered PM, is the one most directly reshaping PRD practices. These are the PMs generating prototypes with Cursor, Replit, and Lovable, then feeding the results into spec-driven development pipelines.
The most interesting implication is that AI PMs are earning 15-20% more than traditional PMs in the US. The market is explicitly pricing in the value of technical fluency and rapid iteration capabilities. Being able to prototype your own ideas, evaluate their feasibility, and iterate without waiting for engineering isn’t just a nice-to-have anymore, it’s a premium skill.
The Evals Are the New Requirements
For AI-powered products specifically, the PRD is being replaced by something even more radical: evaluation suites. Instead of writing “the chat assistant should be friendly”, you define automated eval criteria that quantify what “friendly” means. Instead of acceptance criteria, you have property-based tests that verify invariants across thousands of inputs.
This is genuinely profound. Traditional PRDs describe behavior using natural language, which is ambiguous, contradictory, and impossible to verify. AI evals describe behavior using executable assertions, which are precise, testable, and automatically validated against every interaction.
Tools like Kiro’s spec-driven development are building this capability directly into the development workflow. Requirements are checked for contradictions before code is written, and property-based tests validate behavior across scenarios, not just happy-path examples.
The approach looks like this:
Requirement 1.2: All generated ticket IDs should be unique.
Property Test 3.2: For any sequence of parking operations,
all generated ticket IDs should be unique.
That’s not a PRD. That’s executable truth.
Avoiding the Doom Loop
The most common failure mode of vibe coding workflows isn’t technical, it’s conversational. The “vibe coding doom loop” occurs when AI gets stuck solving the same problem repeatedly, each “solution” introducing new bugs. It happens when prompts are too vague, when direction changes mid-stream, or when too many unrelated changes are requested at once.
The fix isn’t more documentation. It’s better context. Teams that start with clear, structured input, a four-line spec that defines the scope, the user, and the success criteria, get dramatically better output than teams that began with a vague “build me an app.”
The lesson here is that vibe coding doesn’t eliminate requirements thinking, it redistributes it. The thinking happens earlier, more concisely, and becomes executable. This is exactly the shift toward provable, rigor-focused coding that formal verification tools are bringing to the industry.
What Should Your PRD Actually Contain Now?
The smartest teams are converging on a hybrid approach. Don’t abandon the PRD entirely, abandon the parts that are now redundant.
Keep writing if it covers:
– Business context and goals
– Constraints and non-negotiables (permissions, data residency, performance SLAs)
– Migration and backward-compatibility requirements
– Known risks and open questions
Stop writing if the prototype captures it:
– Screen-by-screen behavior descriptions
– Happy-path user flows
– UI copy and interaction details
– Basic validation logic
The mechanical work of translating between documents and implementations is being automated away. The judgment work, deciding what to build, why it matters, and what could break, remains stubbornly human.
Some practitioners are already building their own quality gates into the workflow, encoding team standards as Claude skills or prompt templates. One PM described adding “critique skills” at the spec and ticket levels, essentially creating automated review processes that check AI-generated requirements against team standards. That’s a genuinely smart pattern: use one layer of AI to generate, another to critique, and humans to arbitrate.
The Bottom Line
Vibe coding projects succeed when they’re built around a narrow problem the builder understands deeply. The pattern from 30+ real-world vibe coding examples is consistent: the best projects pair a useful build with existing domain expertise and a clear path to users.
The same lesson applies to PRD practices. AI-generated prototypes are excellent at exploring the shape of a solution. They’re genuinely terrible at capturing the constraints that make software production-ready. The tooling gets dramatically better at handling context when your codebase is well-documented and your data is properly cataloged, the AI can only be as smart as the systems it can see.
Ten-line PRDs generated from a vibe-coded prototype might be the future for greenfield features and internal tools. But for anything touching money, security, or state, anything where “wrong” has real consequences, the deeper context still matters.
The real insight is that the PRD isn’t dying. It’s becoming executable. The teams that figure out how to represent their requirements as specs, evals, and property tests, while retaining the business and constraint context that models can’t infer, are going to run circles around everyone else.
The other teams will keep shipping prototypes that look great and break in production. Their tickets will read beautifully. They’ll just be wrong.
Want to dig deeper into how LLMs are reshaping the balance of power between junior and senior developers, or how executive AI usage is quietly becoming a security nightmare? The revolution is only getting more interesting.
