Designers and product owners delivering code: a complete open-source practice for two-way Figma-and-code sync
AI will upend your process—for the better ft. Justin Meyer (Bitovi) | Config 2026 · Justin Meyer
20 min total·Actually worth watching closely: ~6 min·3 must-watch clips
- 0:12 – 1:58Listen
Opening: who is rewriting the delivery process
Opens with the core claim: software development no longer belongs only to engineers, and designers and product owners are building prototypes in hours and committing hundreds of thousands of lines of code.
Iterate on the prototype with stakeholders and real users first, taking out the big risks early, so the engineer only has to build it once.
Largely a statement of position with nothing on screen worth watching. Fine to listen to while doing something else.▶ Jump to 0:12Speaker · Justin Meyer - 1:58 – 4:13Listen
Three steps in a team's AI adoption
Splits the evolution into three stages: one product owner prototyping alone and pushing to the repo; then everyone using agents and getting good at moving work between the ticket system and the design files; finally moving the well-worn paths to the cloud.
Do not jump straight to the end. Find the path you have walked over and over first, then think about automating it.
Organizational stages, illustrated mostly with text outlines. You get more from the narration than from the screen.▶ Jump to 1:58Speaker · Justin Meyer - 4:13 – 6:00Watch
Why prototypes always feel slightly off
Names the consistency problems you inevitably hit when AI builds the prototype: typography that does not match, and a self-contradicting data model, like a form storing the full name while the dropdown shows only the first name. The fix is three dedicated skills: one for brand color and spacing rules, one to stop it rebuilding components that already exist, and one to keep the data model consistent and organized while you are on mock data.
Lock down brand rules, the component inventory and the data model at the prototype stage, or every later step amplifies the inconsistency.
The concrete failures are on screen: you can see the same data rendered differently in the form and the dropdown, which is what makes it clear how easy they are to miss.▶ Jump to 4:13Speaker · Justin Meyer - 6:00 – 8:20Listen
Making room for prototypes in a complex codebase
Covers adding a mock layer to the existing codebase so the AI focuses only on the frontend instead of making a chain of decisions about architecture and data changes, then how to share the prototype in one click for stakeholders to try.
Shorten the decision chain and non-technical colleagues get noticeably faster, more reliable prototypes.
An engineering trade-off explained over flow diagrams. Catching why the layer is there is enough.▶ Jump to 6:00Speaker · Justin Meyer - 8:20 – 9:59Skim
How the designer picks up the prototype
The prototype is shared straight from a cloud dev environment link, so designers and stakeholders can try it without setting anything up, feedback comes back and gets applied immediately, leading into how the designer works with the tooling.
A clickable link buys you real feedback faster than any review document.
Mostly flow and UI screenshots. Skim it to see the collaboration path, no need to catch every sentence.▶ Jump to 8:20Speaker · Justin Meyer - 9:59 – 11:40Watch
Back into the design file, then calibrated pixel by pixel
Demos the reverse direction: rebuilding a running prototype into design files, starting with low-level components and icons, then composites, then the full page, producing the component variants designers are used to. The key addition is a screenshot diff, made more precise with the component showcase tool, catching small deviations and sending them back to be fixed.
Generating the design file is only half of it. The visual diff is what gets it to genuinely usable precision.
Almost entirely screen work and before/after comparisons. Outline weights and control positions only register if you are watching.▶ Jump to 9:59Speaker · Justin Meyer - 11:40 – 14:14Watch
Handing off design review and user stories
Two things: review automatically reads the ticket and the design files, produces consistency and behavior questions, and posts them back onto the design as comments for the designer to answer; story writing produces a draft ticket with design links for the product owner to look over.
Because the team treats the design file as the single source of truth, even the design Q&A context deliberately stays there rather than scattering into chat logs.
How the comments land back on the design, and what the questions actually look like, are both on screen. Audio alone stays abstract.▶ Jump to 11:40Speaker · Justin Meyer - 14:14 – 19:32Skim
Implementation and the cloud takeover
Covers the two levers for getting the design implemented correctly, pulling a structured representation of the design and declaring which code each design component and variant maps to, then moving the whole chain to the cloud, assigning work to an agent the way you would assign a colleague, with a human reviewing the resulting branch in a cloud environment before ship.
Declare the component-to-code mapping properly and, in the speaker's experience, the odds of the implementation matching the design roughly triple.
The back half is configuration notes and flow diagrams. Skim it, catch the two levers and the shape of the automation at the end.▶ Jump to 14:14Speaker · Justin Meyer