7 Anti-Generative Design Principles for AI-Assisted UI: Constrain, Delete, Iterate

AI can produce plausible-looking interfaces in minutes. The real challenge is preventing it from piling on more buttons, more copy, and more decoration until the product becomes a polished clutter room.

1. See the Whole: Design Is a Constraint–Solution–Review Loop, Not Patching

The author frames design as a three-step loop borrowed from Christopher Alexander's Notes on the Synthesis of Form :

List every constraint the design must satisfy.

Devise a set of solutions that meet all constraints simultaneously.

If any constraint needs adding, removing, or rewriting, return to step one.

Constraints include typography rules, required workflows, business-logic state branches, information hierarchy, permission boundaries, and loading conditions. The common failure is skipping step three and playing "design whack-a-mole": a user reports confusion, so a tooltip is added; a button lacks prominence, so a color layer is added; an action is hard to discover, so another entry point is inserted. Each fix feels like progress, but the interface gradually becomes a collage that randomly favors certain interactions.

The article illustrates a dense left sidebar where information and actions are crammed into a small space. Teams easily get pulled into spot-fixes for every piece of feedback, leading to loss of control. AI amplifies this temptation because it eagerly executes "make this area stand out" or "add an entry for this task" without questioning whether the information priority is broken. The result: every feedback item is implemented quickly, yet more users get lost.

A steadier approach is to triage feedback: obvious bugs and blockers get immediate fixes; minor friction and recurring discomfort are logged. When a refactor is due, they are fed back into the same constraint set for holistic resolution. Responding fast does not mean overreacting.

2. Delete Things: AI's Default Is Addition; Humans Must Own Subtraction

The original author states bluntly: "Agents like to add stuff; your job is to take the unnecessary parts away." In code this shows up as extra try-catch blocks, duplicate utility functions, or unnecessary abstraction layers. In UI it appears as superfluous explanatory lines, needless dividers, decorative icons, and badges that try to explain every state.

The output often looks more "designed" than a hand-crafted version, yet it still has problems: emphasis is diluted, rhythm is broken, users must constantly decode. The simplest review action is to look at each element and ask, "Does it really have to be here?" Not "does it look okay?" or "will it look empty if removed?" but "does it carry a clear job: aid understanding, drive action, establish hierarchy, or maintain system consistency?" If the answer is no, delete it first.

The author adds that deletion ability becomes a new baseline skill for product teams in the AI era. Because generation tools make "producing more" extremely cheap, the scarce skill becomes "knowing what should not appear."

3. Iterate in Design Tools, Not in the Live Product

Third principle is a process rule: do not iterate design directly in production code. Use a tool that allows fine-grained control, rapid experimentation, and does not require reloading the entire product context.

The author calls a hidden risk "prototype gravity." Once an agent has produced a first version in the real codebase, the team naturally feels "continuing on top of it is cheapest." Alternative directions disappear; all effort becomes polishing edges of the first version. Worse, the real codebase forces the agent to graft new ideas onto existing architecture, so solutions are constrained by implementation details from the start.

Tools mentioned include Figma, Cursor's design mode, Claude Design, emerging design tools, and HTML prototypes. The tool itself is not the point; the point is that they all provide a low-cost space for control and comparison.

A practical rule worth adopting: have the AI generate 3–4 distinct directions instead of treating the first version as the answer. The value is not merely "pick one" but forcing the team to articulate preferences. You may like A's information hierarchy, B's whitespace, C's interaction flow, or D's rhythm. When options are laid out, taste shifts from vague "feels wrong" to discussable judgment.

4. Use Components and a Component Library: Put AI's Local Capabilities into a System

"Separate view and logic, make components reusable" sounds like engineering common sense, but after AI joins interface production it becomes more critical. Every time an agent ad-hoc generates a button, a card, or a form section, it seeds a little visual drift.

The advice is direct: split view and logic, build reusable components. Only then does the application form a whole instead of being patched together from many re-implemented buttons.

The author's team maintains a /showcase page: the agent builds UI components there, tweaks and tests them in isolation, and only after confirmation are they integrated into the main product. This essentially puts guardrails on the AI. The agent can produce quickly, but it must first pass the component layer's constraints: sizing, states, spacing, boundaries, naming, interaction feedback. Thus generation speed does not directly turn into visual entropy.

5. Use Preview Deployments: Validate Design with Real Data

Design is easiest to fool with static mockups. Empty states, ideal copy, fixed screen sizes — once dropped into real scenarios they often deform immediately.

The author argues the best way to evaluate design is to plug in real data. Preview deployments let the team run the new interface against the real backend, use it hands-on, and share a link. Even if the agent follows instructions perfectly, it can still expose "something's off" under real content, real states, and real permissions.

For large features touching both frontend and backend, the team splits PRs: backend changes are verified by unit and integration tests; frontend still needs human judgment, and preview deployments make that judgment easier to perform.

This highlights an often-overlooked division: automation can prove "it runs," but not "it's usable." The interface ultimately must be held in hand and placed into concrete tasks to know whether it helps or just adds a prettier barrier.

6. Borrow Mature Solutions: Don't Reinvent Every UX Problem from Scratch

The sixth principle uses a colloquial phrase: Steal stuff. It's not endorsing plagiarism; it's reminding us that the vast majority of UX problems have already been solved elsewhere. Facing similar tasks, similar information, similar communication goals, we can study how mature products organize them and extract the applicable parts.

Good designers typically pull a stack of screenshots at project kickoff. They are not mood-board decoration; they are a "solution library": search, filter, navigation, empty states, complex forms, data density, error feedback — each screenshot offers concrete choices.

These screenshots also serve as high-quality context for AI. Instead of saying "make it feel like X style," show the agent the actual layout, copy density, hierarchy, and interaction relationships. AI understands abstract style words loosely; it executes seen structure more reliably.

The article includes a GIF recording the dynamic process of reference gathering (preserved as an animated image). However, there is a boundary: borrowing solves "does a more mature structure exist?" not "copy the surface skin." What truly transfers are information ordering, task paths, feedback mechanisms, and deletion restraint.

7. Cultivate Taste: It's Not a Persona, It's a Retrospective on Your Own Reactions

The final principle, and the hardest for tools to replace, is exploring your own taste.

The author defines taste as reflection on one's own reactions. An engineer can often point out "this design doesn't work" but may not know how to fix it. What's missing isn't critical ability but an experience-accumulated "solution library." There is no shortcut; it comes only through repeated trying, feeling, and retrospective.

The process can be joyful or brutal: designs are critiqued round after round until they're good enough. The author describes the team's method when no full-time designer existed as threshing: throw a design in the middle, everyone keeps beating it until it genuinely feels satisfactory.

Behind this metaphor lies an important fact: taste does not equal someone's innate "good eye." It is whether the team is willing to voice intuition, surface reactions, and preserve failures. AI can supply ever more candidates, but it will not build the standard for judging those candidates.

Closing: Treat AI as a Prolific Partner, Not the Design Arbiter

The seven principles compress into one sentence: AI expands possibilities; humans maintain order.

This is not anti-generation, nor a call to return to pure handcraft. Rather, it demands more active use of AI: let it produce variants, build components, set up previews, organize references. But every generation must be interrogated within the larger structure:

Which constraints does it satisfy?

Which hierarchies does it break?

Is this element truly needed?

Are there other directions worth comparing?

Does it still hold when dropped into real data and real tasks?

Only when humans keep asking these questions does AI become a design lever; otherwise it merely becomes a faster interface-filling machine.

Original article by @reactiverobot.