From Prompt
to Pull Request
I designed the pipeline that turns Claude Design's output into production-ready React on Oxygen, Doctolib's design system, then ran it end-to-end with a builder — a designer or PM — to show it goes all the way to a real, reviewable pull request. I reviewed the results with engineering and published the findings for the wider design and engineering org.
The problem
Claude Design could sketch a screen. It couldn't ship one.
Claude Design is fast at generating a layout, but by design it doesn't consume your actual components: even pointed at our GitHub repo or Figma file, it generates its own HTML/CSS interpretation of what Oxygen might look like. The result looked plausible, but it wasn't real Oxygen, and someone still had to rebuild it by hand in production code before anything could ship.
That gap is where most "AI in design tools" attempts stall: the demo looks great, then an engineer redoes the work anyway. If builders were ever going to ship real changes themselves, that translation step had to be automated, not manual.
The initiative
Turn Claude Design's approximation into a real, reviewable pull request.
The goal wasn't a demo, it was a working pipeline: an AI-generated layout going all the way to production Oxygen React, reviewed by an engineer like any other PR.
Core goals
- Duplicate Oxygen inside Claude Design so its output already looks like Oxygen, not a generic approximation
- Build a skill that translates that output into compliant Oxygen React automatically
- Ship a real feature through it, reviewed by an engineer, not a staged demo
- Learn whether builders, not just engineers, could close the loop themselves
How I approached it
Three steps, from an AI sketch to a real pull request.
I duplicated Oxygen inside Claude Design, so it generates HTML and CSS that already look like Oxygen, not a generic AI approximation designers then have to fix by hand. That same accuracy means designers can prototype and ship A/B test variants directly from Claude Design, fast, without waiting on engineering for every iteration.
Claude Design's HTML/CSS is still not production code. I built a matching skill that translates it into compliant Oxygen React, grounded in roughly a dozen Doctolib-specific skills covering accessibility, code best practices, and component APIs, so the translation inherits the same rules a reviewer would enforce by hand. Duplicating Oxygen inside Claude Design and building that skill took a few days, not weeks, most of it reusing skills already written for other workflows.
To validate the pipeline against reality, not intent, I ran it with a real product team: a builder took a real user complaint, designed the fix in Claude Design using Oxygen, and hit "Send to Claude Code" to generate a draft PR. A senior engineer then reviewed it like any other PR, no shortcuts, no staged demo. After the review, it was merged and shipped to production.
The numbers
A builder-authored PR, reviewed like any other.
Results from this first run: one builder, one fix, one review. Not yet an average across teams, a first data point the next iteration is built to confirm or correct.
"This process is definitely a game changer. Every team should already be using this flow for quick wins, and testing it on broader topics too."
VP Product - DoctolibWhat's next
From a first run to a repeatable practice.
This first run used a single one-shot Claude Code prompt; handing that step to a dedicated agentic engineering team is the obvious next lever to push both numbers further. The other is reach: the same speed that let a builder prototype and ship this fix applies just as well to shipping A/B test variants, not just one-off quick wins.
The rollout follows the reviewing engineer's own recommendation: start with "quick wins" only, and plan the extra code-review time into sprint capacity with the EMs involved, rather than treating a builder-authored PR as free engineering time.
What it changes
A new default for how ideas start: designed and half-built, not just described.
A traditional design handoff describes what should change, screens, specs, redlines, and leaves engineers to reconstruct the interactions from scratch. A builder-authored PR shows a working starting point instead, interactions included, cutting the distance between "here's what I want" and shippable code. It doesn't replace engineering judgment, review still catches what a one-shot prompt misses, but it changes where a feature begins.
The bigger unlock isn't the code Claude Code writes, it's how much the thinking cycle shrinks. Designing, iterating, and implementing used to be separate stages spread across weeks. Now they fold into the same sitting, from idea to shippable code in hours, sometimes a day.