On October 29, 2026, Figma published details about its specialized editing model. Its stated focus is not generating new screens. It is helping designers change work that already exists on the canvas. Figma describes an agent that combines its own editing model with third-party models for different tasks.

That distinction is worth paying attention to. Generating a plausible interface and making a good change to an existing product are different problems.

A new screen can look convincing in isolation. An edit has to respect what is already there: component choices, layout relationships, terminology and the behavior users have learned.

To me, that is the more interesting direction for AI-assisted design. The next competition between design tools is about context.

A good-looking screen can still be the wrong answer

Take a hypothetical inventory application. An AI tool might generate an attractive dashboard with summary cards, charts, recent activity and a table.

But the people using it may need something much more specific: which orders cannot ship, which materials are missing and what to deal with first.

The interface can look finished while the important decision is still unresolved.

My test would not be whether the screen resembles a modern SaaS application. It would be whether it helps someone understand the situation and act on it. That takes product context, not just visual instructions.

Existing products carry rules that are easy to miss

Suppose you ask an agent to simplify an approval screen. What should it preserve?

Perhaps the warning beside a field exists because users repeatedly misunderstood it. Perhaps a confirmation that looks redundant is what separates a draft from an irreversible action. Perhaps one customer role must never see a particular financial detail.

Those are the kinds of constraints I would want documented before delegating the edit.

Some of that context lives in the design file. Some lives in code. Some lives in research, support conversations and the heads of the people maintaining the product. I would treat connecting it as part of the design work.

Vendor numbers are a signal, not your acceptance test

In the same post, Figma reports that typical agent tasks got about 20% faster between beta and general availability, that people undid the agent's work 60% less often and that user ratings were 33% higher. Those are Figma's own numbers, not evidence that every team will see the same improvement.

The practical question is what happens in your own workflow. I would evaluate an editing agent against representative tasks:

  • Update a form without losing its validation states.
  • Apply a component change without introducing inconsistent variants.
  • Simplify a workflow while keeping the decisions it requires.
  • Adapt a screen for another viewport without hiding important actions.

Then I would look at the review and correction effort, not only the time it took to generate the first result.

Make your product easier to understand before asking AI to change it

My response to this direction would be to improve the inputs.

Document what each component is for. Name things clearly. Explain the exceptions. Keep useful examples. Record why a decision exists when the reason would not be obvious from the screen.

I would also separate rules from preferences. "This action requires approval" should not carry the same weight as "we usually prefer this spacing."

It is the same reason I keep the rules my coding agents work under written down: rules in the repository become part of the context every agent works with.

The opportunity is not to remove design judgment. It is to give that judgment a clearer form, so both people and tools can work from it.

An interface is the visible result of many decisions. The more responsibly we want AI to change it, the more clearly we need to communicate the decisions underneath.

If you want AI working on your product and most of its rules still live in people's heads, email me.