ASK KNOX
beta
Learn/Unchaining UI — Visual Testing with Claude/Lesson 324
LESSON 324

The Full Loop: Build, See, Fix, Verify

End-to-end walkthrough of a complete visual QA cycle: Claude Code builds a UI component, you inspect it, write a structured audit, Claude Code fixes it, and you verify.

12 min read·Unchaining UI — Visual Testing with Claude

Introduction

You have learned how to take screenshots and how to write a visual audit. But those skills only matter when they are connected into a repeatable production workflow. The Build-See-Fix-Verify loop is that workflow. It is what separates developers who vaguely feel like "the UI looks about right" from developers who can state with confidence that every visual requirement has been met and verified.

This lesson walks the full loop from start to finish using a real component example: a dashboard stats card with a chart placeholder and action buttons. By the end, you will have run the complete cycle at least once and have a template you can apply to every component you build going forward.

Core Concept: The Four Phases

The loop has four phases. They are sequential. Skipping any phase is how regressions slip through.

Phase 1: Build — Write the Spec

Claude Code cannot see your design file. It cannot feel your intuition about whether something looks right. Its only source of truth is the text you give it. If your spec is vague, the component will be vague. If your spec is precise, the component will be close to correct on the first build.

A production-quality build prompt includes:

Layout description. Not "make a card" but "make a card with a header row containing a metric label on the left and a trend badge on the right, a large number display in the center, a 160px tall chart area below, and a footer row with two action buttons side by side."

Color and surface values. "Background: bg-slate-800, border: border border-slate-700, header text: text-slate-400 text-sm, metric value: text-white text-3xl font-bold."

Breakpoint behavior. "At mobile widths below 640px, the two footer buttons stack vertically and take full width."

Example content. "Metric label: 'Total Revenue'. Value: '$48,291'. Trend badge: '+12.4% vs last month' in green. Chart is a placeholder div with bg-slate-700/50 rounded."

Constraints. "No animations yet. No real chart library yet. Use Tailwind only. No inline styles."

Here is a complete example build prompt you could use right now:

Build a StatsCard component in React with Tailwind CSS.

Layout:
- Outer card: bg-slate-800, rounded-xl, border border-slate-700, p-6
- Header row: flex justify-between items-start
  - Left: metric label (text-slate-400 text-sm font-medium)
  - Right: trend badge (text-emerald-400 text-xs bg-emerald-400/10 px-2 py-1 rounded-full)
- Metric value: text-white text-3xl font-bold mt-2
- Chart placeholder: h-40 bg-slate-700/40 rounded-lg mt-4 flex items-center justify-center
  with text-slate-500 text-sm "Chart placeholder"
- Footer: mt-4 flex gap-3
  - Primary button: flex-1 bg-indigo-600 hover:bg-indigo-500 text-white text-sm py-2 rounded-lg
  - Secondary button: flex-1 border border-slate-600 hover:border-slate-500 text-slate-300 text-sm py-2 rounded-lg

Props: label, value, trend, trendPositive (boolean), onPrimary, onSecondary, primaryLabel, secondaryLabel

Example usage:
<StatsCard
  label="Total Revenue"
  value="$48,291"
  trend="+12.4%"
  trendPositive={true}
  primaryLabel="View Details"
  secondaryLabel="Export"
/>

No animations. No chart library. Tailwind only.

This level of detail gives Claude Code what it needs to produce something inspectable on the first try.

Phase 2: See — Visual Inspection

Once the component renders, you inspect it. Do this in a consistent order every time. Consistency means you catch things in the same sequence and nothing gets skipped because you were focused on something else.

Inspection order:

  1. Layout structure. Does the overall shape match the spec? Are the rows, columns, and grid areas where they should be? Is the card width correct in context?

  2. Spacing. Internal padding, gap between elements, margin above and below. Squint at it — if anything looks cramped or too loose, measure it with DevTools.

  3. Typography. Are the font sizes, weights, and colors correct? Is the hierarchy legible — does the metric value visually dominate the label?

  4. Colors. Background, text, border, badge, button. Compare against your design tokens. Hover states: do they change?

  5. Interactions. Hover the buttons. Do they respond? Are the hover state colors correct?

  6. Edge cases. Plug in long text: "Average Customer Acquisition Cost Per Qualified Lead". Does it overflow, truncate, or wrap correctly? Try a negative trend value. Try a very long number.

Take a screenshot at this stage. You will compare this against the post-fix screenshot. This before/after comparison is your verification proof.

Phase 3: Fix — The Audit Handoff

Write a structured audit report and paste it into Claude Code. Structure matters here because Claude Code processes a prioritized list more reliably than a paragraph of complaints.

Use this format:

Visual audit for StatsCard — fix these issues in order of severity.

CRITICAL (breaks layout):
1. Footer buttons are stacking vertically at all widths, not just mobile. They should
   be side-by-side (flex-row) on desktop and stack on mobile (<640px).

HIGH (wrong spec):
2. Trend badge background is missing. "text-emerald-400" is correct but bg-emerald-400/10
   is not rendering — check if the opacity modifier is being applied.
3. Chart placeholder height is rendering as ~60px, not h-40 (160px). Verify the parent
   has a defined height context.

MEDIUM (visual polish):
4. Header label text appears to be text-slate-300 not text-slate-400. Should be slightly
   more muted.
5. Gap between metric value and chart placeholder is too tight — increase mt-4 to mt-5.

LOW (minor):
6. Primary button hover state is barely visible. Verify hover:bg-indigo-500 is in the
   safelist or not being purged.

Fix only these items. Do not change anything else.

The last line is not optional. Without it, Claude Code may "helpfully" refactor spacing throughout the component, change your Tailwind class naming patterns, or restructure the component tree in ways that introduce new issues.

Phase 4: Verify

After Claude Code returns the fixes, re-render the component and re-inspect using the same order from Phase 2.

For each finding in your audit:

  • Is it resolved? Mark it done.
  • Did the fix introduce a regression? If the footer buttons are now correct but the primary button lost its background color, that is a regression.
  • Are there new issues that were not present before?

Take a second screenshot. Compare it side-by-side with your Phase 2 screenshot. This before/after proof is how you demonstrate the iteration worked.

Practical Application: Dashboard Card Walkthrough

Here is a real iteration trace showing what this looks like in practice with timestamps.

13:02 — Build prompt submitted. Full spec as above.

13:03 — First render. Component appears. Layout is mostly correct. Footer buttons are stacking. Trend badge has no background. Chart placeholder is 60px tall.

13:04 — Phase 2 inspection complete. Found 6 issues. See audit above.

13:06 — Claude Code returns fixes. Buttons are now flex-row gap-3. Badge has bg-emerald-400/10. Chart is h-40.

13:07 — Phase 4 verification. 5 of 6 issues resolved. One regression: the secondary button border is now missing entirely (border border-slate-600 was dropped in the fix). One original issue (item 4, label color) not addressed.

13:08 — Loop 2 audit:

Two remaining issues from previous audit:

1. Secondary button is missing its border. Should be: border border-slate-600
   hover:border-slate-500
2. Header label color should be text-slate-400 not text-slate-300

Also one regression introduced in last fix:
3. Chart placeholder text "Chart placeholder" is no longer centered —
   the flex items-center justify-center may have been removed.

Fix only these three items.

13:09 — Loop 2 fixes applied.

13:10 — Verification. All issues resolved. No regressions. Component matches spec.

Total time: 8 minutes. 2 loops.

The Iteration Budget

Most components converge in 2–3 loops. This is normal. Claude Code is not writing broken code — it is writing code that needs visual feedback to calibrate, which is information it cannot access without you.

Loop 1: Major structural issues. Layout, spacing, broken states.

Loop 2: Polish. Colors, edge cases, hover states, minor regression from loop 1 fixes.

Loop 3 (if needed): Fine-tuning. Pixel adjustments, interaction refinement.

If you are at loop 4 or 5 with major issues still open, stop. The component is either too complex or your spec was too vague. Break it into sub-components and spec each one separately, or go back and rewrite the spec with more precision before continuing.

Real numbers from production usage:

  • Average visual issues found per fresh component: 3–7
  • Average loops to convergence: 2–3
  • Average time per loop (inspect + audit + fix + verify): 5–10 minutes
  • Total time to converge: 10–30 minutes per component

These numbers assume a well-written spec. A vague spec doubles or triples loop count.

Common Mistakes

Submitting findings as prose, not a list. "The buttons look weird and the colors are off and also I think the spacing is too tight" gives Claude Code no way to prioritize or isolate fixes. Use the numbered, severity-sorted format.

Not taking the before screenshot. Without before/after, you have no verification proof. You are relying on memory to confirm fixes, which is unreliable.

Asking for multiple components in one prompt. Build one component per loop. If you need a card, a table, and a modal, do them sequentially. Each has its own loop.

Skipping edge case testing. A component that looks correct with short text and round numbers will often break with real production data. Always test long strings and edge values before closing the loop.

Accepting "mostly fixed." If 5 of 6 issues are resolved, the loop is not done. Feed the remaining issues back. Partial convergence compounds — next loop's audit will mix new issues with holdovers.

Summary

The Build-See-Fix-Verify loop is the production workflow for visual QA with AI-generated UI. Its power is in its structure: every phase has a clear input and output, and the loop terminates when all issues are resolved with no regressions.

Phase 1 produces a renderable component from a precise spec. Phase 2 produces a list of visual findings. Phase 3 converts those findings into a structured handoff Claude Code can act on precisely. Phase 4 confirms each fix and checks for regressions. Then you either close the loop or start the next iteration.

Most components converge in 2–3 loops in under 30 minutes. That predictability is why this workflow exists.

What's Next

The next lesson applies the loop to a new dimension: responsive behavior. A component that converges perfectly at 1440px can break catastrophically at 375px, and Claude Code will not know unless you check. The next lesson teaches you how to run device-aware visual QA across multiple breakpoints and feed viewport-specific findings back to Claude Code with the context it needs to apply fixes in the right media query.

Exercise

Build a complete page layout using only Claude Code prompts. The page should include:

  • A fixed top navigation bar with a logo placeholder, two nav links, and a user avatar
  • A left sidebar with four nav items and an icon placeholder for each
  • A main content area with two StatsCard components side by side (use the spec from this lesson)
  • A footer with copyright text

Run the full loop:

  1. Write the build prompt with full layout and color spec
  2. Screenshot the result
  3. Write a structured audit with severity ordering
  4. Feed back with "Fix only these items"
  5. Screenshot after fixes
  6. Document: how many loops, how many issues per loop, total time

Save your before and after screenshots. They are your verification proof.