The AI UI Problem Nobody Talks About
Every AI-generated UI looks identical. I thought it was a model problem. I was wrong.
I’ve built hundreds of UIs with AI. It started as curiosity: “Can GPT-5 build me a landing page?” And it worked. Sort of. I’d describe what I wanted, the AI would spit out code, I’d iterate until it looked right, and eventually I’d have something functional.
But here’s what nobody tells you about AI-generated UIs: they all look the same.
You know the design I’m talking about. Centered div. “Welcome to Our Product” in 48px. Generic three-column feature grid. Gradient “Get Started” button. Fake testimonials with lorem ipsum. Whether you’re using GPT-5, Claude-Sonnet-4.5, or Gemini. Whether you’re building a SaaS app or an internal tool. Same template. Same hierarchy. Same components.
I thought this was inevitable. Training data bias. “AI slop.” We’d just have to wait for better models.
I was completely wrong.
The problem wasn’t the models. It was us giving AI creative freedom when what we needed was constraints.
This is the story of how I built UI Intent into AskCodi and watched a free open-source model match Claude-Sonnet-4.5’s output quality.
The Five Attempts That Changed Everything
Let me show you my life before UI Intent.
I’m prototyping an internal analytics dashboard for a client. Simple requirements: display metrics, show charts, provide filters. I write a prompt:
“Create a dashboard to display sales metrics with charts and filters.”
Attempt 1: GPT-5.1
The AI gives me a landing page with a hero section. Navigation bar with “Home, About, Contact”. Large centred card with placeholder text. Single “View Dashboard” button.
Wrong product type entirely.
Attempt 2: Claude-Sonnet-4.5
Better. I get a data table (good!). But it adds authentication UI (not needed). Includes user profile dropdown (not asked for). No charts, despite my explicit request.
Attempt 3: Same prompt, next day
Completely different layout. Sidebar navigation appeared out of nowhere. Three different chart types (bar, line, pie). Metrics are hardcoded and not configurable.
Different AI response to the identical prompt.
Attempt 4: Gemini 3
Marketing-focused landing page again. “Unlock Your Data” headline. Pricing table (?). No actual dashboard functionality.
Attempt 5: Back to GPT-5.1
Finally something reasonable. But uses different component library. Different colour scheme. Different data structure.
Same prompt. Five wildly different interpretations.
The Vague Prompt Paradox
The more I experimented, the more I noticed a pattern: detailed prompts didn’t actually help.
I tried being hyper-specific:
“Create a dashboard with a sidebar navigation on the left (dark background, 240px width, fixed position), a top header bar (white background, 64px height, contains logo and user dropdown), and main content area with 4 metric cards in a grid (2x2 on desktop, 1x4 on mobile). Each card shows a number, label, and percentage change. Below the cards, show a line chart for sales over time using Chart.js. Use Tailwind CSS with the default color palette. Navigation items: Dashboard, Reports, Settings.”
The result? The AI got overwhelmed. It nailed some specifics but ignored others. The sidebar was 280px instead of 240px. The metric cards used a 4x1 grid instead of 2x2. The chart library was Recharts instead of Chart.js. The navigation had an extra “Analytics” item I didn’t mention.
But here’s the real problem: the UI was still generic. Despite all my specificity, it looked like every other AI-generated dashboard. The spacing felt off. The typography was bland. The interactions were basic. It was functional but not good.
So I tried the opposite approach, vague prompts with iterative refinement:
“Build me a dashboard.”
Then I’d refine:
“Add charts”
“Make it more spacious”
“Use a sidebar”
“Remove the authentication”
“Make it darker”
“Add filters”
The result? After 10 to 15 back-and-forth messages, I’d get something decent. But the process was exhausting. And if I started a new conversation tomorrow with the same vague prompt? Completely different output. No consistency. No memory. No design system.
The Model Lottery
Different models had different biases:
GPT-5.1 loved landing pages. Always added “Get Started” CTAs. Preferred marketing copy over functional UI. Would spontaneously add testimonials and pricing.
Claude-Sonnet-4.5 was more technical, less marketing focused. But it would over-engineer simple requests. Added state management when not needed. Assumed you wanted authentication on everything.
Gemini 3 was visually adventurous (gradients, animations everywhere). But inconsistent component choices. Would switch libraries mid-conversation. Spacing felt random.
Open-source models produced simpler outputs (good and bad). Struggled with complex layouts. Safer, more conservative designs. But also more generic and uninspired.
I found myself playing a game: “Which model will give me something usable today?” I’d try one model, hate the output, switch to another, iterate, get frustrated, switch again.
This wasn’t scalable. This wasn’t professional. This wasn’t the future of development.
There had to be a better way.
Why Human Designers Don’t Have This Problem
I started thinking about why human designers produce consistent work.
When you hire a designer, they don’t randomly switch between design systems. They don’t add authentication flows to internal tools. They don’t put landing page hero sections on dashboards.
Why? Because they understand context.
They know:
Product type: “This is a dashboard, not a landing page.”
Audience: “These are technical users, not consumers.”
Goals: “Success means task completion, not conversion.”
Constraints: “No authentication, no backend, just display data.”
Human designers have an internal model of what’s appropriate. They’ve internalized design patterns, best practices, and anti-patterns. They know that certain UI elements belong in certain contexts.
AI models don’t have this. They have statistical patterns from training data, but no contextual understanding of this specific project.
What if we could give AI that context?
My First Failed Experiments
I tried enhanced system prompts first. I’d prepend every request with:
You are building a DASHBOARD (not a landing page).
Target audience: Technical users (developers and analysts).
Constraints: No authentication, no backend calls, display only.
Design tone: Professional and minimal.
Layout: Sidebar navigation + main content area.
Result: Better, but inconsistent.
Sometimes the AI respected these constraints. Other times it ignored them. If I had a long conversation, the AI would “forget” the context and revert to generic patterns. Adding a chart would suddenly introduce authentication. Asking for a settings page would spawn a pricing table.
The issue was that system prompts are passive guidance, not enforced rules. The AI could follow them, but it wasn’t required to.
Next, I tried JSON metadata attached to each project:
{
"project_type": "dashboard",
"audience": "technical",
"design_tone": "minimal",
"constraints": ["no_auth", "no_backend", "display_only"],
"layout": "sidebar_nav"
}I’d include this in the system prompt and reference it in user messages: “Following the project metadata...”
Result: Slightly better consistency.
The AI would reference the metadata occasionally. But it still felt like suggestion, not governance. If the metadata said “no authentication” and the user asked for a login page, the AI would just... build a login page. The metadata was context, not law.
I needed something stronger.
The Key Insight
Then I had the breakthrough:
What if UI Intent wasn’t just context, but a binding contract?
Not guidance. Not suggestions. Not “here’s some context about this project.”
But an authoritative design specification that the AI must follow, even when the user’s request conflicts with it.
Think about how design systems work in companies:
You have component libraries with specific allowed components. You have design tokens that define colors, spacing, typography. You have anti-patterns documentation (”Never use red buttons for primary actions”). You have accessibility requirements that cannot be violated.
What if UI Intent was a design system for a single application?
A structured specification that defines:
What this UI is (product type, goals, audience)
What it must include (required patterns, components, layouts)
What it must not include (forbidden features, anti-patterns, non-goals)
How it should look (tone, density, visual style)
And most importantly: The AI cannot violate this specification without explicit permission.
This is where the story really begins.
Continue to Part 2: Designing a Design Contract
In the next post, I’ll share how I designed the UI Intent system, the three enforcement options I considered, and why I chose the hardest one to build.
This is Part 1 of a 5-part series on building UI Intent. I’m Sachin, founder of AskCodi, and this is the story of how I solved the generic AI UI problem.