SixFifty · 2026
POC to Production Pipeline
A workflow that lets PMs build prototypes in code with AI, get them reviewed by Design and Engineering, and push them to production.
- Tags
- AI · Workflow · Process
The problem
We had a normal workflow. PMs wrote design and dev stories, designers started on Figma, and devs started on the dev work in parallel. Designs got presented to stakeholders, picked apart, revised, eventually approved, and then we handed the approved designs over to engineering to bolt onto whatever they’d been building in the meantime. It worked. It was also slow, and the seams were starting to show.
A couple of things broke it. Some stakeholders didn’t trust Figma prototypes, so we tried Figma Make to get the prototypes feeling more real, but that ate tokens and time and the output was middling. Then PMs got Claude accounts, and the whole thing fell apart in a different way.
Once PMs could vibe code a POC themselves, they started doing it. The problem was that none of those POCs used our design system. So we ended up in this loop where a PM would build a POC in code, hand it to design, and design would have to convert that code into a Figma file just to spec it properly. Then we’d hand the Figma file back to devs to turn back into code. Code to Figma to code. We were laundering a working prototype through Figma for no real reason at all. And the timing of it was rough, because devs had also picked up AI tools and were burning through their backlog twice as fast, so they were starving for new work while design was buried in conversion busywork that didn’t even need to exist. Something had to give.
The insight
If PMs were already building POCs in code, the answer wasn’t to stop them. It was to give them a starting point that was already on-system. Pull down the design system, vibe code with those components, hand the result to design and engineering for review. That collapses the whole loop.
No more code-to-Figma-to-code. Designers review what was actually built instead of redrawing it. Devs get something that’s already 75 to 80 percent production ready and finish the last mile. The catch was that the design system had to live at the top of this stack for any of it to work, and that’s the part I had to fight for. Most teams treat the design system as a reference doc, not as a piece of working infrastructure that the entire product hangs off of. I needed it to be the second one.
What I built
Over a span of a couple of weeks, the first move was rebuilding all our components in React using Claude Code, which took about a week. We had Figma components and we had a code library, but the gap between them was real, and the gap had to close before any of this would work. With the components rebuilt and a token layer underneath, the design system became something a PM could actually pull down and use, not just look at.
After that I built a copy-and-paste prompt for PMs to spin up a new POC. The prompt does a few things in one go. It pulls the design system down, connects them to GitHub, creates a PR, and drops them into a workspace where they can start vibe coding against the right components from the first line. A PM goes from “I have an idea” to “I’m prototyping inside the actual system” in one paste. They never have to think about scaffolding, repos, or which version of which component they’re supposed to be using. It’s all handled before they type the first prompt.
That single prompt turned out to be the most important piece of the whole thing. It removed the only real friction point in the new workflow, which was the moment where a PM had to decide between using the system or going off-script. Now using the system is just easier than not using it. That’s the only way you actually get adoption. You don’t tell people to do the right thing, you make the right thing the path of least resistance.
The pipeline
When a PM has an idea, they paste the prompt and start building the POC. They're not thinking about the design system because the design system is just there, baked into the components they're working with. Whatever they hand off to design is already half on-system by default, which is a different starting point than anything we had before.
PM builds the POC
They paste the prompt, the design system is already pulled down, and they vibe code against the right components from line one. Whatever they hand off is already half on-system by default.
Design reviews the POC
The designer reviews the way they’d review any feature. Accessibility, user feedback, user flows, all the parts of the experience an AI can’t quite see on its own. The pipeline flags any CSS that isn’t from the design system, which surfaces the gaps as a side effect of the review. If something is missing, the design system itself grows by one piece.
Engineering ships it
Devs look at how to wire it to live data, what’s needed to make it shippable, and anything else that has to happen before it goes into production. Some POC code might get rewritten, especially anything load-bearing or security-sensitive, but the goal is plug and play. By the time engineering picks it up, the prototype is already 75 to 80 percent production-ready code. The job is finishing it, not rebuilding it.
The bit that makes this actually work
The design system isn’t just a starting reference for the POC. It’s a live source of truth that propagates downstream the whole way through.
If a POC is sitting in the engineering review stage and a designer changes a button in the design system, that change shows up in the POC immediately. No re-spec. No “hey can you update the screens.” The system itself is the dependency, so updates flow through wherever it’s used. The same is true for tokens, type, spacing, anything that lives in the foundation.
It turns the design system from a static reference into the actual circulatory system of the product.
A PM building a POC, a designer reviewing it, and a dev shipping it are all looking at the same components, with the same updates, in real time. Nothing has to be hand-translated between stages because nothing is being copied. It’s all the same thing, all the way down.
What's hard
Mostly buy-in. Each group lands in a different spot.
PMs are stoked
They get to ship faster, validate their ideas in real product code, and stop writing specs that nobody reads. They’ve been the most enthusiastic adopters by a wide margin, and most of them figured out the prompt within an hour of getting access.
Engineering is uncomfortable
Some of the devs are openly worried they’re being pushed out of jobs by AI and PM-written code. The honest answer is that the role is shifting, not disappearing. The work moves up the stack, from “implement the design” to “make it shippable, secure, and scalable.” Engineers who lean into it end up doing more interesting work, not less.
Design is recalibrating
If PMs can build POCs from the design system, what is design for? My take is that design becomes the gatekeeper of the system itself. Components, accessibility, flows, what’s allowed in the system and what isn’t. Less time pushing rectangles around in Figma, more time owning the source of truth the entire product is built from.
The trick is going to be making both groups feel the upside before the change feels like a threat. That’s mostly a leadership problem, not a tooling problem, and it’s one I expected going in.
Where it is now
I presented the pipeline. Our Head of Product backed it. The SRE team is now figuring out the right shape for the engineering review cycle, since that’s the gate that’s going to make or break trust in the system. Once that’s locked, the pipeline goes from “Ty’s pet project” to “how we ship,” and the rest of the company can start using it without anyone needing my permission to do so.
It’s still in progress, and I don’t want to oversell what’s working yet. But the components are rebuilt, the prompt works, the design system sits at the top of the stack, and the first PM POCs are starting to come through. The early ones are messy. They’ll get less messy as people learn the pattern, and the pattern itself will sharpen as more POCs run through it.
If this lands, the change isn’t just faster shipping. It’s a different shape of product team, where everyone is working from the same set of code-backed components and the round trip between idea and product gets cut by weeks. That’s the version of this that gets me out of bed in the morning. The faster shipping is just a side effect.