画板 1

    AI-Generated Front End Doesn't Lack Code — It Lacks Constrainable Aesthetics

    4 hr ago0 views

    Over the past two years, the conversation around AI coding tools has moved from "can it write this function" to "can the generated UI actually ship." This article breaks down the five recurring patterns that make AI front-end output feel unfinished, explains the three structural reasons aesthetics resist generation, and lays out four engineering levers — design tokens, grid and visual rhythm, state completeness, accessibility baselines — plus an automated post-generation inspection workflow to turn subjective visual judgment into checkable rules.

    1. The Shift in Focus: From “Can It Generate” to “Does It Look Like a Product”

    Over the past two years, the developer community’s focus on AI coding tools has made a clear shift. The first question was whether the model could write a given function. Then it became whether it could rewrite an entire class. Today the discussion has landed on whether the interface it generates is ready to hand off directly.

    The reason is straightforward: tasks like syntax, API calls, and completing unit tests have clear right-or-wrong boundaries, plenty of training data, and results that can be judged automatically. Visual quality has no such thing as a pass/fail compile result. The tools have leveled the barrier to writing code, but the barrier to shipping has not dropped at the same rate.

    One signal that is easy to misread is the fluctuating volume of content around “AI writing code.” That does not mean interest is declining. On the contrary, the tools have already been adopted as default infrastructure. What has actually become scarce is judgment: which output can be used as-is, which has to be redone, and why.

    2. Where the Gap Is: Five Recurring Flavors of “Half-Finished”

    AI-generated front-end code often passes syntax and type checks, and the interactions do work, yet the result still looks off. This distortion is patterned and can be grouped into five categories.

    1. Spacing in disarray. A page mixes arbitrary values like 7px, 13px, 18px, and 26px, and whitespace between similar elements is inconsistent. Nothing is technically “wrong,” but the rhythm is broken, and users get tired reading it for reasons they cannot name.

    2. Collapsed hierarchy. Headings, body text, and secondary information use similar font sizes and weights, and there is no clear priority inside a card. The result is that every element is “shouting,” and the eye has nowhere to land.

    3. Color out of control. Semantic colors get used as decoration, with three or four accent colors in a single view; or the same element is separated by both a light border and a shadow, producing a double outline.

    4. Missing states. Only the default state is implemented, with no hover, focus-visible, active, disabled, loading, empty, or error states. You will not see this in a demo, but in real use it is breakpoints everywhere.

    5. Responsive degradation. On narrow screens the layout is just multiple columns mechanically stacked into one: font sizes, line heights, and touch target sizes do not adjust. Fixed-width containers overflow, and hidden elements get no equivalent alternative interaction.

    3. Why Aesthetics Are Hard to Generate: Three Structural Gaps

    No feedback loop. Code can run and can be tested, so the model gets an immediate signal. Whether an interface is good or bad has to be judged by human eyes, so there is no equivalent quality signal during training or iteration. Visual output is never the thing being “scored.”

    Biased corpus distribution. The publicly available front-end samples are mostly documentation examples, tutorial snippets, and layout experiments. They aim to demonstrate a principle, not to be production-ready. What the model learns is code that runs, not code that is restrained and consistent.

    An undecidable objective function. Whether spacing should be 16 or 20, or whether the accent color belongs on the button or the heading, are design trade-offs with no single correct answer. Without a decidable objective, the model falls back to whatever is statistically most common — which is also the easiest way to look mediocre.

    The conclusion matters: do not expect a stronger model to “just generate good taste.” The workable path is to decompose aesthetics into engineering constraints that can be executed and verified.

    4. Translating Aesthetics into Engineering Constraints: Four Levers

    Aesthetics feel mystical because they have never been formalized. The following four items turn most subjective judgment into objective checks.

    Lever 1: Tokenize the design system. Collapse colors, font sizes, spacing, radii, shadows, and elevation into a finite set of variables, and require every value to come from that set.

    1. /* First layer of aesthetic constraints: turn "looks good" into "value is legal" */
    2. :root {
    3.   /* 4px base grid */
    4.   --space-1: 4px;  --space-2: 8px;  --space-3: 12px;
    5.   --space-4: 16px; --space-5: 24px; --space-6: 32px;
    6.   /* Five-step type scale */
    7.   --text-xs: 12px; --text-sm: 14px; --text-base: 16px;
    8.   --text-lg: 20px; --text-xl: 24px;
    9.   --radius-sm: 4px; --radius-md: 8px;
    10.   /* Semantic colors: reference by purpose only, never pick arbitrary values */
    11.   --color-text-primary: #1f2329;
    12.   --color-text-secondary: #646a73;
    13.   --color-surface: #ffffff;
    14.   --color-border: #dee0e3;
    15. }

    Once the allowed values are constrained, spacing disarray and color chaos both shrink dramatically.

    Lever 2: Grid and visual rhythm. Define the page-level vertical rhythm: 8–12px inside a card, 16px between cards, 32px between sections, and identical spacing for elements at the same level. Keep the number of hierarchy levels to three or fewer (main heading, subheading, body text). More than three means the information structure itself needs to be rearranged.

    Lever 3: State completeness. Put a “state matrix” into the definition of done. Every interactive component implements all eight states — default, hover, focus-visible, active, disabled, loading, empty, error — and missing any one counts as unfinished.

    Lever 4: Accessibility baseline. Body text contrast against its background of at least 4.5:1 and 3:1 for large text; clickable areas with a short edge of at least 24px; focus styles that must be visible and never removed; form controls explicitly associated with their labels. Contrast is computable, so it can be automated directly.

    5. Move the Spec Upstream: Give the Tool a “Design Context”

    Most teams describe only the business requirements and leave visual judgment to the tool’s default habits — that is exactly where the distortion starts. The spec should be injected as context before generation.

    1. [Design context — takes precedence over default habits]
    2. 1. Spacing: 4px base grid. Only --space-* tokens are allowed; arbitrary px values are forbidden.
    3. 2. Type scale: 12/14/16/20/24 only, line height between 1.25 and 1.6.
    4. 3. Color: reference semantic tokens only (text-primary / text-secondary / surface / border / primary / success / warning / danger).
    5. 4. Hierarchy: at most one accent color per view; never separate the same element with both a border and a shadow.
    6. 5. States: every interactive component must implement all eight states (default / hover / focus / active / disabled / loading / empty / error).
    7. 6. Accessibility: touch target short edge >= 24px; focus visible; every control must have an associated label.
    8. 7. Delivery notes: list the tokens used this time, the states not implemented, and the visual trade-offs that need human confirmation.

    A second highly effective path is to provide visual input: feed a design file or reference screenshot and let the model treat “reproduce this given visual” as the task. That is far more stable than “freely create a page.” The more specific the constraints, the closer the output gets to a mature product.

    6. After Generation: Inspect the Rendered Result Automatically

    Reading the source code wording has limited value. Check the computed styles and geometry after rendering. Contrast, for example, can be calculated directly:

    1. // The widely used accessibility contrast formula
    2. const ch = (c) => { const s = c / 255; return s <= 0.03928 ? s / 12.92 : ((s + 0.055) / 1.055) ** 2.4; };
    3. const lum = ([r, g, b]) => 0.2126 * ch(r) + 0.7152 * ch(g) + 0.0722 * ch(b);
    4. const contrast = (fg, bg) => {
    5.   const [hi, lo] = [lum(fg), lum(bg)].sort((x, y) => y - x);
    6.   return (hi + 0.05) / (lo + 0.05); // body text >= 4.5, large text >= 3.0
    7. };

    The inspection should cover roughly the following, all collected from computed styles and layout information via a headless browser:

    1. - Magic values: any color, font size, or spacing value outside the token set
    2. - Spacing variance: whether the standard deviation of vertical spacing between similar elements exceeds the threshold
    3. - Level count: more than five type scale steps or more than three hierarchy levels
    4. - Contrast: whether text against its actual composited background meets the ratio
    5. - Touch targets: any interactive element with a short edge under 24px
    6. - Text overflow: scrollWidth > clientWidth inside a container with no scrolling enabled
    7. - Visual regression: compare key pages against baseline screenshots and catch unintended changes

    Pair this with density acceptance using real data: render with copy at real lengths and lists with the real number of items, rather than placeholder text and three sample rows. That alone exposes a large number of layout defects.

    7. Turn Every Manual Fix into a Rule

    The biggest waste in a team is designers fixing the same class of problem over and over without leaving a trace. A practical approach is to record each fix as a structured entry: problem type, tokens involved, the basis for the judgment, and the corrected value. Each week, fold the high-frequency entries into the design context and the inspection rules, and the share of human intervention keeps dropping.

    The essence of this loop is converting aesthetics from personal experience into a team asset: constraints go into the spec, the spec goes into the context, and the context goes into automated acceptance.

    8. Pre-Launch Visual Review Checklist

    1. Does the whole site use tokens only for spacing, with consistent rhythm between similar elements?
    2. Is the information hierarchy within three levels, with a clear place for the eye to land?
    3. Are accent colors restrained, and are semantic colors free of decorative misuse?
    4. Are all eight component states implemented and walkable?
    5. Can a keyboard get through the entire flow, with focus always visible?
    6. Do contrast ratios and touch target sizes meet the baseline?
    7. Does it behave correctly on narrow screens, ultra-wide screens, with long text, and with extreme data?
    8. Confirm the overall look one more time after rendering with real data.

    9. Closing

    The statement “there is already no shortage of AI writing code” is accurate, but it needs one addition: what AI produces is a candidate solution, not a finished interface. The tools can hand you runnable code; they cannot decide for your team what good visual judgment is. What really determines delivery quality is whether aesthetics have been decomposed into tokens, grid, states, and contrast — engineering conventions that can be constrained, checked, and reused. Aesthetics are not an ineffable talent. They are a set of parameters that have not yet been written into the spec. Write them down, and the tool’s output will steadily converge on a mature product.

    09040904

    Top articles