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.