Figma Make's new two way GitHub integration turns designs into live, production code — with built In governance

Justy The headline is trying SO hard to start a fight. Designers are the new engineers? Come on.

Cody Yeah. The article’s stronger point is way less dramatic. Figma Make apparently stopped being a one-way prototype toy and became a visual editor that can attach to a real repo, make local changes, and open a normal GitHub pull request.

Justy Right.

Cody That’s the actual argument. Not role replacement. More like, can a designer or PM make bounded frontend edits inside the same workflow engineering already trusts.

Justy Which, honestly, is a much better product story than the fake job-title war. If it really works against an existing codebase, that matters right now because teams are tired of rebuilding the same tiny UI tweak three times in design, prototype, and code.

Cody Mm-hm.

Justy Also I cannot believe episode four hundred thirty-seven of our extremely serious kitchen-table institution is us debating whether the canvas is now a local dev environment.

Cody I mean... that phrase does make my eye twitch a little. But the governance part is why I’m not rolling my eyes all the way back. The piece says Figma Make keeps everything inside standard version control, with local commits, branches, pull requests, and the same C I pipelines and security checks.

Justy Okay okay.

Cody If that’s true, then the scary part is lower. It’s not sneaking code straight into production through a pretty button. It’s just another editor, sort of, with a very opinionated interface.

Justy My week has basically been one long parade of tiny opinionated interfaces. I spent two hours fighting a grocery app because it kept replacing plain yogurt with vanilla yogurt, which is a DIFFERENT FOOD. Anyway, that made me weirdly sympathetic to tools that preserve intent across handoffs.

Cody That is such a Justy bridge. But yes, intent is the whole thing here. The article says the model reads surrounding code architecture, then applies visual edits while anchoring to design system rules like tokens, typography, component variants, auto-layout. That part is plausible for narrow frontend changes.

Justy Right, right.

Cody Where I’d slow down is the phrase production code, because that covers a huge range. Swapping layout, spacing, colors, maybe some component wiring? Sure. Understanding a weird internal state model, custom build setup, edge-case accessibility logic, and all the accidental complexity in a mature app? I think that gets messy fast.

Justy That feels fair, not doomy. And the article kind of supports that read, actually. It keeps positioning Figma Make as a frontend bridge for established teams, not a general-purpose app builder. It even says Figma’s own docs point this at designers who already have codebase access.

Cody Exactly.

Justy So who cares is pretty specific. Mid-size or bigger product orgs with a real design system, real repo guardrails, and a backlog full of visual polish work that engineers do not want to spend Tuesday on.

Cody Yeah.

Justy The stat in the piece was interesting too. Forty-five percent of designers and fifty-nine percent of product managers already contribute to code regularly. I don’t know how universal that is, but if you already have code-adjacent people, this could remove a lot of ceremonial friction.

Cody And that’s where the comparison section helps. Lovable sounds more like code-first, full-stack, repo-as-source-of-truth, better for greenfield SaaS stuff. Claude Design sounds quicker for rough prototypes, then hand it to coding agents, but maybe expensive in token burn for heavy iteration.

Justy No way.

Cody Yeah, that framing made sense to me. Figma Make wins if the thing you already have is a company, not just an idea. Existing components, existing brand rules, existing code ownership. It loses if you need to invent the whole stack from scratch.

Justy There’s also a quiet product truth here. A lot of teams don’t need more raw code generation. They need fewer weird gaps between design intent and mergeable code. That’s less sexy than vibe coding your way into a startup over a weekend, but probably more valuable in a big org.

Cody And less likely to create mystery meat code. Which, sorry, I had to say it.

Justy No, that’s right. My only caution is that the article gets a little grand about the bottleneck moving from engineering bandwidth to governance and design intent. I think that’s true in some teams, not across the board. Plenty of teams still just need engineers and time.

Cody I agree. That’s where it overreaches. Governance matters more once you already have mature systems. If the architecture is chaotic, adding an A I canvas on top does not suddenly make it coherent. It probably amplifies whatever discipline or mess was already there.

Justy Hm.

Cody And the multi-model bit was notable. The article says Figma toggles between Claude three point six Sonnet, Claude Opus, and Gemini. Fine. But model selection is not the moat by itself. The hard thing is the translation layer between design operations and repo-safe code edits.

Justy Which is why I think the practical takeaway is pretty simple. If a team already lives in Figma and GitHub, this is worth testing for UI-layer work. Not because designers become engineers overnight, but because some changes can stop dying in the handoff.

Cody Also because it keeps review where review belongs. Engineers still own the merge. Designers and PMs get a shorter path from intent to proposed change. That’s a healthy split, assuming the generated diff is readable.

Justy Yeah. So not a revolution, not a toy either. Just a pretty sharp bridge, Cody. And I promise not to ship vanilla yogurt to production.