The easier it is to make something look finished, the more important it is to understand what the team actually decided.
That was the starting point for Hugo Raymond, Designer Advocate at Figma, in his talk at Infobip Shift 2026.
His main point was that AI becomes a problem when it fills in the gaps before decisions are made, because it can hide unresolved decisions.
A prototype shouldn’t try to look like a finished product #
Hugo reminded us that the purpose of a prototype is to help the team test an idea. He compared it to a model airplane:
A model doesn’t try to be a real airplane. We use it to study specific characteristics of the airplane.
The problem, he argued, is that AI can now create a very convincing prototype even when the original idea is still incomplete:
In the past, gaps were easier to see. If a screen did not exist, a flow ended in a dead end, or the team had not defined a certain state, you could clearly see that nobody had made that decision yet. AI can now connect the flow, generate data, create and error states, and add behavior that nobody explicitly defined.
In the end, everything looks like one coherent product, even though the team designed some parts and the model simply filled in the rest.
Visual polish no longer proves that the team solved the problem #
According to Hugo, this creates an especially important problem for developers: the more finished a prototype looks, the more authority we give it and the more likely we are to treat it as a specification that developers simply need to implement.
Hugo warned that a polished prototype no longer means that someone has thought through every edge case, business rule, or technical constraint.
One of his key points was that polish used to be expensive. If something looked highly refined, you could at least assume that someone had spent time thinking through the problem. Now, the tables had turned:
AI has broken that connection. The first draft can now look like the final iteration. Teams therefore need to make a much clearer distinction between what they have actually decided and what is still only an assumption.
Code is not the opposite of design #
Hugo doesn’t think the solution is to move design back into static mockups, quite the opposite: code is not the opposite of design but one of the materials we use to design:
A code prototype can use real data, react to unexpected input, and show states that a designer did not draw in advance. AI has made this kind of experimentation much more accessible.
Still, code and a design canvas don’t show the same things.
Code is very good at showing what happens, while the canvas can do a better job of preserving why the team made a certain decision, which alternatives the team considered, and what the team still needs to solve.
Because of that, he sees a future where teams combine different materials depending on what they’re trying to learn.
AI speeds up execution, but not decision-making #
The final and most important point of his talk focused on the limits of automation.
AI can take over a lot of repetitive work, speed up prototyping, and help teams test ideas more cheaply, but making something faster does not mean we understand what to make any better.
Hugo therefore makes a distinction between friction worth removing and friction that serves a purpose:
We can automate copying, waiting, and repetition. We should not automate comparing options, testing assumptions, discussing trade-offs, and questioning decisions.
As he pointed out, these moments help teams develop the judgment that AI cannot simply replace. “When almost every prototype can look finished, how convincing it looks is no longer the most important thing,” he said. What matters is whether the team can still clearly see what it has decided, what it has assumed, and what it still needs to solve.