Vibe coding belongs upstream of the PRD.Copy link

"No PRDs on the Claude Code team".

That line, from Boris Cherny, who runs the Claude Code team at Anthropic, has been doing the rounds on every podcast and Substack I've opened for the last fortnight. He's also on record saying half his ideas are bad and you just have to try stuff, give it to users, see what sticks. Anthropic's other big proof point this year was Claude Cowork, the non-technical sibling to Claude Code, built in about ten days, no PRDs, no Figma, livestreamed at launch. The discourse has named the thing too. Vibe coding. The argument: requirements documents are dead weight, the prototype is the spec, ship it and let users tell you what's wrong.

Boris is right about a specific thing. Prototyping is the cheapest way to find out what an idea actually wants to be. Ten days of working code, in the hands of real users, will out-learn six weeks of a Confluence page every time. I run my own work this way. I've used Claude Code every day for just over a year and I've watched it collapse the cost of discovery to something that would have looked like magic in 2022.

The line stops being right at the moment the prototype gets called the product.

Discovery is not deliveryCopy link

A prototype is a discovery artefact. It exists to surface what you didn't know you needed to ask. What does this feature look like in someone's hands? Where does the model the user has in their head diverge from the model I have in mine? What was I sure about that the prototype just disproved? Those answers are gold. They're also the entire job of the prototype. Once you have them, you're done with the artefact, and you carry the learnings forward into something that's actually built to ship.

Prototyping is one phase. Delivery is another phase. Both are necessary. They are not the same activity, and they don't produce the same kind of artefact. The structural mistake is collapsing the two and assuming the output of the first is fit for the purpose of the second.

I tried Claude Cowork on launch day. It was buggy. Not in a way that embarrasses the team, who shipped it as exactly what it was. Buggy in the way a ten-day prototype is buggy. Edges left rough, edge cases ignored, the system working brilliantly on the path the demo walked and falling over the moment you stepped off it. Anthropic could ship that and the audience for the experiment understood the deal. Now picture the same posture on a REST API behind a financial document workflow. Or an ecommerce checkout. Or a multi-user CRUD app holding customer data. None of that is exotic software. All of it gets audited eventually, by a regulator, by a PE buyer at exit, by a client's security team during procurement, by someone. "We'll iterate" is not a posture that survives that conversation.

What happens when the prototype IS the specCopy link

Without a separate specification, acceptance criteria don't exist. The audit trail starts at the moment the model guessed. Edge cases are whatever the training data leaned on. Schema, error paths, observability, the bits a prototype skips for good reasons, all silently become part of the production design because nobody wrote down what they should have been. I've covered the categories before and won't relist them. What matters is who made those decisions, and whether the trail survives review. If the decision-maker is an agent inferring from a vague prompt, the bank does not get to audit the inference.

People keep telling me audit is bureaucracy. Or extra process. It's neither. Audit is the ability to answer "why does this system behave this way" in an environment where someone is eventually going to ask. If the answer is "an agent inferred it from a vague prompt during a ten-day prototype sprint and we never went back and wrote it down properly", the answer fails. Not because the regulator is picky, but because the team doesn't know either.

The teams I work with at tier-1 investment banks already know this. They aren't asking whether AI can write code. They're asking what governs the code AI writes, and how they prove it. PRD-less doesn't survive that question. It isn't supposed to.

The phase modelCopy link

The work has a sequence. Prototype, then learnings, then requirements, then acceptance criteria, then engineering. Each step takes the output of the previous one and translates it into something the next step can use. The prototype is the cheapest way to learn what to specify. The PRD is the cheapest way to hold the specification stable while the build happens. The acceptance criteria are the cheapest way to know when the build matches the spec.

Skip any of those steps and you don't save the cost of doing them. You move it later in the project, where it costs more. The prototype that became the spec turns into the production bug that becomes the customer call that becomes the post-mortem that becomes the new requirements document everyone wishes had been written six months ago.

The prototype is a forerunner to the PRD. Treat it as a substitute and you've conflated discovery with delivery.

Where vibe coding fitsCopy link

Throwaway work is the right home for vibe coding. Weekend projects. Internal tools nobody audits. Prototypes you intend to discard once you've extracted the learnings. The thing about an artefact you're going to throw away is that nothing about it has to scale, hold up, or be defensible six months from now. Vibe-code it, learn from it, bin it.

Durable software has a different bar. The phrase that keeps doing the work for me is "what will this system be asked to prove in three years?" If the answer is nothing, vibe coding is fine. If the answer is anything, somebody has to be able to point at the requirements, the acceptance criteria, and the test that verified the behaviour, and explain how they connect. That isn't bureaucracy. That's the engineering.

The reader probably already knows which category their work falls into. The mistake I see most often is teams that know the category, then take the prototype and try to harden it into the durable thing. It rarely works. The artefact wasn't built to support that load. The team would have been better off using the prototype as a discovery artefact, writing the spec from what they learned, and building the durable version properly.

The quiet bitCopy link

The AI vendors selling the prototype-as-product model are not neutral parties. None of them makes ROI today. They are priced for a land grab that won't hold, and one thing that accelerates a land grab is engineers building and discarding prototypes by the dozen, because every prototype burns tokens. Uber reportedly burned through its 2026 AI budget in four months. Anthropic reportedly spends more on AWS than it makes in revenue. Token spend is a board-level line item now. Worth holding in mind when you read the next piece about how the PRD is dead. Follow the money.

Where this landsCopy link

Prototypes belong upstream of the PRD, not instead of it. The prototype is the cheapest way to find out what you don't know yet. The PRD is the cheapest way to hold the answer steady while you build. Both jobs are real. Collapsing them looks like speed and behaves like debt.

That's the line RCF draws. Prototyping is welcome in the discovery phase, where it earns its keep. The handover happens when the learnings get written down properly and the build phase begins. More on how that handover works at stravica.ai/rcf-methodology.