Prototypes Over PRDs: What Boris Cherny's Claude Code Team Taught Me About the Future of Building

The Moment I Knew the Game Had Changed

A few weeks ago, Boris Cherny — head of Claude Code at Anthropic — described how his team built Cowork, a full product designed for non-engineers, in roughly ten days. No PRD. No Figma mockups. No six-week roadmap ritual. Just working software, iterated at speed, with taste as the filter.

Boris ships 20–30 PRs a day running five parallel Claude instances. His PMs code. His data scientists code. His user researchers code. Everyone on the team carries the same title — "Member of Technical Staff" — and that's by design. According to Boris, productivity per engineer grew 70% even as Anthropic tripled in headcount. 90% of Claude Code's own codebase was written by Claude Code.

As someone who has spent over 13 years leading engineering teams, and who runs side projects as a part-time entrepreneur, I had to sit with this for a while. Not because it was surprising — I've been watching this wave build — but because of what it makes obvious about everything that comes next.

---

The Bottleneck Has Moved

For most of my career, the constraint was always build capacity. Could we hire fast enough? Could the team absorb the scope? Was the sprint loaded correctly? The entire machinery of modern product development — PRDs, sprint planning, Jira ceremonies, design handoffs — existed because building was expensive and slow, and you needed consensus before committing resources.

Boris said it plainly: "There's just no way we could have shipped this if we started with static mocks and Figma or if we started with a PRD." The old process would have spent more calendar time documenting Cowork than his team spent building it.

When a prototype takes 45 minutes instead of 6 weeks, the economics of exploration flip entirely. You don't need a document to authorize exploration. You need someone who can look at working software and say "this one, not that one" in real time.

The bottleneck has moved from "can we build it" to "should we ship it."

---

PRDs Aren't Dead — But They've Been Demoted

I want to be balanced here, because I've seen the other side. In large organizations with established products, understanding the hypothesis and defining success metrics is still critical. You can't prototype your way out of a misaligned business strategy. When you have compliance requirements, cross-team dependencies, and regulatory constraints, the discipline of a well-crafted PRD still matters.

But let's be honest about what most PRDs actually are in practice: permission slips. They exist less to clarify thinking and more to de-risk decision-making by committee. When I was managing teams of 15–20 engineers, I watched talented people spend weeks writing specs for features that could have been validated with a working prototype in a day.

The insight from Boris's team isn't that PRDs should disappear — it's that the PRD now comes after the prototype. You build the thing, evaluate it against real user interaction, and then document the "why" and the metrics. The order of operations has inverted.

---

Taste at Speed: The Real Skill

Carly Ayres wrote something in her essay "Taste at Speed" that I keep coming back to: slowness has been positioned as an antidote to slop, as if deliberateness and quality are the same thing. But speed isn't the opposite of craft. Slowness isn't inherently better.

She draws a distinction between two kinds of speed — the pace at which someone builds fluency through repetition, and the efficiency that comes after mastery. With AI, those two timelines have been decoupled. You can jump straight to the appearance of fluency without the underlying skill. Tools produce polish, but not perspective.

This is precisely the trap I see engineering leaders falling into. The question isn't whether your team can produce prototypes quickly. Of course they can — anyone with Claude Code or Cursor can generate working software in an afternoon. The question is whether anyone on the team can evaluate fifteen prototypes and pick the three worth shipping.

That evaluation skill — pattern matching across user research, technical feasibility, and business model simultaneously while staring at working software — is what separates teams that ship meaningfully from teams that just ship fast.

---

What This Means for Engineering Leaders

I manage engineers. I hire engineers. I coach engineers into senior and staff roles. Here's what I'm telling my teams now:

The coordination cost is evaporating. Boris's team eliminated the translation layer between spec and code by making everyone capable of building. When a PM can prototype their own idea, you skip the entire telephone game of requirements → design → handoff → build → review → "that's not what I meant." The 70% productivity gain Anthropic reports isn't just about AI writing code faster — it's about removing the human middleware.

"Member of Technical Staff" is the future title. The hard boundary between PM, designer, and engineer is dissolving. Not because specialization doesn't matter, but because the cost of being a generalist who can build has dropped to near zero. On my side projects, I'm already operating this way — I'm the PM, the designer, and the engineer, with Claude as my force multiplier. Larger teams will follow the same pattern.

Your value is in the kill rate. The PMs and engineering leaders who thrive will be the ones reviewing prototypes at 9am, killing 80% of them by noon, and shipping the survivors by end of week. If you can't make fast, confident decisions about working software, you're the bottleneck — not the build pipeline.

---

The Jazz Ensemble Problem

Think about what separates a great jazz musician from someone who can play the notes. A beginner can learn the scales, memorize the chord changes to So What, and play a technically correct solo. But the musician who spent years in smoky clubs, who played a thousand bad solos before landing a great one, who absorbed Miles and Coltrane and Monk through sheer repetition — that person hears differently. They know when to play and, more importantly, when to leave space. They've internalized the vocabulary so deeply that taste and execution become the same act.

AI is like handing everyone a perfect session band and a studio with infinite recording time. You can lay down take after take, and every one will sound polished. But as Carly Ayres warns, when the first take already sounds finished, there's no obvious reason to keep pushing. You miss the accidents and the failures that build genuine musical instinct. "Slow built your instincts. Fast lets you use them. But you still have to know what you're reaching for."

The best producer in the room isn't the one who plays every instrument — it's the one who listens to forty takes and knows which three bars from take seventeen belong in the final cut. That's the job now. As an engineering leader, I'm less the person ensuring we build correctly and more the person ensuring we choose correctly. Less session musician, more producer.

---

The Uncomfortable Truth

Here's what I think the next 18 months look like: every fast-moving team will operate the way Boris's team operates today. The PMs who struggle will be the ones still writing 15-page specs for features that could be prototyped, tested, and validated before the document hits its first review cycle.

And the engineering managers who struggle will be the ones still optimizing for throughput when the real constraint is judgment.

The future belongs to people who can hear the music — and to the leaders who know which take to ship.

---

References

• Boris Cherny on Lenny's Podcast: Head of Claude Code: What Happens After Coding is Solved
• Boris Cherny on The Pragmatic Engineer: Building Claude Code with Boris Cherny
• Carly Ayres: Taste at Speed — Good Graf! Substack