AI website review for vibe-coded layout and typography

Review a vibe-coded website with a practical checklist for layout, type choices, hierarchy, spacing, and the next changes worth making.

ai website review for vibe coded website layout and typography

Contents

  • [Start with the highest-value checks](#start-with-the-highest-value-checks)
  • [Fix layout before visual effects](#fix-layout-before-visual-effects)
  • [Make typography a deliberate system](#make-typography-a-deliberate-system)
  • [End with five verifiable changes](#end-with-five-verifiable-changes)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

An AI review of a vibe-coded website should check layout and typography together, then turn the findings into a short, ordered fix list. Start with hierarchy, content width, spacing rhythm, type scale, and the way headings, body copy, labels, and controls work as one system.

Start with the highest-value checks

Use this order so decorative polish does not hide structural problems:

  1. Page hierarchy: Can someone tell what the page is about, what to do next, and why it matters within a few seconds? Check the first screen, headline, supporting copy, primary action, navigation, and section order.
  2. Layout structure: Check maximum content width, alignment edges, column proportions, section spacing, and behavior at narrow widths. Repeated left edges usually make a page feel intentional. Unrelated alignment lines make it feel assembled.
  3. Typography: Check whether headings, body copy, labels, buttons, and supporting details have clear roles. Look for too many families, weak size differences, tight line height, long text measures, or awkward heading wraps.
  4. Repeated components: Compare cards, buttons, inputs, badges, and navigation items. Their padding, corners, borders, and text alignment should feel related.
  5. Responsive behavior: Reduce the viewport and look for overflow, cramped columns, oversized headings, broken line lengths, and actions that become difficult to reach.

Compare the first screen with the examples below before borrowing a pattern. The captured Linear reference lists Inter Variable, Berkeley Mono, and Tiempos Headline. That is a reference observation, not a rule that your site should copy.

Captured pages

Fonts captured on linear.app

Fix layout before visual effects

Set a readable content width first. Then create a spacing scale with small gaps for labels and controls, medium gaps inside cards, and larger gaps between sections. Reuse the scale instead of choosing a new margin for every block.

Check the first screen at desktop and mobile widths. The main action should remain obvious, the headline should not occupy most of the screen, and supporting content should not compete with it. If a section feels busy, remove competing emphasis before adding gradients, shadows, or animation.

Write each finding in an implementation-friendly format:

  • Observation: The hero has three competing actions.
  • Impact: Visitors may not know which path to choose.
  • Change: Keep one primary action and make the others quieter links.
  • Priority: High.

Repeat this for every important issue. It keeps feedback specific and easy to implement.

Make typography a deliberate system

Use one primary family unless another face has a clear job. A compact sans-serif system can create contrast through size, weight, and muted color rather than many typefaces. The captured Linear example shows Inter used for body copy, labels, navigation, controls, headings, and emphasized interface text. Use that as a comparison point, not as a prescription.

Check that headings have a clear jump from body copy, body text is comfortable to scan, metadata is smaller without becoming faint, buttons have enough weight and contrast, and line height changes with text size. Also check whether font loading changes wrapping or causes visible layout shifts.

If you use a second face, give it one defined role such as code or editorial display text. Do not add it merely because the page feels plain.

End with five verifiable changes

Finish with no more than five first-pass changes. For example: narrow the content measure, remove one hero action, standardize card padding, define four text styles, and test mobile navigation. Mark each change high, medium, or low priority and name the exact section where it applies.

Recheck clarity, alignment, wrapping, and consistency after implementation. A useful review explains what to change, why it matters, and how to tell whether the next version is better.

Use this in your AI agent

> Review my vibe-coded website for layout and typography. Check the first screen, hierarchy, content width, alignment, spacing rhythm, responsive behavior, font families, type scale, line height, wrapping, and repeated components. Compare the captured Linear reference only where it explains a practical pattern. Return the five highest-priority changes, each with an observation, user impact, exact suggested change, and priority. Separate structural fixes from optional visual polish.

You can install Fudge for your AI agent to run this review against a captured page and relevant saved references.

How should I review a vibe-coded landing page differently from a dashboard?

For a landing page, review persuasion and sequence first: headline clarity, supporting proof, primary action, section order, and whether each section answers the next likely question. The first screen should give visitors one obvious next step, while later sections should reinforce it.

For a dashboard, review speed and repeat use first: navigation, information density, scanning order, table or card consistency, control placement, empty states, and feedback after an action. A dashboard can be denser than a landing page, but density should be grouped and predictable.

Use different typography checks too. Landing pages can use a stronger display scale if wrapping remains controlled. Dashboards usually benefit from smaller, steadier text styles with clear differences between titles, labels, values, and metadata. In both cases, test narrow widths and inspect repeated components. The question is whether the same decisions remain understandable as the page changes.

What should I give an AI agent so it can review my website accurately?

Give the agent the page URL or a browser capture, the intended audience, the page's main action, and constraints such as an existing brand font or component library. If multiple states matter, include desktop and mobile versions, signed-in screens, and open menus or dialogs.

Ask for evidence-based output. Name the areas to check: first-screen hierarchy, content width, alignment, spacing, responsive behavior, font family, size, weight, line height, contrast, and repeated components. Ask the agent to separate observations from recommendations and rank changes by impact and effort.

Require an implementation list rather than a list of adjectives. Each item should include an exact location, likely user impact, proposed change, and a simple verification check. Include one or two references and ask for comparison of a specific pattern, such as typography hierarchy or card spacing, instead of imitation of an entire site.

Related questions