A case study from Prerender.io. One feature, three repositories, and the four things that had to be true before any of it worked.
In April I wrote about what happens after a design sprint when you have Claude Code: four prototypes in two weeks, real business logic, mock data, flows you could click through. A few things remained open:
- Do they turn into production code?
- Or shall we throw them away?
- Or live and let die?
It would be quite a waste, so we decided to make the most of it, actually . Our front-end developer took a prototype and built on the base of it. And actually we have never done a classic design hand off. Why the design hand-off is no longer needed then?
What the workflow actually is
As for now we maintain 3 repositories, which coexist together and feed each other.
The design system
A themed React component library where the brand tokens, the responsive behaviour and the accessibility work all live inside the components. This is a base for prototype components. I imposed strict rules how the prototype is fed from here
The prototype
A generated against the design system and the product requirements document, then argued over across a lot of critique sessions until it was worth keeping. The prototype is a running application. Mock data stands in for the real endpoints. The microcopy has been through review. The interaction states behave and it’s deployed, so you can look and play with it independently.
The Codebase
The product codebase is the third, running on a little bit different stack from the other two. And here is the biggest challenge, which we (for now) closing half-way.
The dev challenge
The developer’s job is to translate that into the product codebase. Translate, not copy. The two sides sit on different major versions of Ant Design and different versions of React, so every component gets re-expressed in the target stack’s conventions.
He drives that translation through Claude Code with a custom skill pointed at both repos. The skill is the interesting artefact here, as it automates the hell of a job when interpreting the prototype code and matching it with the actual codebase. But we are also planning on shortening that path, and build prototypes straight in the codebase. More about it soon :)
What actually changed in the handoff
The old loop hand-off style was slow because a Figma file described an interface without being one. Every value had to be read, guessed at, built, then checked against the thing it came from. Also it was super time consuming to build every state in Figma and to present each tooltip or interaction. It’s much faster now. Fine tuning copy or interactions is faster than building it from scratch. Right?
We stopped running into each other with the questions like: “Which component is this?” and “what is this class supposed to be?” Both vanished the moment we started to exchange github repo commits :)
The second change: the interactions are real. When a design file is the contract, any state nobody had time to draw simply doesn’t exist, and the developer either invents it or comes back to ask. When the reference is a working prototype, the states are whatever got built, including the ones I never got round to sketching properly.
Figma hasn’t disappeared from my work, because in May I wrote about going back to Figma to redesign a flow by hand after AI handed me something logically sound and completely unimaginative. Figma is still where I produce initial idea, a step after doodling with pencil and paper. Still handy, but in a bit different context.
Apart from the work comfor, have we gained anything? Yes, indeed. The speed of the process. It’s not that easy to quantify it into a hard gain, but I would risk the assumption of at least 50% decrease in time on designer <-> front-end team.
So how to start?
There are several conditions to make it work, actually.
The PRDs were good enough to build from. It needs to be detailed, up to date, and including the business logic along with the edge cases. Our product manager went through the feature section by section and wrote, in plain prose, what each piece of data represents and where the data comes from. That document, more than any design artifact, is what lets a model build the right thing. And it was constantly updated along the product lifecycle. So no more old and stale PRDs. Sorry!
A developer willing to experiment. Somebody had to take a set of imperfect artifacts, make them work, and come back to tell what ain’t working right. That transparency I appreciate a lot! And that helped me to learn massively!
A shared component library on both sides. A common library (Ant Design) underneath the prototype and underneath production. That’s what turns a port into a mapping exercise, and it took a long run of iterations to get there. When there’s no exact token match on the target side, the instruction is to fall back to the closest one that exists and never invent a value. That rule isn’t new. I put it in my own project template back in April, phrased as never use raw hex for brand tokens. I am almost sure that if we the design system + prototype would sit on completely different codebase (like shadcn/ui) the Claude skill matching the prototype with the acutal codebase would produce some hallucinations and errors.
A prototype worth copying. Generated quickly from the PRD and the design system, then fine-tuned over many rounds: challenged both by business and technical stakeholders. Its feasibility was evaluated before converted to the codebase.
Two of those four have nothing to do with AI. The model did the translation. Everything that made the translation possible was ordinary product hygiene: a maintained document, a shared library, a willing colleague, and a prototype that had already been through critique.
The underlying Rule: one source of truth
There shouldn’t be conflicting documents, and if they are, the AI should know what the escalation route is. In simple words: which is the most important document and based on which the final decision should be made. For instance: where the PRD and the design disagree, follow the PRD.
Sounds a bit like process bureaucracy. What it actually does is guard against a specific failure. When the design contradicts what the PRD says, the model won’t shrug and carry on. It stops building and starts reasoning about whether the underlying data model is wrong. Should it change the back end?
Declaring one document the winner doesn’t allow that loop to be open.
Where this still breaks
This is not perfect, yet (ha!). We will get there, but here is a quick list of things to improve and how we handle them so far.
Design can’t be the knowledge base. The circular reasoning above is a symptom. The cause is that a design file accumulates labels, tooltips and descriptions nobody treats as authoritative, and a model has no way of knowing which ones to discount.
Business copy distracts the model. A capable model tries to infer meaning from wording. Hand it a domain term from our world, something like a crawled page, and off it goes through the database fields hunting for something that fits. The string is a placeholder marketing will rewrite, but it has no way of knowing that. Being smart is usually what you want. Here you want it incurious about the copy and precise about the data. There’s already a translation file in every project where every label maps to a value, and pointing the skill at that file is the obvious fix.
Prototype and production are separate contexts. Different repos, different stacks. Whatever gets learned while building the prototype doesn’t carry into the codebase, so every port re-establishes context that already existed somewhere else. Moving the prototype into the codebase as a subfolder would fix that, and it’s the change I expect to open the most doors.
What I would tell another team
Start with the document, not the model. If your requirements are stale or your business logic lives in somebody’s memory, adding an AI agent will produce wrong things faster than before. AI knows how to build unwise things in a matter of light speed.
Then decide what wins. Not as a philosophy of design. Just a written rule an agent can follow when two sources disagree.
And make your business documentation UI agnostic. Don’t describe the interface. Let the prototype be the artefact on that one.
The design system underneath all of this is the one I described back in March, across three earlier posts. It was built to be a single source of truth. Turns out the useful test of that claim is whether somebody who didn’t build it reaches for it when nobody’s watching.
