Building Frontends With AI

Frontend is where AI shines and stumbles in equal measure. It can scaffold a UI in minutes that would have taken a junior developer a full day. It can also produce something that looks like every other AI-generated landing page on the internet: gradient hero, three feature cards, identical pricing table, generic stock photo. The agent finished the job. The result is forgettable.

The split here is not laziness on the agent's part. It is structural. Backend correctness has clear pass/fail criteria. Frontend correctness includes taste, and taste is a moving target trained on whatever the agent has seen the most of, which means safe, common, average. If you want a frontend that does not feel like it was assembled from a checklist, you have to bring the design judgment yourself and let the agent handle the typing.

This page works through the practical mechanics of building frontends with AI: how component architecture changes when an agent is doing the scaffolding, where state actually belongs, why Tailwind has won the AI compatibility race, and how to fight the generic-output gravity well that pulls every AI-generated UI toward the same five looks. The recommendations are opinionated. The frameworks are the ones that actually work in 2026 production codebases, not the ones that sounded promising in a 2022 blog post.

Why Frontend With AI Is a Different Game Than Backend

The mechanical parts of frontend work map onto AI assistance the same way backend work does. A Claude or Cursor session can produce a working React component, a Tailwind layout, a fetch hook, a form with validation, and the result will run. Tests pass, types check, the page loads. By the standards backend work is judged on, the job is done.

Frontend has a second axis the agent does not measure on. Does the layout breathe? Does the type rhythm feel deliberate? Does the spacing tell the eye where to land first? Does the brand have a voice or does it look like every Stripe-clone hero in the last four years? These are real engineering concerns, not afterthoughts, and the agent does not have a strong signal to optimize for them. It can produce code that compiles, code that runs, code that is technically correct, and still produce a UI that is forgettable.

This asymmetry is rooted in how feedback loops work for the agent. A failing test is a clear signal: the assertion did not match. A type error is a clear signal: the shapes do not align. A 500 status code is a clear signal: the request blew up. Compare that to "the spacing feels off" or "the hero looks like every other SaaS site." There is no test that fails. The agent receives no feedback. The output ships, looks generic, and the agent has no idea anything went wrong.

The result is that frontend work with AI splits into two distinct phases. Phase one is the part the agent owns: scaffolding, boilerplate, prop typing, form wiring, accessibility attributes, responsive breakpoints. Phase two is the part you own: design tokens, layout rhythm, type pairing, illustration, motion, the choices that make the UI distinctive. Treat them as one phase and the work plateaus at "fine but generic." Treat them as two phases and you get speed on the mechanical parts plus taste on the visible parts.

One useful frame: the agent is faster than you at the parts of the work that are well-documented and slower than you at the parts that require seeing the result. Documented work means React component patterns, Tailwind class composition, form validation libraries, accessibility attribute names. Seeing-the-result work means deciding the hero needs less padding, the pricing tier needs a different emphasis, the dark mode contrast on the secondary text is wrong. Plan accordingly. The mistake most teams make is asking the agent to make the seeing-the-result decisions and then being disappointed that the output looks like every other agent's output. The agent did the only thing it could do given the inputs.

The flip side is true too. Asking a senior designer to write a 600-line React form with React Hook Form, Zod validation, accessible error states, focus management on submit failure, and optimistic UI updates is a waste of expensive design hours. The agent does that work in a quarter of the time, and the only design choice involved is which form library to standardize on. Match the work to the worker. Tasks where the failure mode is "the test failed" go to the agent. Tasks where the failure mode is "this feels off" stay with the human.

Component Architecture From the Ground Up

The fastest way to produce a codebase the agent cannot work with cleanly is to put everything in one file. A 1,200-line page component with inline state, inline data fetching, inline styles, and inline child components will run, but every change touches the same file, the agent has to load the whole thing into context, and surgical edits become whole-file rewrites. Architecture matters more, not less, when an agent is editing. The agent's context window is a finite resource. Files that are too big consume that resource on irrelevant code, leaving less room for the actual change.

The pattern that works across React, Vue, Svelte, and Solid is some form of separated concerns: presentation in one place, state in another, data fetching in a third, utilities in a fourth. The names vary. The split is the same. A presentational component receives data and callbacks as props and renders. A hook owns state and side effects. A data-fetching layer owns API calls. A utilities folder owns pure functions. When all four are in their place, every change has an obvious file to land in, and the agent can produce edits that fit instead of inventing new conventions every session.

Atomic design is one popular framing for this split: atoms (button, input, label), molecules (search bar combining input plus button), organisms (header containing search and nav), templates (page layouts), pages (concrete instances). Domain-driven is another: organize by feature instead of by layer, so all the checkout components live together regardless of whether they are atoms or organisms. Both work. Pick one and apply it consistently. The agent does much better when the structure is predictable, because it can pattern-match new work onto existing files instead of inventing new conventions.

React remains the lingua franca for AI agents because it has the largest training corpus and the most consistent patterns. That does not mean it is the best framework for every project. Vue 3 with the Composition API, Svelte 5 with runes, and Solid with its fine-grained reactivity all produce smaller bundles and simpler reactivity models. Agents can write them all. They write more idiomatic React because that is where the volume of training data sits, and the agent has internalized the common React patterns more deeply.

The practical implication: if you have no strong framework preference, default to Next.js with React for the smoothest agent experience. If you have a preference for Vue or Svelte, pick that and accept slightly more work guiding the agent to your conventions. The agent will get there. The first attempt may need more correction. Document your conventions in a CLAUDE.md or AGENTS.md at the repo root so the agent has the rules in context every session, and the corrections become one-time rather than recurring.

Server-first frameworks have shifted the architecture conversation in the last two years. Next.js App Router, Remix, SvelteKit, and Nuxt all default to running components on the server and only sending JavaScript for the parts that need interactivity. This changes what "component architecture" means. A typical Next.js App Router page is a server component that imports data, passes it to nested server components for layout and content, and only marks specific leaves as client components when they need state, event handlers, or browser APIs. The agent needs to understand this split or it will mark too many things as client components and ship more JavaScript than necessary.

The convention that works: server components are the default, "use client" is the exception. When the agent generates a new component, the question is "does this need browser-only behavior?" If yes, mark it client and push the boundary as deep into the tree as possible. If no, leave it server. A common error in AI-generated Next.js code is putting "use client" at the top of a layout component because it has a useState somewhere five levels deep. The fix is to extract the stateful piece into its own client component and leave the layout on the server.

State Management Without Overengineering

State management is where AI-generated frontends most often go wrong, and the failure mode is consistent: the agent reaches for too much. Asked to manage form state, it installs Redux Toolkit. Asked to track a single dropdown's open state, it sets up a global Zustand store. The agent has read more enterprise codebases than personal projects, and the bias shows. Enterprise codebases tend to over-engineer state because the cost of choosing wrong at scale is higher; the agent generalizes that bias to projects where the cost of over-engineering is the actual problem.

The rule is to start with the smallest tool that solves the problem and only escalate when there is real cause. Most state in a React app belongs in a single component, managed with useState or useReducer. Server data belongs in a server component if you are using Next.js App Router, or in a fetch hook with caching if not. Cross-component UI state, like a sidebar's open/closed status, belongs in Context if it is small and local, or in a tiny global store like Zustand if it spans many places.

The honest version of the spectrum: 80 percent of components need only useState. 15 percent need a fetch hook for server data. 4 percent need Context or Zustand for shared UI state. 1 percent need Redux for complex enterprise flows. If your codebase has Redux everywhere, it was probably built by someone who learned React in 2018 and never updated their defaults, or by an agent that pattern-matched onto a codebase from that era. Redux Toolkit is a fine library when its complexity matches the problem; the issue is that most problems do not need its complexity, and the cost of carrying it shows up in onboarding time, bundle size, and review effort.

Local state covers form fields, modal open/closed, hover effects, animation triggers, and tab selection within a single page. Use useState for one or two values, useReducer once you have three or more transitions or related state. No library needed. The state lives where it is used and dies when the component unmounts. This is by far the most common case, and resisting the temptation to globalize it is the single biggest improvement most codebases can make.

Server data is anything fetched from an API, anything that lives in a database, anything that needs caching across navigations. In Next.js App Router, fetch in server components and pass props down. In SPAs, use TanStack Query (formerly React Query) or SWR. Treat server data as cache, not state, because it has an authoritative source elsewhere. The mental shift here is important: server data does not need to be "managed" the way local state does. It needs to be fetched, cached, invalidated, and re-fetched. A query library handles all four. A state store handles none of them and forces you to reimplement the cache.

Cross-component UI state covers sidebar open status, theme preference, notification toasts, command palette state. Context works for state that is read in many places but written in few. Zustand or Jotai work better when state is read and written across the tree, with simpler ergonomics than Context plus useReducer plus memoization. Stay under 50 lines of store code total. If your global store grows past 50 lines, the state probably wants to be split into multiple smaller stores or moved closer to where it is used.

Complex application state covers multi-step wizards with branching paths, undo/redo stacks, optimistic updates with rollback, real-time collaboration state. Redux Toolkit earns its keep here because the patterns (slices, thunks, selectors, devtools) scale. XState earns its keep when the state has a clear finite-state-machine shape. Most apps never get here. If you are building a Figma clone, an Excel competitor, or a multiplayer game, you are in this category. If you are building a SaaS dashboard, you are not.

// Local state. The boring default that handles most cases
function SignupForm() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [submitting, setSubmitting] = useState(false);
  // ... rest of form
}

// Server data. Fetch hook with caching
function ProductList() {
  const { data, isLoading } = useQuery({
    queryKey: ['products'],
    queryFn: () => fetch('/api/products').then(r => r.json()),
  });
  if (isLoading) return <Skeleton />;
  return <Grid items={data} />;
}

// Cross-component UI state. Zustand for the sidebar
const useSidebar = create((set) => ({
  isOpen: false,
  toggle: () => set((s) => ({ isOpen: !s.isOpen })),
  close: () => set({ isOpen: false }),
}));

When you ask an agent to add state, be specific about which bucket the state belongs in. "Add an open/closed state for this modal that lives in the parent component" produces different code than "manage the modal state for this app." The first prompt directs the agent to local state. The second prompt invites it to install a state library you do not need. Specificity in prompts is not pedantry; it is the difference between getting working code and getting working code that drags 40KB of dependency weight you will never undo.

One pattern worth codifying: write a short "state policy" in your CLAUDE.md or AGENTS.md. "Default to useState for local state. Use TanStack Query for server data. Use Zustand for cross-component UI state. Do not introduce Redux without explicit approval." This single section saves hours of correction over the lifetime of the project, because the agent reads the policy at the start of every session and produces compliant code from the first attempt.

Styling With AI

Tailwind has won the AI-compatible CSS race, and the reasons are mechanical, not aesthetic. Tailwind class names are predictable, finite, and composable. The agent does not have to invent class names, hold a CSS file in context, or reason about specificity. It composes utilities and the result is deterministic. CSS-in-JS solutions and traditional CSS Modules both work, but they require the agent to coordinate across more files, which slows down both the agent and you.

The other reason Tailwind dominates AI-generated UIs: there is enough Tailwind in training data that the agent has internalized common patterns. Ask for a centered card with shadow and rounded corners, and you will get sensible utility composition without back-and-forth. Ask for the same in vanilla CSS and you get five extra round-trips while the agent decides on class names and reasoning about hover states. The composability of utility classes maps cleanly to how language models reason about text generation: pick the next token from a constrained vocabulary, repeat. Tailwind is a constrained vocabulary by design.

The Tailwind 4 release in 2024 simplified configuration further by moving from a JavaScript config to a CSS-based config. This makes the agent's job easier still, because it can read and write the configuration in the same file format as the rest of the styling. The migration from Tailwind 3 to Tailwind 4 is mostly mechanical and well-documented, and the agent handles it cleanly when given the migration guide.

// tailwind.config.ts. Design tokens defined once, used everywhere
import type { Config } from 'tailwindcss';

export default {
  content: ['./src/**/*.{ts,tsx}'],
  theme: {
    extend: {
      colors: {
        ink: { 50: '#f7f7f8', 500: '#374151', 900: '#0a0a0a' },
        accent: { 500: '#6366f1', 600: '#4f46e5' },
        surface: { DEFAULT: '#ffffff', subtle: '#fafafa' },
      },
      fontFamily: {
        display: ['Inter Display', 'system-ui', 'sans-serif'],
        body: ['Inter', 'system-ui', 'sans-serif'],
        mono: ['JetBrains Mono', 'ui-monospace', 'monospace'],
      },
      spacing: {
        '4.5': '1.125rem',
        '13': '3.25rem',
        '18': '4.5rem',
      },
      borderRadius: {
        'xl': '0.875rem',
        '2xl': '1.25rem',
      },
    },
  },
} satisfies Config;

Design tokens are the single most impactful intervention you can make to fight generic-feeling output. The default Tailwind palette is excellent at being inoffensive and terrible at being distinctive. Every AI-generated UI that uses raw Tailwind defaults looks like every other AI-generated UI. Override the colors, override the type, override the spacing rhythm, and the agent will compose distinctive UIs because the materials it is composing are distinctive. Twelve color tokens cover most production needs (3 ink shades, 2 accent, 4 surface, 3 status). Two or three font families maximum (display, body, optional mono). Eight spacing values cover most layouts in a pixel rhythm. Three radius values prevent the "every corner is different" smell.

Component libraries that pair well with AI fall into a few camps. shadcn/ui has become the default choice for new React projects because it is not a library you install in the traditional sense: it is a set of primitives you copy into your codebase and own. The agent can edit them, you can theme them, and there is no vendor lock-in. The CLI runs once per component, drops the source into your repo, and you treat the files like any other file in your codebase. Updates are pulled in by re-running the CLI for that component, which is a deliberate process rather than an automatic version bump.

Radix UI provides the headless primitives shadcn builds on, useful when you want full styling control without the shadcn defaults. It handles accessibility, keyboard navigation, focus management, and ARIA attributes for components like dialogs, popovers, and combobox patterns. You bring the visuals. Radix brings the behavior. For most teams, shadcn is the right starting point because it ships with sensible defaults and Radix underneath, giving you both the speed of a component library and the ownership of headless primitives.

Mantine and Chakra UI are full component libraries with built-in theming. They are faster to start with than shadcn, harder to deeply customize, and harder to escape from when you outgrow their design language. Mantine has 100-plus components and strong hooks for common patterns. Chakra has prop-based styling that some developers prefer to utility classes. Both are reasonable choices for internal tools, admin dashboards, and projects where shipping speed matters more than distinctive design. For consumer-facing products with strong brand requirements, shadcn plus Tailwind is the more flexible foundation.

Headless UI from Tailwind Labs covers a smaller set of primitives (menu, dialog, listbox, switch) with strong accessibility defaults and Tailwind-native styling. It is a smaller commitment than Radix and a smaller ecosystem than shadcn, useful when you only need a handful of behavioral primitives and want to keep the dependency surface tight.

For theming, the modern pattern is CSS variables for the values that change between themes (colors mostly) plus Tailwind utilities that reference those variables. Light/dark mode becomes a class toggle on the html element, and every component picks up the new colors without re-renders or context propagation. shadcn ships this pattern out of the box. Implementing it from scratch takes maybe 30 lines of CSS plus a Tailwind config that maps utilities to variables.

/* globals.css. CSS variables for theming */
:root {
  --background: 0 0% 100%;
  --foreground: 240 10% 3.9%;
  --primary: 240 5.9% 10%;
  --muted: 240 4.8% 95.9%;
  --border: 240 5.9% 90%;
}

.dark {
  --background: 240 10% 3.9%;
  --foreground: 0 0% 98%;
  --primary: 0 0% 98%;
  --muted: 240 3.7% 15.9%;
  --border: 240 3.7% 15.9%;
}

/* Tailwind utilities reference the variables */
.bg-background { background: hsl(var(--background)); }
.text-foreground { color: hsl(var(--foreground)); }

One pitfall with AI-generated styling: the agent often defaults to overly-rounded corners, gradient backgrounds, and shadow-heavy cards because those are common in training data. If you want a flatter, sharper, more editorial look, say so explicitly in your prompts and reflect it in your tokens. "Use 4px radius, no shadows, solid backgrounds only" is a useful constraint to bake into a CLAUDE.md or a prompt prefix. The agent obeys explicit constraints; it does not invent them. Without them, it defaults to whatever pattern dominates its training data, which in 2026 is still the rounded-gradient-shadow stack from the 2020-2023 SaaS template era.

Forms, Validation, Accessibility

The boring critical stuff is where AI defaults are weakest, because the failure modes are not visible to the agent. A form that submits without validation looks fine until a user types nothing into the email field. A button without an aria-label is invisible to screen readers but renders identically for sighted users. The agent does not run a screen reader against its output. You have to. The good news is that the patterns are well-known and the agent can produce them reliably once you establish the conventions.

Forms are the most error-prone surface in any frontend. They have client-side validation, server-side validation, error display, focus management, accessibility, optimistic updates, and submission states. Asking an agent to "build a signup form" without specifying any of these will produce a form that works for happy-path users and falls apart on every edge case. Be specific. The pattern that works in 2026 is schema-first validation with React Hook Form (or TanStack Form) plus Zod (or Valibot for smaller bundles). The schema describes the data, the form library handles the wiring, and the same schema validates on the server.

Define the schema first. Use Zod, Yup, or Valibot to describe the shape and constraints. Email must match a pattern, password must be at least 8 characters, age must be a number between 13 and 120. The schema becomes the source of truth for both client and server validation, and TypeScript types come for free via z.infer. The agent can generate the schema from a description, generate the form from the schema, and generate the API route handler that validates against the same schema. One source of truth, three usage points.

Pick a form library or accept the boilerplate. React Hook Form is the dominant choice for React. It handles registration, validation, errors, and submission with minimal re-renders. TanStack Form is newer and increasingly popular, with a more typed API. For simple forms with three or four fields, plain useState plus a submit handler is fine. The line where a form library starts paying off is around five fields with cross-field validation, or any form where you need to handle field arrays or nested objects.

Wire validation to the schema. React Hook Form has resolvers for Zod, Yup, and Valibot. The form library validates on submit, on blur, or on change, and surfaces errors mapped to fields. The same schema validates on the server when the form posts. One source of truth, two enforcement points. The agent does this wiring well when the imports and resolver setup are documented; it tends to wing it when the conventions are not written down anywhere.

Display errors near the offending field. An error message above the form that says "There were errors" is useless. The error must appear next to the field that failed, must be associated with the field via aria-describedby, and must be announced by screen readers. Focus the first invalid field on submit failure. These are mechanical patterns the agent can produce; the failure mode is producing them inconsistently across forms unless you have a shared FormField component that handles the wiring.

Handle submission states explicitly. Submitting, success, error. Disable the submit button while submitting to prevent double-submission. Show a loading indicator. Surface server errors in the same field-level pattern as client errors. On success, either redirect or clear the form and show confirmation. The agent often forgets the disabled state on the submit button, which leads to double-submits when users click twice. A code review checklist that includes "is the submit button disabled while submitting" catches this every time.

Accessibility is the second underweighted area. The agent will produce semantic HTML if you ask, but defaults vary. Buttons should be button elements, not divs with onClick. Links to other pages should be anchor elements, not buttons that call router.push. Interactive controls need aria-labels when their purpose is not clear from text content. Form fields need labels associated via the for/htmlFor attribute. Focus states need to be visible, not removed by a global outline:none rule.

The minimum contrast ratio for body text against background is 4.5:1 (WCAG AA). The minimum for large text (18pt+) and UI components like icons is 3:1. The minimum touch target size on mobile is 44 pixels per side (Apple HIG; WCAG 2.5.5 says 44x44). 100 percent of interactive elements should be keyboard-reachable in tab order, and the focus order should be logical, not based on visual placement after CSS reordering. These numbers are not negotiable; they are the baseline for an accessible interface, and the agent will only meet them if you ask.

The mental check that catches most accessibility regressions: imagine submitting your interface to a screen reader. Tab through it. What is announced? Is the order logical? Are there elements that focus but produce nothing audible? Are there elements that should focus but cannot? This takes ten minutes and finds problems no automated tool catches. macOS users have VoiceOver built in (Cmd+F5 to toggle); Windows users can install NVDA for free; mobile users can enable VoiceOver on iOS or TalkBack on Android.

Tools that help: axe DevTools as a browser extension, eslint-plugin-jsx-a11y in your linting setup, the WebAIM contrast checker for color decisions, VoiceOver on macOS or NVDA on Windows for actual screen reader testing. The eslint plugin is the lowest-effort intervention with the highest payoff. It catches missing alt text, invalid aria attributes, missing labels, and dozens of other common errors before the code ships. Add it to your project once and it pays compounding dividends.

// React Hook Form + Zod. The standard stack for forms with validation
import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';

const schema = z.object({
  email: z.string().email('Enter a valid email'),
  password: z.string().min(8, 'At least 8 characters'),
});

type FormData = z.infer<typeof schema>;

function SignupForm() {
  const { register, handleSubmit, formState: { errors, isSubmitting } } =
    useForm<FormData>({ resolver: zodResolver(schema) });

  const onSubmit = async (data: FormData) => {
    const res = await fetch('/api/signup', {
      method: 'POST',
      body: JSON.stringify(data),
    });
    // handle response
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)} noValidate>
      <label htmlFor="email">Email</label>
      <input
        id="email"
        type="email"
        aria-invalid={!!errors.email}
        aria-describedby={errors.email ? 'email-error' : undefined}
        {...register('email')}
      />
      {errors.email && (
        <p id="email-error" role="alert">{errors.email.message}</p>
      )}
      <button type="submit" disabled={isSubmitting}>
        {isSubmitting ? 'Creating account...' : 'Sign up'}
      </button>
    </form>
  );
}

Making It Not Look Generic

The AI default aesthetic is real and recognizable. Gradient hero with subtle noise. Three feature cards with rounded corners and soft shadows. Identical pricing tier table with the middle column highlighted. Stock photography of diverse people pointing at laptops. Inter or Geist for body type. Lucide icons. The whole thing looks competent and forgettable. Anyone who has spent ten minutes on Product Hunt in the last two years has seen this exact composition forty times.

The pull toward this aesthetic is gravitational, not lazy. The agent has seen this look thousands of times. It is the safest answer to "build me a SaaS landing page." Defying it requires deliberate input from you, because the agent does not know what your brand is supposed to feel like and will not invent a distinctive answer on its own. The defensive position is the most-trained-on position; that is mathematically what training a model on the internet produces.

The fix is to bring the design choices and let the agent execute them. That means giving the agent constraints it would not invent: "Use a serif display font like Tiempos or Marfa Display paired with a grotesque body face. Color palette is warm cream, deep navy, and a single accent of muted coral. No gradients. No drop shadows. 4px radius on all containers. Headlines set in 60-72px on desktop with tight tracking." The agent can execute that. The agent will not propose it. The constraints come from you, the execution comes from the agent, and the result is something neither of you would produce alone.

The numbers are illustrative, not measured. The pattern is real. UIs that get to "distinctive" are the ones where a human made design choices that the agent then executed. UIs that stop at "generic" are the ones where the agent was asked to make the design choices and predictably defaulted to the most-trained-on aesthetic.

Practical interventions that produce distinctive output:

One, define a real type system. Pair a display face with a body face that contrast in personality, not just weight. A modern serif (Source Serif Pro, Charter, or commercial faces like Tiempos) paired with a clean grotesque (Inter, Söhne, ABC Diatype) reads as editorial. A heavy industrial display (Druk, Migra) paired with a humanist body (Lyon, Greycliff) reads as confident. A geometric sans display (Recoleta, Inter Display) paired with a monospace caption layer reads as technical. Pick the pairing that fits your brand, codify it in tokens, and the agent will use it consistently. The choice of two faces does more for distinctiveness than ten new color tokens.

Two, escape the default color palette. Indigo, violet, teal, emerald, and slate are the AI-default palette because they appear in dozens of popular templates. Choose colors with personality: a deep oxblood, a saturated mustard, a desaturated sage. The constraint of working with non-default colors forces the agent to compose more thoughtfully and produces outputs that do not match every other AI-generated UI. The constraint also surfaces accessibility issues earlier; non-default colors often have weaker contrast against typical neutral backgrounds, which forces you to actually check contrast ratios instead of relying on Tailwind's defaults to be safe.

Three, choose deliberate spacing rhythms. Default Tailwind spacing produces predictable results. A custom rhythm (say, multiples of 6 instead of 4, or a non-linear scale that emphasizes certain steps) gives every layout a fingerprint. Combined with a custom type scale, the same components composed by the agent will look different from the same components composed against default tokens. The Modular Scale at modularscale.com is a useful starting point; pick a ratio (1.25, 1.333, 1.5, 1.618 are common) and let it generate your entire spacing and type scale from a single base value.

Four, run the taste loop. Ship a draft. Open it on a real device. Look at it for 30 seconds. Note what feels wrong. Iterate on those specific issues. The agent cannot run this loop for you because it does not see the result. You are the only one who can. The mistake here is trying to skip this loop by asking the agent to "make it look better." The agent has no specific feedback to act on, so it produces another generic-leaning iteration. Specific feedback ("the hero padding is too tight; the secondary CTA needs less weight; the testimonial typography is fighting the headline") gives the agent something concrete to fix.

Five, commission custom assets. Stock illustration is a tell; AI-generated illustration is a bigger tell unless heavily art-directed. A real illustrator producing 8-12 custom marks for your brand transforms the visual identity at a cost that is small compared to the engineering hours saved by AI-assisted development. Photography on a real shoot beats AI-generated portraits for the same reason: the result has a specific perspective rather than a generic one. The economics of "save engineering hours, spend the savings on art direction" is one of the better trades available right now.

Performance Considerations

Bundle size is the silent killer of AI-generated frontends. The agent installs whatever package solves the immediate problem. Three months in, your dependency list has 89 packages, your client bundle is 1.2 megabytes compressed, and your time-to-interactive on a mid-range Android phone is 6 seconds. Each individual decision was reasonable. The cumulative result is a frontend that does not feel fast.

The fix is to treat bundle size as a budget, not an afterthought. Set a target (200KB compressed for the initial JS payload is a useful starting point), measure on every build, and reject changes that blow through it without justification. The agent does not track this on its own. You have to make it visible. Tools that help: next-bundle-analyzer for Next.js, webpack-bundle-analyzer for Webpack-based builds, rollup-plugin-visualizer for Vite and Rollup, size-limit for CI enforcement. Pick one, install it once, and look at the output before every release.

Tree-shaking and named imports do most of the work, but only if the libraries you depend on cooperate. Lodash needs lodash-es or per-function imports (import debounce from 'lodash/debounce'). Moment.js cannot be tree-shaken; replace with date-fns or Day.js. Icon libraries vary widely; lucide-react and heroicons are tree-shakeable, font-awesome typically is not. Run bundle analyzer and look at what is actually shipping. The biggest bundle wins come from spotting one or two large packages and either removing them or swapping them for tree-shakeable alternatives.

Hydration cost is the second performance trap, specific to React-based frameworks. Every interactive component in a Next.js or Remix app costs hydration time on first load: the framework re-runs the React tree on the client to attach event handlers. Server components and the React Server Components architecture exist to address this. Components that do not need interactivity stay on the server. Components that do need interactivity opt in with "use client" and only those pay the hydration cost.

Server components are the default in Next.js App Router. They render to HTML on the server and ship no JavaScript to the client. Use them for static content, data fetching, layouts, anything without interactivity. They can import server-only modules (database clients, file system, secrets). They cannot use useState, useEffect, or any browser API. Client components are marked with "use client" at the top of the file. They run on both server (for initial HTML) and client (for interactivity). They can use hooks, browser APIs, event handlers. They cost hydration time and bundle size. Use them only when interactivity is needed and push the boundary as deep into the tree as possible.

Image optimization is the third lever. Next.js ships next/image, which handles responsive sizes, modern formats (WebP, AVIF), lazy loading, and blur placeholders out of the box. Use it. Outside Next.js, the same patterns apply: srcset for responsive sizes, format negotiation via the picture element, loading="lazy" for below-the-fold images, width and height attributes to prevent layout shift. Hero images especially benefit from priority loading and explicit dimensions. AVIF is now supported in all major browsers and produces 25-50 percent smaller files than WebP at equivalent quality.

Font loading is the fourth. Web fonts add 100-300KB and can block render. Variable fonts ship one file that covers many weights and styles. font-display: swap shows fallback text immediately and swaps in the web font when ready. Subsetting (only including the glyphs you actually use) cuts file size by 50-80 percent for languages that use a small character set. The system font stack (system-ui, sans-serif) ships zero bytes and looks acceptable, useful for low-priority text. Use Inter or Geist via next/font (Next.js) or unplugin-fonts (Vite) to get optimized loading without manual configuration.

// next/font. Automatic font optimization, no layout shift
import { Inter, Inter_Display } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-body',
});

const interDisplay = Inter_Display({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-display',
  weight: ['600', '700', '800'],
});

export default function RootLayout({ children }) {
  return (
    <html className={`${inter.variable} ${interDisplay.variable}`}>
      <body>{children}</body>
    </html>
  );
}

Performance budgets work because they make the cost visible at decision time, not in production. CI that fails when the bundle exceeds 200KB compressed forces a conversation about every package addition. Lighthouse CI that runs on every PR catches Core Web Vitals regressions before they ship. The agent cannot enforce these constraints; you set them up once and the build pipeline enforces them automatically. The setup is a few hours of work and pays back across every future PR.

Core Web Vitals are the metrics Google uses for search ranking and that map well to perceived performance. Largest Contentful Paint (LCP) measures when the main content renders and should be under 2.5 seconds. Interaction to Next Paint (INP) measures input responsiveness and should be under 200ms. Cumulative Layout Shift (CLS) measures unexpected visual movement and should be under 0.1. The web-vitals library reports all three from a real browser, and Chrome's Lighthouse audit estimates them in CI. Both should be in your pipeline.

Mobile-First Thinking

Mobile is the default in 2026 traffic. Depending on the niche, mobile traffic ranges from 55 to 75 percent of total visitors, and the trend has been monotonic for ten years. A frontend that looks great on a 27-inch monitor and falls apart on a phone is a frontend that fails most of its users. The agent does not know your traffic mix. Designing mobile-first means starting from the constrained device and adding layers up to the larger ones, not the other way around.

The mechanical part is easy. Tailwind's responsive prefixes (sm:, md:, lg:, xl:) make it natural to write mobile styles as defaults and add larger breakpoints as overrides. CSS Grid and Flexbox handle reflow well. Container queries (now stable in all major browsers) let components respond to their container size instead of just the viewport. The patterns work. The agent can write them. The default mobile-first behavior is a single line in your prompts: "Write Tailwind classes mobile-first; use responsive prefixes only when overriding for larger viewports."

The hard part is the parts that only show up on real devices. Virtual keyboards push your viewport up and can hide form fields. Touch targets that are 32 pixels high feel cramped on a thumb. Hover states do not exist on touch devices, so anything that depends on hover for discoverability is invisible to most of your users. Scroll momentum on iOS behaves differently than on Android. Safari has its own quirks with viewport units and 100vh on mobile. The dvh, lvh, and svh units exist specifically because 100vh was wrong on iOS for a decade; if your code still uses 100vh for "full screen" effects, swap to 100dvh.

The minimum touch target dimension is 44 pixels (Apple HIG; WCAG 2.5.5 says 44x44). Material Design's recommended touch target on Android is 48dp (about 48 logical pixels). The minimum spacing between adjacent touch targets to prevent mis-taps is 8 pixels. The minimum body text size to prevent iOS Safari from auto-zooming on input focus is 16 pixels. These four numbers prevent most of the touch interaction problems in mobile UIs.

The classification of responsive approaches is worth knowing because the agent uses the terms loosely. Responsive design means one layout that scales fluidly across viewport sizes using percentage widths, relative units, and breakpoints. The same HTML serves all devices; CSS adjusts. This is the default approach for most sites, and Tailwind plus CSS Grid plus Flexbox makes it natural. Adaptive design means distinct layouts for distinct device classes (mobile, tablet, desktop), often with different content prioritization. Each viewport class gets its own designed layout instead of a fluid scaling. This approach is used for apps with very different mobile and desktop experiences (banking, complex SaaS).

Fluid design means layouts that interpolate continuously between breakpoints using clamp(), viewport units, and container queries. There are no fixed breakpoints; instead, type and spacing scale smoothly across the entire viewport range. This is the modern approach when you have a strong token system and want layouts that breathe with the viewport size. Container queries let components respond to their container's size instead of the viewport: a card component shows a horizontal layout in a wide container and a vertical layout in a narrow container, regardless of viewport. Container queries have been stable in all major browsers since 2023 and are useful for component libraries and dashboard layouts where the same component appears in multiple contexts.

The "test on a real phone" rule exists because Chrome DevTools mobile emulation lies. It shows you the viewport size, but it does not give you the touch interaction model, the keyboard behavior, the scroll physics, the actual rendering performance on a mid-range device, or the network conditions of mobile data. Plug a phone into your laptop, enable USB debugging, and look at your work on the actual device. This takes five minutes and finds problems that emulation never surfaces.

What "mid-range device" means in 2026: think Pixel 7a or iPhone 13, not the latest flagship. These have decent CPUs but not infinite memory; aggressive animations and large bundles still feel slow. The 75th percentile of devices is closer to a Samsung A-series than a flagship. Test there, not on your top-of-line review unit. WebPageTest.org and Chrome's "Slow 4G" throttling get you partway; nothing fully replaces a real device on a real network.

// Tailwind mobile-first pattern. Defaults are mobile, larger viewports add overrides
<div className="
  px-4 py-6           {/* mobile defaults */}
  sm:px-6 sm:py-8     {/* small (640px+) */}
  md:px-8 md:py-12    {/* medium (768px+) */}
  lg:px-12 lg:py-16   {/* large (1024px+) */}
  flex flex-col       {/* mobile: vertical stack */}
  md:flex-row         {/* tablet+: horizontal */}
  gap-4 md:gap-8
">
  <Sidebar className="w-full md:w-64 md:shrink-0" />
  <Main className="flex-1" />
</div>

Touch handling deserves specific attention. The CSS hover media query lets you write hover styles that only apply on devices that actually have hover capability: @media (hover: hover) { ... }. This prevents the "hover state stuck on mobile" bug where a user taps a card and the hover styles persist until they tap somewhere else. Pair with @media (pointer: coarse) for touch devices specifically. Tailwind exposes both as variants: hover:bg-accent-500 only applies on devices with hover, and pointer-coarse:p-4 only applies on touch devices.

Virtual keyboard behavior is the trickiest mobile interaction to get right. When a user focuses a form field, iOS Safari pushes the viewport up. If your fixed-position elements (modals, headers, footers) are positioned relative to the viewport, they will jump. The Visual Viewport API gives you the actual visible area accounting for the keyboard. The "interactive-widget" meta tag (with values "resizes-content", "resizes-visual", or "overlays-content") lets you control this behavior in modern browsers. For most apps, "resizes-content" works as expected: the layout shrinks to fit above the keyboard and your fixed elements stay where the user expects.

Closing

Frontend with AI is faster than frontend without it. A scaffolding session that used to take a junior developer a day takes an agent twenty minutes. Component shells, prop types, form wiring, accessibility attributes, responsive breakpoints: all of these compress dramatically when an agent does the typing. The speedup is real and the time savings are not theoretical.

The quality plateau is real too. Without taste-direction from a human, AI-generated frontends top out at "fine but generic." The gradient hero, three feature cards, indigo accent, Inter typeface aesthetic is not laziness on the agent's part; it is the safest answer the agent can produce given the prompts it receives. Distinctive outputs require deliberate choices the agent will not make for you: typography, color, spacing, illustration, layout decisions outside the default templates.

The work that survives is the work where a human brought the design judgment and let the agent handle the typing. That is the actual division of labor. Architecture decisions, design tokens, component library choices, accessibility checks, performance budgets, mobile testing on real devices: these are yours. The mechanical work of producing the code that implements your decisions: that is the agent's. Treat them as one role and you get plateau output. Treat them as two and you get speed plus distinctiveness, which is the actual goal. Generic outputs are easy to spot and easier to dismiss; distinctive outputs require deliberate choices the agent will not make for you.