How to audit and fix AI-generated UI

An AI UI audit cannot prove who or what created a website. It can show where the interface relies on generic decisions, weak product logic, inconsistent components, missing states, and code that does not follow the project’s system.

The finished audit should not say “this looks AI-generated.” It should identify the exact problem, show evidence, explain the user impact, assign severity, name the system level, propose a fix, and define how to verify that fix.

This Guide audits two connected incident-management routes, turns the findings into a repair plan, and verifies the repaired product. Use How to make UI not look AI-generated when you are ready for a complete page-by-page rebuild.

What the audit produces

For every finding, record:

Example:

This format turns a visual opinion into work another person or agent can verify.

Before you start

You need:

• two or more connected routes
• the primary user and outcome for each route
• realistic populated data
• loading, empty, error, success, permission, and long-content states
• renders at 1440px, 768px, and 390px
• keyboard access to the main workflow
• the source components, tokens, and styles
• one relevant system from the InterfaceKit library

Use two routes because a single page can hide system drift. A generated page may look coherent by itself while using a different frame, type scale, button, badge, or empty state from the next page.

The running example uses:

• /incidents for finding and filtering active incidents
• /incidents/:id for investigating, acknowledging, and resolving one incident

The primary user is an on-call engineer. The outcome is to find a high-impact incident, understand its current state, and take the next safe action.

Step 1: Write the product baseline

You cannot audit hierarchy or action priority without knowing what the product must help the user do.

Write a short baseline:

List route: /incidents
Outcome: Find the incident that needs attention now
Required data:
- Severity
- Status
- Service
- Summary
- Started time
- Owner
- Last update
Primary action: Open incident

Detail route: /incidents/:id
Outcome: Understand current impact and take the next safe action
Required data:
- Severity and status
- Affected services
- Timeline
- Current owner
- Customer impact
- Recent updates
Primary action: Acknowledge or resolve, based on state and permission

Rules:
- Viewers cannot acknowledge or resolve
- Resolved incidents cannot be acknowledged
- Resolution requires a note
- Pending actions cannot submit twice
- Stale incident data must reload before mutation

Breakpoints: 1440px, 768px, 390px

This baseline is the standard for product fit. A section that does not support the outcome needs a reason to stay.

Step 2: Build the audit matrix

Capture the same routes across representative states and widths:

Use the same data at each width. Record the viewport, route, fixture, and timestamp beside each screenshot.

Also capture:

• open menus
• dialogs
• validation messages
• focus states
• loading transitions
• long service names
• large incident collections
• network or console failures

Do not audit only the screenshot that was used to approve the first design.

Step 3: Separate detection from proof of authorship

Is there a way to tell if a website is AI generated? Not reliably from appearance alone.

Human teams use templates, trends, and design systems. AI-assisted teams can produce careful work. A rounded card, gradient, centered hero, or familiar font does not prove authorship.

The audit can identify a pattern that often makes a website look AI-generated:

• the structure could belong to almost any product
• decorative styling hides weak information priority
• content sounds plausible but does not match the workflow
• repeated components change between routes
• important states and permissions are missing
• responsive behavior only compresses the desktop layout
• the source contains duplicate or arbitrary implementations

Report the pattern, not an unsupported claim about who made it.

Read What makes a website look AI-generated? for the diagnostic tests behind this distinction.

Step 4: Use four severity levels

Rank findings by user impact:

A disliked gradient should not outrank an action that submits twice.

When a finding affects several routes, increase its priority even if the local symptom looks small. A broken shared component can cause more damage than a severe-looking page-specific detail.

Step 5: Audit product fit

Start with the product, not the palette.

For each section, ask:

1. Which user decision does this support?
2. Which required data does it show?
3. Which action does it enable?
4. Which state changes its meaning?
5. What would become harder if it were removed?

Flag:

• metrics with no role in the workflow
• generic cards added only to fill the page
• repeated summaries that hide the actual queue
• labels that do not use the product’s language
• actions without permission or state rules
• important information postponed to a tooltip or hidden panel

For the incident list, “Total incidents this month” may be useful in reporting but not during urgent triage. If it pushes active incidents below the fold, it weakens the page outcome.

Record the finding:

Location: /incidents, populated, 1440px, summary cards
Evidence: Four metrics occupy the first 280px. None changes the queue or helps
identify the incident needing attention.
Impact: The active incident list starts below the initial viewport.
Severity: High
System level: Page
Fix: Remove the decorative summary row from the triage route.
Verify: The highest-severity active incident is visible at initial load.

Step 6: Audit structure, hierarchy, and density

Temporarily ignore color, shadows, gradients, and illustration.

Check:

• application frame
• content rail and maximum width
• navigation behavior
• page header
• primary and secondary regions
• reading and scan order
• action placement
• grouping through spacing
• information density

Use a decoration-off test:

1. Remove card backgrounds, shadows, and decorative color in a temporary review.
2. Keep typography, spacing, and alignment.
3. Check whether the page structure still makes sense.

If every region needs a card to explain its grouping, the hierarchy may be weak.

For operational pages, check how much useful information fits without becoming unreadable. Too much empty space can be as harmful as overcrowding.

Example finding:

Location: /incidents, populated, 768px, incident rows
Evidence: Each row uses 112px of height because labels repeat above every value.
Impact: Only three incidents fit before scrolling, slowing comparison.
Severity: High
System level: Block
Fix: Use a stable column or compact metadata pattern from the selected reference.
Verify: Six realistic rows remain readable at 768px without hidden severity.

Step 7: Audit the interface system

Inventory the decisions that should repeat across routes.

Foundations

Record:

• type sizes, weights, and line heights
• spacing values
• content widths and gutters
• control and row heights
• semantic colors
• border widths and contrast
• radius values
• shadows
• icon families and sizes

Group near-duplicates. Look for local values that have no clear role.

Components

Inventory:

• buttons
• links
• fields and selects
• tabs
• tables or resource lists
• badges
• menus
• dialogs
• notices
• loading and empty states

Use a consistency table:

Do not consolidate components only because they look similar. Confirm that their behavior and semantic role are also the same.

Cross-page rules

Check whether:

• the same severity means the same thing
• actions occupy predictable locations
• filters use the same interaction pattern
• page widths and gutters remain stable
• loading and error states preserve context in the same way
• mobile transformations follow the same priority

Prompt-by-prompt generation often creates local consistency and global drift. The second route exposes it.

Step 8: Audit states, interaction, and accessibility

Open every state in the matrix. Do not infer state quality from component names.

Check:

• initial loading
• background refresh
• initial empty
• filtered empty
• request error
• partial data
• stale data
• success feedback
• pending action
• disabled action
• permission restriction
• long content
• large collection

For each missing or weak state, record the user consequence.

Weak:

No error state.

Useful:

When the incident timeline request fails, the details panel becomes blank and
offers no retry. The engineer loses the incident summary and cannot recover
without reloading the route.

Complete the main workflow with a keyboard. Check semantic controls, focus order, visible focus, menu and dialog focus management, Escape behavior, validation, and announcements for changing status.

Use the WCAG 2.2 Quick Reference when an accessibility finding needs a specific success criterion. Do not treat accessibility as a final polish pass.

Step 9: Audit the responsive product, not only the layout

Review at 1440px, 768px, and 390px.

At each width, ask:

• Is the same user outcome still clear?
• Does the most important data stay visible?
• Do primary and secondary actions keep their order?
• Does the list use a deliberate mobile strategy?
• Do overlays fit and keep focus?
• Do sticky regions hide content?
• Can long labels wrap without covering actions?
• Is there horizontal scrolling where it is not part of the product?

Mobile should not be a squeezed desktop page.

For the incident list, a narrow layout might keep severity, service, summary, and age visible while moving owner and recent-update details into the opened row. Hiding severity because it does not fit would reverse the product priority.

Step 10: Audit the code behind the UI

How do you make code look less AI-generated? Do not rewrite it to conceal who created it. Make it clear, maintainable, and consistent with the repository.

Inspect:

• duplicated components with small visual differences
• repeated literal colors, spacing, and dimensions
• wrappers that do not add layout, semantics, or behavior
• dead props and unused state
• placeholder copy left in production paths
• one-off mobile components that duplicate desktop logic
• event handlers that bypass the existing data layer
• missing permission checks
• optimistic states with no rollback
• comments that repeat the code instead of explaining a decision
• tests that cover only the populated happy path

Trace one workflow from route to data request, component state, user action, mutation, feedback, and recovery. The code should explain how the product works.

Example:

Location: IncidentRow, IncidentHeader, IncidentTimeline
Evidence: Each file defines its own severity-color map with different labels.
Impact: Severity meaning changes across the list, detail header, and timeline.
Severity: High
System level: Component and foundation
Fix: Create one semantic severity definition and reuse the existing badge.
Verify: Component tests cover every severity and both routes render the same label.

Quality is the goal. Cosmetic changes to naming or formatting do not fix weak logic.

A practical AI slop website example

Consider the incident product before the audit:

• The list opens with four generic metric cards.
• Every incident sits in a large rounded container.
• Severity uses color without a stable label.
• The detail route uses a different header and spacing scale.
• The Resolve action appears for viewers and resolved incidents.
• Loading replaces the whole page with a spinner.
• Request failure leaves a blank panel.
• The mobile page hides severity and pushes actions off screen.
• Three components define different status colors.
• The code contains repeated local values and an unused chart package.

What do AI slop websites look like? They often look finished in the approved screenshot but become generic, inconsistent, or incomplete when you inspect another route, an uncomfortable state, or the source.

How do you know if something is AI slop? Look for output that was accepted without enough product judgment, verification, or ownership. The label describes the unresolved result, not the mere use of AI.

Read What is AI slop in UI design? for the fuller definition and limits of the term.

Step 11: Turn findings into a repair plan

Do not repair findings in screenshot order. Group them by system level:

## Product behavior
- Enforce acknowledge and resolve permissions.
- Add stale-data protection before mutation.
- Prevent duplicate pending actions.

## Foundations
- Define one severity color and text mapping.
- Consolidate content widths, gutters, and spacing values.

## Components
- Reuse one severity badge across list, header, and timeline.
- Replace the local detail overlay with the shared dialog.
- Add retry behavior to the shared error state.

## Blocks
- Standardize page header and filter composition.
- Create one responsive incident-row pattern.

## Page-specific
- Remove summary cards from the triage route.
- Move secondary detail actions into the existing menu on mobile.

Then order the work:

1. Critical permissions, workflow, accessibility, and recovery
2. Product structure and hierarchy
3. Shared foundations
4. Shared components and blocks
5. Missing states and responsive behavior
6. Page-specific content and polish

Fixing foundations and shared components before page polish reduces repeated work.

Step 12: Give an agent the audit, not a vague reaction

Use this prompt:

Read the approved audit findings before editing.

Fix only the critical and high-severity findings in this pass.
Follow the ordered repair plan:
1. Permissions and stale-data behavior
2. Page structure and action hierarchy
3. Shared severity definition and badge
4. Responsive incident row
5. Missing recovery states

Preserve existing routes, API contracts, analytics, and keyboard behavior.
Use the selected InterfaceKit references and current project tokens.
Do not add a new UI, CSS, icon, or chart library.

Make every affected state reachable.
Run the project checks and the audit matrix at 1440px, 768px, and 390px.
Report each finding as fixed, still open, or deliberately deferred with evidence.

Use a separate pass for medium and low findings after the workflow remains stable.

Step 13: Verify the repaired system

Repeat the original audit matrix with the same routes, fixtures, data, and viewport sizes.

For every finding:

• open the recorded location
• perform the original failing action
• compare the same state
• confirm the user impact is removed
• run the relevant test
• check for regressions on the second route

Use a closure table:

Do not mark a finding fixed because a file changed.

Direct answers to common audit questions

Is there a way to tell if a website is AI generated?

Not reliably from appearance alone. You can identify generic patterns, missing judgment, inconsistent systems, and unfinished states. You cannot use those signs as proof of authorship.

What do AI slop websites look like?

They often combine interchangeable structure, plausible but shallow content, decorative containers, inconsistent components, and incomplete product states. The problems become clearer across connected routes and non-happy states.

How to know if something is AI slop?

Check whether the output fits the actual product, follows one system, covers important states, works across widths, and has been meaningfully reviewed. AI-assisted work is not automatically slop.

How to identify AI slop without relying on taste?

Record observable evidence, user impact, severity, system level, fix, and verification. Avoid claims based only on a familiar font, gradient, card style, or visual trend.

How do I make my code look less AI-generated?

Align it with the repository. Remove dead and duplicated code, reuse components and tokens, preserve semantic structure, make permissions and state transitions explicit, and add tests for failures and edge cases. Do not disguise authorship. Improve quality.

How do I make UI not look AI-generated?

Replace generic product, structure, content, component, and state decisions with specific ones. Fix critical behavior and shared system issues before page-level decoration.

Final audit checklist

• Two or more connected routes were reviewed
• The user outcome and product rules are written
• Populated and uncomfortable states are reachable
• 1440px, 768px, and 390px use the same realistic data
• Keyboard and focus behavior were tested
• Findings include location and observable evidence
• Every finding states user impact and severity
• Foundations and repeated components were inventoried
• Cross-page drift was recorded
• Responsive product priority was checked
• The code path behind the workflow was inspected
• Fixes are grouped by system level
• Repairs are ordered by user impact
• The original audit matrix was repeated
• Closed findings include verification evidence
• Deferred findings include a reason

Use the UI prompting workflow to give an agent the correction plan. Use How to make UI not look AI-generated for the full repair sequence.