A peer-reviewed study of 22 product team members, presented at ACM CHIWORK 2026, found that vibe coding speeds up iteration but does little to help teams decide whether they’re building the right thing. In vibe-coded app UX, the tool’s defaults fill every gap nobody decided, and most of that can be fixed flow by flow, without a rebuild.
A vibe-coded app is one built mostly by prompting an AI coding tool and accepting what it generates, instead of designing and reviewing each screen.
Why do AI-built apps break between screens?
AI tools build an app one screen at a time, but users move through it as one flow, so the gaps show up in the hand-offs. Take a lending app built from five prompts, one per screen: sign-up, identity check, loan amount, offer and first repayment. Here’s where its four hand-offs break.
- Sign-up works. The next screen is a dashboard with nothing on it, because no prompt said the identity check comes next.
- The identity check pre-fills details from a government ID service. When that lookup fails, there’s no route to upload documents instead, so the user is stuck.
- The loan screen asks for monthly income again, although the user entered it two screens earlier. Each screen kept its own copy of the data.
- The repayment screen shows an amount but not the rate or term from the offer, so the user can’t check what they agreed to.
Any one of these screens would get through a demo. A real customer goes through all four hand-offs in one sitting, so the test further down looks at whole flows.
Why do vibe-coded apps feel AI-made?
Vibe-coded apps feel AI-made because every choice the founder skips gets filled with the most common answer on the web. Ask for a lending dashboard and you get a sidebar, four metric cards, a line chart and a table, in a font and corner radius users have seen on a hundred other products. The paper calls this design homogenisation, and its sharper point is why it ships: the first output looks finished, so pushing back feels like extra work. The authors call it a “good enough” trap.
Still, users notice the missing screens well before they notice the styling. Nobody types “tell a new user what to do when the dashboard is empty” or “handle a payment the bank hasn’t confirmed yet,” so those screens get the model’s default: “No data yet,” or “Something went wrong” with a Try again button that invites a second payment.
Accessibility gaps are easy to miss in a demo and easy to measure. These tools learn from public web code, and most of it fails basic checks. WebAIM’s 2026 analysis of the top one million home pages found detectable WCAG failures on 95.9% of them, with low-contrast text on 83.9%. Automated checks catch only part of the problem, so the real picture is worse.
Users never say “this was built with AI.” They say it looks like a template, or they pause before sharing an ID or a payslip. In a product that runs KYC or takes payments, that pause shows up as drop-off at the step that matters most.
The AI-tell test: scoring vibe-coded app UX flow by flow
The AI-tell test scores each core flow against eight tells and marks each one keep, fix or rebuild. It takes about 20 minutes per flow.
- Pick the two or three flows that matter most, usually sign-up, payment and the task users return for.
- Run each as a brand-new user on a mid-range phone and mobile data, the way most first sessions happen.
- Run it again and go off path on purpose. Press back, refresh, enter a wrong value, switch devices, and log in as your second user type.
- Score each tell 0 if it’s handled well, 1 if it’s partly handled and 2 if it’s missing or broken.
Any 2 in a flow where users pay or share documents comes first. A flow that scores 6 or more out of 16 needs more than tidying, so check its rebuild rows before anything else.
| Tell | What users notice | What it costs you | Usual call |
| Default visual style | Looks like a template, or like a competitor | Credibility in the first few seconds and in sales demos | Keep for now. Replace default type and colour once flows work |
| Generic copy | Can’t tell what a button will do | Sign-up drop-off and hesitation at commit steps | Fix. Rewrite in your users’ words |
| Empty states | A blank screen straight after sign-up | Users leave before first value | Fix. Show one clear next step |
| Error messages | Developer wording, and input that disappears | Support tickets, abandoned and duplicate payments | Fix. Say what happened, how to recover, and keep their input |
| Onboarding | A feature tour they swipe past | “How do I…” emails and low activation | Fix. Start with the first real task |
| Off-path behaviour | Back, refresh or a device switch loses progress | Churn in long forms such as KYC, booking or patient intake | Rebuild if progress isn’t saved anywhere. Fix if it is |
| Second user role | Admins and staff see the same screens | B2B deals stall at the demo | Rebuild if the data has no concept of roles |
| Accessibility basics | Unlabelled icons, low contrast, keyboard dead ends | Users who can’t finish, and hard questions from enterprise buyers | Fix. Labels, contrast and focus order are front-end work |
The two rebuild rows are where a vibe-coded app needs real engineering. If a half-finished application lives only in the browser, no screen design survives a refresh, and a manager view needs a data model that knows about managers. The other six are front-end work a designer and one developer can change without touching the database. Older products build up the same kind of hidden UX debt over years; an AI-built app can get there in a few weeks.
Why can’t the AI tool fix these on its own?
AI tools are good at making a change once someone has decided what to change. Most of these tells are decisions about your users that the tool can’t see.
- It only fixes what you ask for. Every tell in the table exists because nobody asked. A tool won’t flag an empty state it never built, or a hand-off between two screens it generated separately.
- The calls depend on people. Which flow matters most, what a first-time borrower needs to see before sharing a payslip, and whether lost progress is a screen problem or a data problem all come down to your users, your regulator and your business model.
- It has no user to watch. A tool can check its output against a rule. Only watching someone go off path shows where they hesitate, give up or pay twice.
Digitraly, which runs UX assessments for software teams in fintech, aviation and healthcare, takes one workflow, tests it the way a real user meets it, ranks each issue by severity and by what it costs the business, and turns the result into fixes your developers, or your AI tool, can build.
When is a UX fix the wrong first step?
If users finish your core flow and still don’t come back, no UX fix will help, because the problem is demand. Better empty states won’t create a need that isn’t there. Talk to the users who left first.
Engineering comes first if the app slows with a few dozen people on it, or if API keys and customer data aren’t secured, especially with payment or health data. And if the product is still a prototype testing an idea, leave the generic look alone until someone wants it.
Where to start
AI tools have made a working first version cheap to build, but the decisions users judge a product on still take someone’s time and attention. Users notice when nobody made them, usually at an empty screen or a broken hand-off. Pick the flow where users most often stop, score it on a phone this week, and fix the 2s before anyone decides what to rebuild.
