When a few sentences become a prototype
Lovable. Bolt. v0 – these tools all promise the same thing: a clickable prototype created from a few sentences in a matter of minutes. And it’s actually true. Anyone who’s never seen a client’s eyes light up as they point to an AI-generated design and say, ‘That’s exactly how we want it,’ either hasn’t worked in this industry long enough, or has simply been lucky so far – both scenarios are possible.
In any case, the result looks like a product: it has colours, it has buttons, you can click on it and something happens. In short, it’s impressive enough not to be scrutinised in a meeting. But what is it, if you take a closer look? It’s the statistical average of everything the AI model has ever seen in web design.
Researchers at the University of Washington have described this in rather matter-of-fact terms. LLMs are trained on a web dominated by the same frameworks, the same component libraries and the same layout conventions. The result is simply predictable: generic layouts, standard components, a clean but entirely interchangeable look. When under time pressure – and when aren’t we under time pressure these days? – you simply go with this output. Regardless of the fact that your own brand identity is sacrificed in the process, replaced by whatever the model ‘just does’.
Just because it works doesn’t mean it’s good
And then there’s what you can’t see, because it lies beneath the surface. AI-generated code runs. It looks correct. It passes superficial tests. At first glance, this isn’t an argument against AI code, but rather an argument for who reviews it. Because that is precisely where the real problem lies: not in the tool, but in the assumption that no specialist knowledge is required to use it.
AI code that’s checked, understood and taken responsibility for by experienced developers certainly has its place. AI code that is put into production by someone who doesn’t know what to look out for is an open invitation. What works is left untouched – until someone who doesn’t have your best interests or those of your organisation at heart gets their hands on it.
The situation is similar in the design process. Anyone who tries to convert an AI-generated prototype into an editable Figma document quickly ends up in a state that feels like the basement of someone who never throws anything away: unnecessarily nested layers, generic labels, no component logic whatsoever, no discernible design system, no consistency. For a UX designer looking to further develop a consistent product in Figma, this isn’t a proper starting point, but rather a lot of extra work just to tidy things up.
The first prototype becomes the anchor
However, the security vulnerabilities, the generic appearance and the inconsistencies aren’t actually the main problem. The real problem arises earlier – namely, the moment the client sees the prototype for the first time. From that point on, everything becomes more difficult – and not just a little bit.
Cognitive psychology calls this the anchoring effect. What you see first becomes the frame of reference for everything that follows. An idea that emerges early on – even without user research, even without any validation – gains momentum simply because it was there first. Applied to AI prototypes, this means: the client has seen something clickable. They’ve interacted with it. They’ve probably already shared it with three other people, and now the UX designer comes along and says we should actually rethink the whole thing from scratch, and only use it as a ‘basis’.
That’s no longer a design discussion; it’s therapy. For an anchor that you didn’t set yourself, and which nonetheless now defines the entire project. You get stuck on the first plausible output, and the divergent thinking that would be necessary for good decisions simply no longer takes place. It’s hard to explain this to someone who’s currently very proud of their two-hour prototype.
Quickly visible isn’t sustainably good
The promise is: faster. For project managers and founders, this is actually true in the short term – and, as we know, the short term is the favourite timeframe of project managers and founders. Something is there, something is visible, someone can point to something. What isn’t so easy to show is the effort that arises afterwards.
The inconsistencies, the ‘priming’ that you first have to laboriously break down, the technical debt that eventually becomes so huge that nobody knows what the thing actually does anymore. In the end, UX designers spend more time ironing out mistakes and persuading clients to change their minds than they would have if they’d been part of the process from the start. The efficiency gains end up somewhere – just not where you wanted them to be.
UX is more than just prompting
AI models are getting better and better at simulating competence. That is the real problem. Not because they’re good, but because they look good enough to stifle the uncomfortable follow-up question.
Can anything be done about it? Yes, actually. We need designers who speak uncomfortable truths at an early stage, convince clients that a two-hour prototype and a well-thought-out product are two different things, and still manage to keep everyone happy somehow. They know when an AI tool, used sensibly, speeds up the process, and when it does more harm than good.
That is precisely the work we do. Using AI where it makes sense, avoiding it where it doesn’t, and always striving to develop UX and UI in the way each project deserves – not just in the quickest way possible. There’s a difference between a tool that saves an expert time and one that replaces an expert. We welcome the former. The latter is something we encounter every day in the projects that come to us afterwards.
