{"slug": "ai-speeds-up-prototyping-but-teams-still-need-to-distinguish-decisions-from", "title": "AI speeds up prototyping, but teams still need to distinguish decisions from assumptions", "summary": "Figma Designer Advocate Hugo Raymond warned at Infobip Shift 2026 that AI-generated prototypes can hide unresolved decisions by filling in gaps before teams make them, making a polished prototype look like a finished specification. Raymond said teams must distinguish what they have actually decided from what remains an assumption, and argued that automation should cover copying, waiting, and repetition but not comparing options, testing assumptions, discussing trade-offs, or questioning decisions. He added that code and a design canvas show different things, with code showing what happens and the canvas preserving why a decision was made.", "body_md": "# AI speeds up prototyping, but teams still need to distinguish decisions from assumptions\n\nThe easier it is to make something look finished, the more important it is to understand **what the team actually decided**.\n\nThat was the starting point for Hugo Raymond, Designer Advocate at Figma, in his talk at [Infobip Shift 2026](https://shiftmag.dev/tag/infobip-shift-2026/).\n\nHis main point was that **AI becomes a problem when it fills in the gaps before decisions are made**, because it can hide unresolved decisions.\n\n## **A prototype shouldn’t try to look like a finished product**\n\nHugo reminded us that the purpose of a prototype is to **help the team test an idea**. He compared it to a model airplane:\n\nA model doesn’t try to be a real airplane. We use it to study specific characteristics of the airplane.\n\nThe problem, he argued, is that AI can now create a very convincing prototype even when the original idea is still incomplete:\n\nIn 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 loading and error states, and add behavior that nobody explicitly defined.\n\nIn the end, everything looks like one coherent product, even though the team designed some parts and the model simply filled in the rest.\n\n## Visual polish no longer proves that the team solved the problem\n\nAccording 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.\n\nHugo warned that a polished prototype no longer means that someone has thought through every edge case, business rule, or technical constraint.\n\nOne 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:\n\nAI 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.\n\n## Code is not the opposite of design\n\nHugo 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:\n\nA 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.\n\nStill, **code and a design canvas don’t show the same things**.\n\nCode 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.\n\nBecause of that, he sees a future where **teams combine different materials depending on what they’re trying to learn.**\n\n## AI speeds up execution, but not decision-making\n\nThe final and most important point of his talk focused on the limits of automation.\n\nAI 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**.\n\nHugo therefore makes a distinction between friction worth removing and friction that serves a purpose:\n\nWe can automate copying, waiting, and repetition. We should not automate comparing options, testing assumptions, discussing trade-offs, and questioning decisions.\n\nAs 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.", "url": "https://wpnews.pro/news/ai-speeds-up-prototyping-but-teams-still-need-to-distinguish-decisions-from", "canonical_source": "https://shiftmag.dev/ai-speeds-up-prototyping-but-teams-still-need-to-distinguish-decisions-from-assumptions-12049/", "published_at": "2026-09-14 14:15:01+00:00", "updated_at": "2026-09-14 14:48:04.047755+00:00", "lang": "en", "topics": ["ai-products", "ai-tools", "artificial-intelligence"], "entities": ["Hugo Raymond", "Figma", "Infobip Shift 2026"], "alternates": {"html": "https://wpnews.pro/news/ai-speeds-up-prototyping-but-teams-still-need-to-distinguish-decisions-from", "markdown": "https://wpnews.pro/news/ai-speeds-up-prototyping-but-teams-still-need-to-distinguish-decisions-from.md", "text": "https://wpnews.pro/news/ai-speeds-up-prototyping-but-teams-still-need-to-distinguish-decisions-from.txt", "jsonld": "https://wpnews.pro/news/ai-speeds-up-prototyping-but-teams-still-need-to-distinguish-decisions-from.jsonld"}}