Figma Make Brings Visual Editing Closer To Real Code

The distance between design and development has always been one of the most expensive gaps in software work. A designer creates a screen. A developer translates it into code. The implementation comes back slightly different. The designer comments. The developer adjusts. Another edge case appears. The cycle continues.

Figma’s latest update to Make is an attempt to shorten that loop. The company says users can now connect Make to a local codebase, select elements visually, adjust properties such as layouts, colours, fonts or sizing, and let the agent find the relevant code and apply the change. The feature also supports shipping changes from Make, which moves it beyond prototype generation and into the more sensitive territory of editing real software.

That does not mean designers are suddenly replacing engineers. Nor does it mean every visual change should bypass developer review. The more useful way to read the update is this: Figma is trying to make the codebase more accessible at the exact point where design decisions are made.

For product teams, that could be significant.

The Old Handoff Is Under Pressure

The design-to-development handoff has improved over the years, but it has never fully disappeared. Design systems, component libraries, tokens, inspection tools and better collaboration have helped, yet many teams still lose time translating intent into implementation.

The problem is rarely that designers and developers do not communicate. It is that they work in different surfaces. Designers manipulate the interface visually. Developers manipulate the underlying code. Each side sees part of the truth.

That creates familiar friction. A spacing change that looks small in a design file may be tied to a shared component. A colour adjustment may need to respect design tokens. A button state may depend on accessibility rules, responsiveness, error handling or product logic. A page that looks right in one viewport may fail in another.

Figma Make’s local-code integration is interesting because it tries to bring those worlds closer together. Instead of asking the designer to describe a change and wait for someone else to find the right file, the tool lets the user point at the interface and request the edit directly. The agent then reads the code context and applies the modification.

That is a different workflow from simply generating a prototype from a prompt.

Visual Editing Becomes More Serious When It Touches Production Code

Figma Make has already been part of the wider AI app-building wave, where users can generate prototypes or functional apps from natural-language prompts and design references. The new step is more consequential because it connects to existing codebases. The Verge described the update as allowing teams to use Figma Make as a visual surface for building and editing real software, rather than only exploring prototypes.

That changes the risk profile.

A generated prototype can be imperfect and still useful. It helps a team explore a concept. A change to a real codebase must meet a higher standard. It needs to respect architecture, component reuse, accessibility, state management, responsiveness, tests, naming conventions and design-system rules.

This is where visual code editing can become powerful, but only if the agent understands the surrounding system. A simple colour or spacing change is one thing. A layout change that affects reusable components across multiple pages is another. A visual interface may make the edit feel local, while the code change may have wider consequences.

That is why the developer workflow still matters. Visual edits need review, version control and the ability to see exactly what changed. A strong implementation should create a pull request, show the diff, respect branch workflows and allow engineers to accept, reject or modify the change.

If the tool supports that discipline, it could reduce unnecessary back-and-forth. If it does not, it could create new kinds of cleanup work.

The Role Of The Designer Starts To Shift

For designers, the appeal is obvious. Many design decisions are visual and precise. Designers know when a layout feels off, when spacing is wrong, when a component does not match the intended hierarchy or when the implemented interface has drifted from the design system.

Until now, they often had to communicate those issues indirectly. A comment, a screenshot, a ticket, a Slack message, a QA note. Each adds friction. Visual editing gives the designer a more direct way to express the fix.

That does not require every designer to become a software engineer. But it does require more code awareness. Designers using tools like Figma Make will need to understand that an interface is not only what appears on screen. It is also a system of components, constraints, tokens and behaviours. The best designers may become more comfortable thinking in terms of implementation, without necessarily writing code by hand.

This could make the designer’s role more influential, not because they bypass engineering, but because they can participate more directly in the implementation layer.

It may also change the kind of work designers spend time on. Fewer hours may go into documenting small visual corrections. More time may go into interaction quality, product logic, accessibility, content hierarchy and systems thinking.

Developers May Welcome It, Or Resist It

The developer reaction will depend on how the tool behaves in practice.

If Figma Make produces clean, reviewable changes that respect the existing codebase, developers may welcome it. Small visual fixes, design-system alignment and repetitive UI adjustments can be tedious. If an agent handles them well, engineers can focus on architecture, performance, logic, data flows, tests and higher-value technical work.

But if the agent generates messy diffs, ignores existing patterns or makes changes that look right visually but weaken the codebase, developers will resist it. And they should.

The history of design-to-code tools is full of overpromising. Many tools produce output that looks acceptable in a demo and becomes difficult to maintain in a real product. Recent research into automated Figma-to-code workflows has found that even strong models can struggle with layout responsiveness and code maintainability, despite improving visual fidelity.

That is the standard Figma Make will have to meet. Visual accuracy is not enough. The code has to belong inside the product.

The Real Opportunity Is Smaller Than The Hype, But Still Valuable

The weakest version of this story is that Figma Make will “revolutionise” software development overnight. It probably will not.

The stronger version is more practical. Figma Make could reduce friction around certain kinds of front-end changes: adjusting spacing, typography, colours, layout details, component variants, responsive behaviour or small interface refinements. These are exactly the changes that can consume time because they sit between design judgement and implementation detail.

If those edits become faster, teams may ship more polished products with less coordination overhead. Designers can test ideas in a more realistic environment. Developers can review concrete code changes rather than interpret vague feedback. Product managers can see closer-to-real versions of features earlier.

The tool may also be useful in design-system maintenance. If a team needs to apply a visual pattern across many places, an AI agent with codebase context could help identify relevant components and update them more consistently than manual ticket-by-ticket work.

But this works only when the codebase is structured enough for the agent to understand. A mature component system, clear naming, design tokens and consistent architecture will likely produce better results than a fragmented codebase full of one-off implementations.

In other words, Figma Make may reward teams that already have good front-end discipline.

Governance Becomes Part Of The Workflow

Once visual edits can touch live code, governance becomes central. Teams need clear rules around who can make changes, what kinds of changes require developer approval, how branches are created, how pull requests are reviewed and how design-system rules are enforced.

This is not only a technical issue. It is a team-culture issue.

Designers may want more control over fidelity. Developers may want to protect code quality. Product teams may want faster iteration. Leadership may want shorter delivery cycles. All of those goals are legitimate, but they can conflict if the workflow is not defined.

The best use of Figma Make will probably be collaborative rather than unilateral. Designers can propose or make visual changes. The agent can translate those changes into code. Developers can review the diff. The design system can remain the source of consistency. The product team can move faster without removing technical accountability.

That balance is important. AI tools should reduce handoff friction, not erase professional responsibility.

Why This Matters Beyond Figma

Figma’s move fits a larger trend in software creation. The boundary between design, code and product management is becoming less rigid. AI coding agents can read codebases, generate changes and respond to natural-language instructions. Design tools can create working prototypes. Product teams can test ideas faster. Developers are increasingly working with agents rather than writing every line from scratch.

Research into visual-spec-to-web-app coding agents points in the same direction: agents are being evaluated not only on whether they can write code, but whether they can create visually coherent, functional applications from design inputs and screenshots.

The implication is not that everyone becomes a developer. It is that software work becomes more fluid. The person closest to the problem may be able to express the change more directly, while the tool handles part of the translation.

That is valuable because many product delays are not caused by a lack of ideas. They are caused by translation costs between disciplines.

The Direction Of Travel

Figma Make’s new codebase integration is best understood as part of a gradual shift rather than a sudden break. Design files are becoming less separate from implementation. Code is becoming more editable through visual and natural-language interfaces. AI agents are becoming part of the collaboration layer between disciplines.

The opportunity is faster iteration and better fidelity between what teams design and what users experience. The risk is lower code quality if visual changes are treated as harmless when they are not.

The teams that benefit most will be the ones that keep the workflow disciplined. They will use visual editing for the kinds of changes where it is genuinely efficient, keep developers in the review loop, maintain strong component systems and treat AI-generated edits as proposals that need inspection.

Figma Make may not remove the handoff between design and development. But it can make that handoff less like a translation exercise and more like a shared editing process.

That is a meaningful change. The future of product development is unlikely to be designers on one side and developers on the other, passing files back and forth. It will be a more connected workflow where design intent, code context and AI assistance meet earlier.

The winners will not be the teams that let anyone edit anything. They will be the teams that use these tools to move faster while keeping the product coherent, accessible and maintainable.