20 Signs Your UI Looks Vibecoded, and How to Audit It

Coding agents can assemble a complete interface quickly. Speed does not stop the result from looking like dozens of unrelated products: the same purple gradient, glossy headline, three identical feature cards, vague marketing copy, and motion that does nothing for the user’s task.

That sameness is not only an aesthetic complaint. It can weaken brand recognition, flatten information hierarchy, hide incomplete interaction states, and ship poor contrast behind polished screenshots. I built Anti-Vibecoded UI to turn the joke into a repeatable review method.

The skill is open source on GitHub under MIT and follows the open Agent Skills specification. One source can be installed in Codex, Claude Code, Cursor, OpenCode, and other compatible agents.

What does “vibecoded UI” mean?

It does not mean that AI-assisted work is inherently bad. It does not mean every gradient, card, icon, or animation should disappear. A UI looks vibecoded when an agent reaches for fashionable defaults without deriving them from the product, audience, content, or task. You could move the interface to another company and very little would need to change.

The useful question is not “Does this page contain a gradient?” Ask instead:

• Does the gradient express an established brand or a meaningful state?
• Can a user identify the primary action quickly?
• Did the card structure come from the content, or from a three-column template?
• Do contrast, keyboard focus, and reduced-motion behavior work?
• Was the result inspected in the real interface or only admired in one screenshot?

The 20 signals

The skill asks the agent to check whether the interface relies on these patterns as defaults:

1. Purple-to-blue gradients without a brand or content reason.
2. Gradient hero text used as a substitute for hierarchy.
3. Emojis in headings that do not match the product voice.
4. Inter everywhere without considering the brand, language, or reading context.
5. Colored borders used to differentiate otherwise identical cards.
6. Glassmorphism cards that weaken legibility or structure.
7. Low-contrast dark mode.
8. A compulsory row of three generic icon feature boxes.
9. A decorative badge above every headline.
10. Lucide icons everywhere, including where text or a product-specific symbol is clearer.
11. Untouched shadcn UI or another component library with default tokens and composition.
12. Repetitive fade-in-on-scroll animation.
13. Cursor-following beams or spotlights unrelated to the task.
14. Buttons that fade or lose contrast on hover.
15. Inconsistent spacing without a deliberate scale.
16. Em dashes used so often that the copy develops a synthetic rhythm.
17. Generic buzzword copy that could describe any product.
18. Serif italic accents added as a fashionable flourish rather than a meaningful voice.
19. Space Grotesk paired with Instrument Serif by default.
20. Grain laid over a gradient without a visual or narrative purpose.

This is not an automatic verdict. Several of these choices may be exactly right for a particular product. The list exists to force a reasoned decision.

What the skill requires for each finding

“This looks AI-generated” is not actionable feedback. For every relevant signal, the skill requires four steps:

1. Point to the concrete screen, component, selector, or screenshot region.
2. Explain the user or brand impact instead of condemning a pattern because it appears on a list.
3. Keep it when it is intentional and effective, or replace it with a solution derived from the product’s content and design system.
4. Check the change in context so a cosmetic fix does not create weaker hierarchy, accessibility, or consistency elsewhere.

The result is a review a designer or developer can act on and verify, not a floating opinion about taste.

Install it in all your agents

With Node.js and npx available, install the skill globally for every agent detected by the skills CLI:

npx skills add yasircs4/anti-vibecoded-ui -g -a '*' -s anti-vibecoded-ui -y

For Codex only:

npx skills add yasircs4/anti-vibecoded-ui -g -a codex -s anti-vibecoded-ui -y

For Claude Code only:

npx skills add yasircs4/anti-vibecoded-ui -g -a claude-code -s anti-vibecoded-ui -y

The official skills CLI documentation covers GitHub sources, global installation, and agent or skill selection. The portable SKILL.md stays small, so each tool does not need a separately maintained prompt.

Example: audit without changing the code

Give the agent a clear scope and stopping point:

Use anti-vibecoded-ui to audit the attached screenshots and current runtime.
For every relevant signal, cite the exact screen and component, explain its
impact, and separate intentional brand choices from generic defaults. Stop
after the findings; do not edit the project.

For implementation, name the platforms, viewports, and states that count as done:

Use anti-vibecoded-ui while rebuilding this checkout.
Preserve accessibility and the existing design system, then verify the
rendered result at mobile and desktop sizes, including loading, error,
disabled, focus, and reduced-motion states.

The completion bar matters more than the list

Removing gradients does not make an interface good. The skill’s completion bar requires a clear task hierarchy, product-specific copy, consistent tokens, accessible contrast and interaction states, and responsive behavior.

It also requires evidence. Work is “verified” only after inspecting the closest real rendered runtime at representative sizes. If that did not happen, the agent must say verification is still pending.

Why publish this as an open skill?

Guidance buried in one chat disappears. A skill is versioned, reviewable, and portable. Anyone can inspect the instructions before running them, open an issue for a false positive, or propose an improvement backed by a real interface.

The public repository includes the core skill, Codex metadata, Arabic and RTL prompts, and examples for audits, redesigns, and pull request reviews. Start at the Anti-Vibecoded UI repository, install it, and run it against a real product. The most useful contribution is not another fashionable prohibition. It is a clearer rule for turning product context and rendered evidence into a better design decision.