Figma is turning a quiet experiment into a pretty loud statement: your local codebase is now invited into Figma Make. And that simple shift – from “AI playground in the cloud” to “AI that edits the code running on your machine” – could end up changing how design and engineering teams actually work day to day.

For anyone who has been watching the design-to-code space over the last couple of years, Figma Make already felt like a glimpse of the future. Launched as a prompt-to-app tool, it let you describe an interface in plain language, attach visual references, and get back a functional prototype backed by real code. Now Figma is going a step further: instead of generating greenfield projects that live in a sandbox, Make can connect to your existing repository, run your app locally from the Figma desktop beta, and directly edit the production UI code driving that live preview.

That’s a big elevation from “toy” to “tool.”

The core idea behind this update is surprisingly straightforward: Make becomes another client of your dev environment. Inside the Figma desktop beta, you can create a Make file, point it to a local folder or clone a GitHub repo, and Figma will wire things up so your app runs inside the Make canvas. Behind the scenes, Make drops configuration into a .figma/make folder, installs dependencies, starts your dev server, and hooks into the preview. Instead of asking AI to hallucinate new code from scratch, you’re asking it to read and modify the code that already exists in your project.

From there, Figma layers a new interaction model on top of traditional coding. You select an element in the live app preview and tweak properties—layout, spacing, colors, fonts, sizing—in a side panel, as if you were editing a design file. Make’s agent then goes off to find the relevant React component, CSS, Tailwind class, or layout logic in your codebase and edits it so the UI and preview reflect your change. It’s not a detached WYSIWYG abstraction that writes inline styles; it’s intended to be real, structured edits to your own code.

Where it gets more interesting is the way Figma mixes visual editing, annotation, and prompting. Simple property changes are point-and-click. For behavior or more complex UI updates, you can drop annotations directly onto the interface, describing an interaction, animation, or multi-element change in natural language. Those annotations act as rich context: Make knows which parts of the DOM or component tree you’re talking about, and can bundle several annotations into a single “transaction” to apply across multiple components. And if you prefer the classic AI workflow, you can still just type a prompt in the Make chat telling it what you want and let it propose code changes.

In practice, this feels like Figma is trying to carve out middle ground between rigid “no-code” builders and raw code editors. You don’t lose the abstraction and speed of design tools, but you’re not trapped behind an export layer that engineers then have to throw away. The edits happen in the same repository the team uses, with version control, branches, and pull requests. Once Make has applied its changes, you can spin up a branch and open a PR from within Figma, then let your standard review process take over.

That workflow matters more than any individual AI feature. It’s Figma signaling that AI-powered design tools shouldn’t stop at prototype exports; they should sit inside the real development loop.

To understand the significance of this, it helps to rewind to what Figma Make was originally pitched as. When Figma announced Make, it framed it as a “prompt-to-app” capability that could generate high-fidelity, interactive prototypes from plain English descriptions and visual references. You’d describe your product idea, target device, core features, and design style, optionally attach screenshots or wireframes, then select a model like GPT-4 or Claude to generate production-style code and a live preview. It was perfect for idea testing and early exploration, especially for people who weren’t comfortable writing code. But there was always an awkward handoff moment: how do you get from AI-generated playground code to the messy, opinionated codebase your team actually maintains?

Developers quickly started hacking around this gap. Community guides popped up showing how to download Make projects, wire them into a Vite-based React setup, apply config patches, and run the result locally. Some folks even built VS Code extensions and scaffolding repos to streamline pulling Make-generated code into local projects. That grassroots energy was a signal: people wanted Make to live closer to their real development workflows, not just in a browser preview silo.

“Make on your local code” is Figma’s answer to that demand, but with a much more integrated approach. Rather than exporting and importing zips manually, you connect the repo directly—either by pointing to a folder on disk or cloning from GitHub via the Make interface. Make adds its configuration, initializes Git if needed, and from that point on you’re working inside a proper version-controlled project. It’s closer to an AI-enhanced design client for your existing app than a one-off generator.

What makes this especially interesting for design and engineering teams is the potential shift in who can safely touch the code. Historically, most designers in a product team wouldn’t dare open the app repo, let alone push changes. Even “design systems” work often ends at a component spec, with engineers implementing the pixel-perfect details later. With Make plugged into local code, the pitch is that designers, PMs, or other non-traditional coders can make constrained, reversible edits to UI code while staying in a familiar Figma environment.

Figma is careful not to present this as a free-for-all. Code editing in Make is restricted to certain seat types on paid plans—Full seats can edit, Full or Dev seats can view and download code—reinforcing that this still lives inside the professional stack rather than as a casual toy for anyone with a free login. And because the whole thing is Git-aware, teams can keep using branches, reviews, and approvals as guardrails.

From a technical perspective, Figma is also quietly acknowledging that “AI editor” doesn’t mean “text box that spits out code.” There’s a full code editor view in Make where you can inspect and manually tweak the underlying files. You can format the code with a quick keyboard shortcut, keep an eye on what the agent changed, and stay grounded in reality. That’s important if you don’t want AI edits to become mysterious black boxes that break your build or silently introduce regressions.

If you zoom out to the broader AI tooling landscape, Make’s local code integration puts Figma into more direct territory with tools like v0, Bolt, Lovable, and the growing crop of AI-native app builders. Many of those tools excel at greenfield generation—type a prompt, get an app—but they often sit apart from existing repos, production infrastructure, or team workflows. Figma’s bet is that existing teams don’t want a separate AI sandbox; they want AI that plays nicely with their current stack, and they want it in the same surface where their design work already lives.

It’s also part of a larger strategy. Over the last two years, Figma has been rolling out a wider slate of AI features—image editing, resolution boosting, smarter prototyping—positioned as ways to “unblock creativity” and speed up the product development cycle. When Figma announced Make’s general availability in 2025, it explicitly linked Make and those AI tools as a suite, not a one-off experiment. Bringing Make into local code is consistent with that trajectory: AI isn’t an extra button, it’s a core part of how Figma imagines teams will move from idea to implementation.

Of course, this also raises the usual concerns that come with AI touching production code. How readable are the edits Make produces? Do they respect team conventions and architecture decisions? How well does the agent navigate real-world complexity—feature flags, legacy components, bespoke styling systems, or heavily customized build pipelines? Figma’s documentation emphasizes that Make uses contextual prompts, annotations, and the live UI to ground its edits, and that developers remain in the loop through branches and code review. But as with every AI coding assistant, the burden is on teams to treat it as a collaborator, not an autopilot.

For now, the rollout is limited. Figma is offering “Make on your local code” in a beta that runs through the Figma beta desktop app, with early access framed as a testbed to refine the experience. In parallel, Make itself has already exited beta and is generally available across Figma plans with tiered access, so this local code piece is more of an advanced capability than the baseline AI feature. If it lands well, you can imagine it becoming one of the flagship reasons to use Figma for design-to-code workflows, not just for mockups.

For US-based teams, especially those juggling distributed collaboration and tight release cycles, that proposition will sound familiar: fewer handoff docs, more direct edits, tighter loops between design intent and shipping code. The optimistic version of this future is one where designers can safely adjust a layout for a marketing experiment, a PM can prototype a flow in the real app, and an engineer can spend more time on architecture and less time nudging pixels via PRs—all inside a Figma file that doubles as both design canvas and AI-assisted code client.

Whether it plays out that way will depend on how well Make actually handles the messiness of production projects once this beta spreads beyond polished demos. But the direction is clear: Figma doesn’t just want to be where your product looks like it works. It wants to be where your product actually runs, with AI ready to help you change it.