Reddit's Handoff Ships a Draft PR. Design Should Hand Engineering the Tests.

Reddit's prototyping harness hands engineering a draft PR. Blair Metcalf's words on what happens to it: "that'll get reviewed and may or may not go through."

Metcalf, Reddit's principal UX engineer, showed Reddit Proto on Claire Vo's How I AI on October 26. The show notes give the numbers: 100% adoption across Reddit's UX and product org, and more than 700 prototypes live on it. The handoff is what Metcalf calls a feature capsule. A Figma frame goes through Reddit's custom design-system MCP, out comes a generated PRD with a user goal and acceptance criteria, Cursor writes production-shaped code in a sibling repo, and a draft PR goes up.

On Monday I argued with Reddit's dashboard in The Column It Needs Is Shipped. This part is about the capsule itself. It's the best handoff I've seen this year and it's still built around the artifact. A more expensive artifact. Code instead of a mockup.

Three days before the episode, Maria Rosala and Rachel Banawa at Nielsen Norman Group published a survey of 521 UX practitioners. One respondent: "I now sometimes find myself trying to quickly fix completely unusable prototypes made by a product manager." The authors' line is the one I'd hand every engineering lead: "A task made faster for one person can create work for another."

So, part 3 of The Design Transition. Part 1 said design's job moved from the screen to the spec. Part 2 split the spec between the PM and design. This one is the other neighbor. When the prototype is production-shaped, what does design actually hand engineering?

The short version

When a designer's prototype arrives as production-shaped code, the handoff can't be the code and it can't be a mockup. It's the behavior spec turned into tests engineering can run. Reddit's feature capsule, as Blair Metcalf described it on How I AI on October 26, 2026, hands over a generated PRD and a draft PR that "may or may not go through," and Nielsen Norman Group's survey of 521 practitioners the same week found that work made faster for one person lands on another. My package has four parts, one per section of the behavior spec: never-do lines become hard-fail rows that block a merge on one failure, the acceptable range becomes graded rows with a real example at the floor, the wrong path becomes fixtures for refusal, low confidence, and recovery, and the rubric becomes the grader. Keep or rebuild the prototype code per layer, not per prototype: keep what came from the design system, rebuild the logic. Engineering owes three things back: a harness that runs design's rows on every change, a regression report that names the row, and the rows it can't pass inside budget, returned as a decision.

Production-shaped is the trap

A mockup was honest about what it was. Nobody shipped a Figma frame by accident. Everybody knew engineering would rebuild it, so the real handoff happened in the conversation around it: the redlines, the edge cases, the "what happens when."

Production-shaped code skips that conversation. It runs. It looks like the product because it's built from the product's own components. And it carries every choice the model made along the way, in a form engineering reads as decided. Part 2 called those choices the third column, made by the model and chosen by nobody. A generated PRD wrapped around them doesn't fix it. That was Ravi Mehta's whole finding in part 2: the AI wrote twenty pages of decisions nobody had made.

Uditi Sharma names the rest of the risk in her post on October 11. A prototype that looks finished "can anchor everyone on the PM's design choices." Then designers "spend their time undoing decisions instead of making them." Swap engineers in for designers and it holds just as well.

On keep or rebuild, Uditi lays out both camps. Some teams grow prototype code into the product. Many engineering teams rebuild, because prototype code skips security, tests, and structure. Her conclusion is that the answer probably depends on the risk of the product.

I'd make it more specific. Decide per layer, not per prototype.

The layer that came out of the design system mapping, the components and tokens Reddit's MCP translates into production code, was production code before the prototype started. Keep it. Everything else gets rebuilt: the logic, the data handling, and anything the prompt decides. The model made most of those choices in an afternoon, and they were good enough for a demo. The prototype goes along as a reference. It's never the source.

What goes in the package

Part 1 gave the behavior spec four sections: what the surface must never do, the acceptable range from best case to floor, the rubric, and the wrong path. The handoff is those four sections, rewritten so a machine can check them. A behavior spec written for humans to read stays in a doc. Written as rows, it ships with every build.

Never-do lines become hard-fail rows. One row per line, each with a real input that tries to make the system do the thing. A single failure blocks the merge. No averaging, no "mostly passes." If the surface must never invent a price, there's a row where the user asks for one that isn't in the data.

The acceptable range becomes graded rows. This is where you cannot mock a distribution turns practical. The range needs real examples at the floor as well as the best case, because the floor is what engineering will actually hit on a bad day. The floor example settles more arguments than any adjective in the spec.

The wrong path becomes fixtures. Refusal, low confidence, timeouts, the third retry, the user who corrects the system. These are the states a mockup never drew and a demo never hits. Designing Refusal is the chapter on why they get judged fastest. Each one gets a fixture engineering can trigger on purpose.

The rubric becomes the grader. The Rubric Is the Spec already says how to write it. In the handoff it stops being a review aid and becomes the thing that scores the rows. My sizes are the ones from Kill the PRD: three to five criteria, at least twenty test cases, binary per dimension.

Plus one page that isn't a test: the ratified ledger from part 2, so engineering knows which choices in the prototype someone made on purpose.

Uditi has a kickoff rule I'd keep exactly as she wrote it: "Engineers see the intended behaviour, including the prompt and failure states, before estimating." The rows are how they see it. An estimate made against a prototype is an estimate for the happy path.

What engineering owes back

A handoff that only runs one way is a toss over the wall with better packaging. Engineering owes design three things.

A harness that runs design's rows on every change. Not at launch, not on request. The rows live next to the code tests and fail the same way. This is the same argument as The Eval Is the Spec on the product side, and it's why the harness is an engineering asset even though design writes most of the behavior rows.

A regression report in design's language. Which row failed, the input, the output, and what changed since the last pass. A single score is useless to a designer. A failing row with its output in front of it is a design review that takes five minutes.

And the rows it can't pass inside budget. Some behavior costs latency or inference money, and engineering will find out before anyone else. That list goes back to design and the PM as a decision, not as a defect report. Maybe the floor moves. Maybe the budget does. But someone decides it with the row in front of them, and nobody quietly drops the row.

The ownership split is short. Design owns the behavior rows and their thresholds. Engineering owns the harness, the implementation, and the latency and cost budgets. When a row and a budget collide, both names go on the row and the PM breaks the tie, because the PM owns the outcome the trade-off is about.

The redline is dead. The failing row replaces it, and it's better, because it keeps running after everybody's moved on to the next feature. That's the receipt and the work in one sentence: the file was the receipt, the rows are the work.

One thing to try this week

Take the feature your team most recently handed to engineering. Mockup, prototype, capsule, doesn't matter.

Write its five most important never-do lines as rows, each with one real input that should make it fail. Thirty minutes. Ask engineering to run the five against what's in staging or production.

Count the fails. Then decide, with the engineering lead in the room, whether those five rows live in the harness from now on. They should.

Sources: Claire Vo with Blair Metcalf, "Why Reddit built its own AI prototyping tool | Blair Metcalf," How I AI on Lenny's Newsletter, October 26, 2026; adoption and prototype figures from the show notes, the feature capsule and the "may or may not go through" line as Metcalf describes them in the episode, details as reported in The Column It Needs Is Shipped. Maria Rosala and Rachel Banawa, "AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings," Nielsen Norman Group, October 23, 2026. Uditi Sharma, "Where does a PM's prototype stop?," Product With Uditi, October 11, 2026. Ravi Mehta's PRD finding as cited in part 2.

Part of the running argument on AI Product Management: AI collapsed the cost of the parts product teams were trained to be good at, and between design and engineering that means the prototype got production-shaped while the spec engineering can actually run became the handoff.

Related answer: What should design hand to engineering instead of a mockup?