AI Coding Era: Frontend Needs Design Judgment More Than Code

1. The evaluation has shifted: from “can it be coded?” to “does it look like a real product?”

Generating a data interface, modifying a view component, or completing a batch of unit tests with AI coding tools is no longer the hard part. For experienced developers, the more troublesome question is this: the code runs, types pass, tests pass, but when the page is shown to real users, it still feels like it was not made by a mature product team.

These judgments are difficult to capture with engineering metrics. They are not reflected in whether the build succeeds, but in small details: the visual focus of the first screen is unstable, spacing between cards is inconsistent, three button styles appear at the same level, hover feedback is missing, and empty states show harsh blank spaces.

The problem therefore becomes concrete: when implementation cost is lowered by tools, frontend quality becomes constrained by the ability to express design judgment and aesthetic rules. This is also the weakest link in the current engineering workflow. We have compilers to verify syntax and tests to verify behavior, but no mechanism to verify whether an interface is reasonable.

2. Seven common types of distortion in AI-generated interfaces

After observing many generated results, the failure patterns are fairly concentrated. They can be grouped into seven categories:

1. Flattened visual hierarchy. Models tend to render every point from a requirements document as a module with equal weight, resulting in six or seven elements that all appear equally important. Mature design relies on clear priority: a page usually allows only one primary visual focus.

2. Broken spacing rhythm. Padding and margins appear with arbitrary values such as 13px, 17px, and 21px, with no relationship between them. People judge layout quality largely through the rhythm of whitespace: spacing within the same group should be clearly smaller than spacing between groups.

3. Color and contrast lose control. Generated interfaces often use default blue, pure black body text, and many accent colors placed side by side without semantic layering. Text and background contrast may also be too low, making small text nearly unreadable.

4. Component consistency drift. The same semantic action, such as delete, may appear as a red text button in one place, a red outline button in another, and an icon button in another. Once consistency breaks, the interface feels assembled from mismatched pieces.

5. Missing interaction states. This is the most easily ignored, yet most easily noticed by users. Generated results often only show the ideal path: no hover, focus, active, disabled, loading, empty, error, or long-text truncation states. Most of a mature product’s polish appears in non-ideal paths.

6. Information architecture copied directly from requirements. Requirements describe what information should be on a page, but not what the user should see first. Models may lay out the checklist faithfully, leading to eight navigation entries and twelve required form fields.

7. Responsive design and accessibility treated as add-ons. Breakpoints are used only to avoid overlap, rather than to reorganize information priority. Keyboard navigation, visible focus, semantic labels, and alternative text for charts are often missing.

3. Root cause: why models cannot automatically fill the aesthetic gap

Attributing these issues simply to insufficient model capability is inaccurate. There are four more fundamental reasons.

First, aesthetics are not style; they are trade-offs under constraints. “Minimal” does not mean removing elements. It means deciding what must be sacrificed within limited space and cognitive budgets. These trade-offs depend heavily on the business context. Without that context, the model can only produce a statistically average-looking solution, and averages naturally lack a strong point of view.

Second, training signals are structurally imbalanced. Code corpus volume far exceeds design-intent corpus volume. Pairing code with corresponding screenshots is also noisy: screenshots contain information not produced by code, such as copy, images, and backend-returned data. This makes it difficult to form an effective supervisory signal for visual decisions.

Third, requirements naturally describe behavior, not visual contracts. A requirement may say “show a confirmation dialog after the user clicks,” but it does not specify the dialog width, layer level, button order, or required confirmation copy for destructive actions. The model can only improvise, and improvisation leads to inconsistency.

Fourth, there is no feedback loop. Functional correctness has type systems and tests as safety nets, but visual problems rely mainly on human inspection. Without a closed feedback loop, iterative convergence is impossible. This is the most critical engineering gap.

4. Core method: turn aesthetics into four layers of design contracts

Since models are good at following explicit constraints, the right solution is not to raise expectations about the model’s taste. Instead, make implicit aesthetic judgment explicit and machine-readable. These four layers tighten from numeric values to behavior.

Layer 1: Design tokens (make aesthetics numeric)

All colors, spacing, font sizes, border radii, and shadows should only come from a limited set. This unifies visual language and makes violations detectable.

/* design-tokens.css — the single source of truth for design */
:root {
  /* Colors: only semantic layers may reference these */
  --color-text-primary:   #1A1D21;
  --color-text-secondary: #5A6069;
  --color-surface-page:   #FFFFFF;
  --color-surface-subtle: #F5F6F8;
  --color-border-default: #E3E6EA;
  --color-accent-primary: #2B5AED;
  --color-status-success: #17864B;
  --color-status-warning: #B36B00;
  --color-status-danger:  #C5332C;
  /* Spacing: a limited scale based on 4px, no arbitrary values */
  --space-1: 4px;  --space-2: 8px;  --space-3: 12px;
  --space-4: 16px; --space-6: 24px; --space-8: 32px; --space-12: 48px;
  /* Font size and line height must be used in pairs */
  --font-size-body:  14px; --line-height-body:  22px;
  --font-size-title: 20px; --line-height-title: 28px;
  --font-weight-emphasis: 600;
  --radius-sm: 4px; --radius-md: 8px;
  --shadow-raised: 0 1px 2px rgba(16,24,40,.06),
                   0 1px 3px rgba(16,24,40,.10);
}

Key constraints: keep token levels minimal; six to eight spacing levels are enough. Do not use more than two accent colors. Danger colors should be reserved for destructive actions. Do not use more than three shadow layers, otherwise depth effects cancel each other out.

Layer 2: Layout and grid (constrain structure)

Structural distortion is the hardest to detect in code review, so explicit rules should replace improvisation:

• Each page must declare one primary visual focus. Other elements must not be emphasized at the same level.
• Breakpoints should be defined as semantic levels, with rules for column counts and information trade-offs, not just width adjustments.
• Spacing within a group must be clearly smaller than spacing between groups. A ratio of at least 1:2 is recommended.
• Long text, long lists, and very large numbers must have truncation or wrapping strategies. They must not break containers.

.page-header { display: flex; align-items: center; gap: var(--space-3); }
.field-group > * + * { margin-top: var(--space-4); }  /* spacing within a group */
.form-section + .form-section { margin-top: var(--space-12); } /* spacing between groups */
@media (max-width: 767px) {
  .detail-layout { grid-template-columns: 1fr; }  /* two columns become one, with adjusted priority */
}

Layer 3: Component contracts (turn components into APIs)

Before generating pages, freeze component interfaces and state sets. The quality gap between model output with contracts and without contracts is significant.

export interface PageHeaderProps {
  title: string;                    // unique per page, determines visual focus
  subtitle?: string;                // up to two lines, truncate if too long
  actions?: ActionSpec[];           // one primary action, up to two secondary actions
  breadcrumb?: BreadcrumbItem[];    // no more than three levels
}
export interface ActionSpec {
  label: string;
  variant: 'primary' | 'secondary' | 'ghost';
  size: 'sm' | 'md';
  loading?: boolean;                // must drive the loading state
  disabledReason?: string;          // disabled state must provide a reason
}
/** The full state set required for any interactive component */
type ComponentStates =
  | 'default' | 'hover' | 'focus-visible' | 'active'
  | 'disabled' | 'loading' | 'empty' | 'error';

Contracts also address consistency drift: actions with the same meaning must reuse the same variant. Models should not reinvent button styles on the same page.

Layer 4: Acceptance criteria (turn “looks good” into testable rules)

This is the most important layer. Aesthetics themselves are hard to judge automatically, but proxy metrics for aesthetics can be automated.

// design-lint: make aesthetics enforceable in CI
const RULES = [
  { id: 'space-scale',  test: n => SCALE.has(n),                    hint: 'spacing value out of range' },
  { id: 'color-token',  test: c => TOKEN_HEXES.has(c),               hint: 'hardcoded color detected' },
  { id: 'type-pair',    test: (fs, lh) => TYPE_PAIRS.has(`${fs}/${lh}`), hint: 'font size and line height are not paired' },
  { id: 'state-cover',  test: s => REQUIRED_STATES.every(x => s.has(x)), hint: 'missing interaction state' },
  { id: 'focus-visible',test: css => /:focus-visible/.test(css),      hint: 'keyboard accessibility missing' },
  { id: 'contrast',     test: (fg, bg) => contrastRatio(fg, bg) >= 4.5, hint: 'insufficient contrast' },
  { id: 'one-focus',    test: page => countEmphasis(page) === 1,      hint: 'visual focus is not unique' },
];

Rules such as state-cover and one-focus are difficult to detect reliably by eye across thousands of lines of code, but they are common sources of the “AI-generated look.” They are well suited to script-based validation.

5. Engineering practice: put generated results into a reviewable loop

The method only works when the workflow supports it. The recommended sequence is:

1. Define contracts first, then let the model generate. Freeze the token file, component inventory, and state requirements before providing the contract files as context. Reversing the order will cause all later output to drift from the baseline.
2. Prefer reuse before creating new components. Explicitly tell the model: if a component is missing, propose it first; do not create a new one on its own. Rebuilding wheels is the main path to consistency collapse.
3. Generate one verifiable unit at a time. A single page, section, or component is easier to review against contracts than an entire interface generated at once.
4. Establish visual regression checks. For key pages, compare screenshots against baselines. Store diffs and rule-check results together. Screenshot artifacts can be stored in object storage, while check results can be written to logging and monitoring systems to create a visible quality trend.
5. Use multiple candidates and a unified review table. Generate two or three options for the same requirement and score them by fixed dimensions instead of intuition: unique visual focus, clear hierarchy, spacing rhythm, complete states, and readability.
6. Move human responsibility earlier and later. Humans define tone, such as brand character and information priority, and make final decisions on whether the result is suitable as a product. The model handles batch implementation within constraints. Aesthetics involve judgment, and judgment should not be outsourced.

6. Reusable requirement description template

Replace vague expressions such as “make it look better” with an executable format:

[Design Contract v1.0]
1. Primary visual focus: ____. The number of elements emphasized at the same level must be 1.
2. One primary action, up to two secondary actions. Destructive actions must be grouped separately and require confirmation.
3. Spacing must use --space-*. Font size and line height must be used in pairs from --font-size-*.
4. Colors may only reference semantic tokens. Hex literal values are prohibited.
5. Required states: default, hover, focus, disabled, loading, empty, error, long text.
6. Reuse components first: ____, ____. If a component is missing, propose it first; do not create one on your own.
7. Breakpoints: below 768px, single column with primary action kept in a safe area; at or above 768px, two columns.
8. Accessibility: fully keyboard accessible, visible focus, body text contrast at least 4.5:1.

The value of this template is that it moves disputes that used to happen during review into explicit input before generation. When disputes are moved earlier, rework is reduced.

7. Conclusion

AI coding tools have reduced the time cost of frontend implementation, but they have also made the bottleneck clearer: code is cheap, but judgment is expensive. The “obviously fake” details in interfaces can usually be traced back to a missing constraint: no tokens, no complete state set, no acceptance criteria.

The right response is not to wait for models to grow their own aesthetic sense. Instead, aesthetics should be engineered: turn visual decisions into tokens and contracts, turn contracts into automatically checkable rules, and connect check results to regression and monitoring loops. When constraints are clear enough, model execution becomes immediately more effective. Judgment, however, still belongs to humans.