Impeccable's Answer to AI Design Sameness
Impeccable is an open-source design skill for AI coding agents. It gives a model a shared vocabulary for frontend work, lets a person compare design variants in a local browser, and checks the resulting interface for a defined set of anti-patterns and quality failures. This series examines Impeccable as a system, not as a bag of frontend tips. The central question is simple: how much of design judgment can be made durable, inspectable, and mechanically testable without pretending that taste, product understanding, or final approval can be automated away?
That question matters because the weakness of AI-generated interfaces is often visible before anyone reads the source. A purple gradient over a dark background, a rounded icon tile above every feature heading, a stack of nested cards, a decorative glow where a real image should be, or a long headline inflated until it consumes the first viewport can make unrelated products look as if they came from the same template. Impeccable's README names these patterns directly. Its detector registry gives them stable identities such as ai-color-palette, nested-cards, icon-tile-stack, and oversized-h1.
The problem is not that every use of a gradient, card, or large heading is bad. A brief can call for any of them. The problem is reaching for a familiar pattern because the agent has no stronger product-specific constraint. A generated interface may be technically valid and still feel interchangeable with an unrelated product. It has code, but not a point of view grounded in the people who will use it, the task they need to complete, or the evidence the product can honestly show.
That sameness has practical consequences. A visitor uses visual hierarchy to decide what matters, whether a product understands their situation, and whether the next action is safe to take. When every surface uses the same hierarchy, the interface spends its first moments proving only that it belongs to a category. The product's own mechanism is pushed below the fold or reduced to interchangeable feature copy. For a working team, the cost appears later as revision: a designer must explain why the page feels generic, an engineer must replace structures that were never grounded in a real task, and the agent must be steered again without a durable record of what the first attempt missed. Impeccable treats the visible tell as a symptom of that missing decision process, not as an isolated offense against taste.
The sameness problem is a control problem
A vague design request asks an agent to make something “beautiful,” “modern,” or “more premium.” Those words express a preference, but they do not give the agent durable authority. They do not say which facts must survive a redesign, which visual decisions belong to the product, which page is meant to persuade rather than support a task, or what evidence would count as a finished result. The model fills the gaps with patterns that have appeared frequently in its training and in previous generated interfaces.
Impeccable's product record describes its intended users as designers, product managers, and engineers working with AI coding tools. Their problem is not a lack of access to CSS. It is the difficulty of steering a fast, capable system with enough precision that the result passes a professional design review rather than merely looking plausible in a screenshot. That makes the project a control layer between human intent and generated frontend code.
A control layer does not need to decide every outcome itself. It needs to preserve the important inputs, make consequential choices visible, and produce feedback at the point where correction is still affordable. Impeccable organizes that work around three connected mechanisms.
First, the skill provides a shared design vocabulary and a set of bounded workflows. It includes 24 commands covering setup, shaping, new work, critique, audit, refinement, hardening, adaptation, live iteration, and related tasks. The commands are not 24 unrelated personalities. They are different entry points into a common set of distinctions: product truth versus visual direction, refinement versus redesign, a quality floor versus a chosen world, and critique versus mechanical detection.
Second, live mode puts visual choice back in the loop. A user can select an element in a local browser, request several variants, cycle through the rendered alternatives, and accept or discard one. The winning change is written to source rather than existing only as a temporary DOM patch. That detail matters. The browser becomes a place to make a decision, while the project files remain the place where the decision lives.
Third, the detector makes a subset of design quality repeatable. The repository currently carries 61 built-in rules. Some describe recognizable generated-UI tells. Others catch failures such as low contrast, text overflow, clipped positioned children, skipped headings, cramped padding, broken images, and content hidden at rest. The CLI and browser-facing detector run without an LLM or API key. They can return a stable rule ID, a description, a location, and a finding that another tool or person can inspect.
These mechanisms reinforce one another, but they do different jobs. The skill can tell an agent to ask what the interface must prove. Live mode can show three possible answers in the actual browser. The detector can flag a low-contrast label or an image that never reaches the screen. None of those steps can independently decide whether the product's central idea is clear, whether the chosen composition fits its audience, or whether a person would trust the result. That division of labor is the beginning of Impeccable's design theory.
The order matters as much as the inventory. A detector finding that appears before a direction exists can turn a local preference into a false requirement. A visual variant generated without product context can be attractive while solving the wrong problem. A polished page reviewed without a mechanical scan can leave a broken image, clipped menu, or unreadable label hidden behind a strong composition. Impeccable's value lies in putting each question at a useful boundary: first preserve what the product means, then make the visual choice explicit, then let rendered behavior and repeatable checks challenge the implementation.
Design quality becomes executable in stages
Calling Impeccable a control layer does not mean it turns design into a checklist. It means the project separates the parts of a design decision that are usually mixed together. Product truth, visual rules, route strategy, implementation evidence, and review signals each get a different place in the workflow. Later chapters will examine those boundaries in detail. At the outset, the important point is that the boundaries are what make the system legible to both a person and an agent.
The first boundary is between what the product is and how it should look. Impeccable's init flow writes durable product knowledge to PRODUCT.md. It asks about users, purpose, positioning, operating context, capabilities, constraints, evidence, platform, accessibility, and confirmed brand commitments. It does not choose a visual world. This prevents a common failure in AI-assisted work: allowing a newly invented palette or page concept to overwrite the facts that should have constrained the invention.
The second boundary is between a reusable visual system and one surface's strategy. DESIGN.md records colors, typography, layout, shapes, component behavior, and visual rules. A surface brief records what one route or artifact needs to accomplish, which visitor mode applies, what the first viewport must prove, and what direction has been chosen. A dashboard, a landing page, and a documentation page can therefore share a design system while making different decisions about density, hierarchy, and action. The system does not ask one global style file to answer every question.
The third boundary is between an attractive result and evidence that the result is finished. Impeccable describes comp-led and code-led build paths, bounded screenshot review, deterministic scans, and separate critique. A comp can provide measured spatial evidence. A detector can report a rule match. A critique can examine specificity, cognitive load, personas, and usability heuristics. Each kind of evidence narrows a different uncertainty. None should be stretched to answer a question it cannot support.
This is why “executable” is a better description than “automated.” A product record can make context persistent. A direction contract can make a visual commitment explicit. Source-owned live variants can make a browser decision inspectable. A rule registry can make certain failures repeatable across the CLI, browser, extension, and hooks. The meaning of the interface still depends on judgment, but the conditions around that judgment become less fragile.
Consider a small action button. Product context can establish who needs the action and what success means. A surface brief can say whether the button is the page's primary commitment or a quiet secondary route. The visual system can define its type, color, shape, and focus treatment. Live mode can expose alternatives for hierarchy or spacing in the real layout. The detector can still check contrast, undersized text, or design-system drift. A critique can ask whether the label is understandable to a first-time user and whether the action appears at the right moment. No single artifact designs the button. Together they prevent the button from being an arbitrary rectangle whose only justification is that the model knows how to write one.
There is also an important claim boundary. The repository states what Impeccable is designed to do, but its product record names no customer testimonials, quantified outcome studies, pricing evidence, or deployment claims. The source supports a careful account of the mechanisms and their intended trade-offs. It does not support saying that the system has already improved every team's design quality, or that a clean scan proves a page is good. The distinction is not a footnote. It is an example of the same discipline Impeccable asks an agent to apply to product copy: say what the evidence actually supports.
The practical judgment this series supports is therefore conditional. Impeccable is most intelligible when a team wants an AI agent to work inside a durable product context, make visual decisions explicit, compare rendered alternatives, and catch repeatable implementation failures. It asks the team to supply more than a prompt. Someone must define or discover product truth. Someone must choose or preserve visual authority. A project must be runnable for live mode, and the host harness may change what hooks or provider-native features are available. Human review remains necessary wherever the question is about meaning, fit, or intent.
Before asking what Impeccable tells an agent to draw, ask what it refuses to let the agent forget. The answer is the product's purpose, the visual system's rules, the surface's job, the evidence behind a build, and the limits of a mechanical scan. The next chapter starts with that memory system: product truth first, visual authority second, and surface strategy where the two meet a real reader or user.