The event card passed every visual check we ran. We had rebuilt it from scratch that morning, and a teammate rejected it two hours later. The checks weren’t useless, but they were incomplete for the intended design and the layout around it.

The card wasn’t broken in any obvious way. It rendered, it loaded without errors, and it used the right component names. The composition was wrong. The icon appeared twice, once from the card template and once from a prior render pass we hadn’t cleaned up. Title height was unconstrained, so event names of different lengths pushed the price block to different vertical positions depending on the string. The color tokens for tier badges were close to the design but not exact, with four hex values off. Content density was too loose. The whole thing looked like it had been built from a description of the intended card instead of from the card itself.

A plausible rebuild

We gave Claude the existing markup, the ticket description, and a directive: rebuild the card to match the new pricing structure. The output was coherent and followed the existing patterns. It resembled the designer’s mockup the way a cover band resembles the original: same structure, same approximate timing, missing the details that made the original worth covering.

The title-height rule shows it best. The design says the title breaks at two lines maximum, and the price block sits at a fixed vertical position regardless of title length. That constraint isn’t in the ticket. You can’t derive it from the existing markup. It lives in the designer’s head, in a Figma annotation we never passed to the agent, and in the visual grammar the product built up over years before we touched it.

Claude built what the ticket said. The ticket didn’t say enough, and that was our mistake.

Five small fixes

The fix meant revisiting the card structure:

  1. Unify the icon path so only one source is active.
  2. Constrain title behavior to the intended design.
  3. Correct the color tokens against the design reference.
  4. Adjust spacing.
  5. Remove the duplicate template fragment.

Each change was small, and each needed knowledge of the exact design instead of an approximation of it.

The wrapper nobody mentioned

Once the card was correct, the page was still broken.

A shell-template wrapper carried a legacy max-width rule. At a wide viewport the card grid looked fine, but at an intermediate viewport the right column clipped. The defect sat in the surrounding layout constraint, and the card was fine.

The initial task didn’t include the shell template or a multi-viewport review. An AI assistant can inspect broader context when you give it that scope, but it can’t infer an undocumented wrapper constraint from a component-only ticket. We were testing at a wide desktop viewport, so we never saw the intermediate-width failure.

The CSS change was small. Finding it required a review that included the page shell and representative viewport widths. A colleague surfaced it in code review, which was exactly the control our component check had missed.

What would have closed the gap

We keep circling one question: what review artifact would have pushed the model toward the exact card structure on the first pass?

The strongest candidate is an annotated design reference with explicit constraints: title behavior, price alignment, color tokens, icon source, and duplicate-content rules. An AI assistant can apply a specification you supply, but a screenshot and existing markup alone may not expose every intended invariant.

Tighter prompting can’t fix the other half of this. The shell constraint was a scope problem. The ticket covered the component while the defect lived in the wrapper. Even a precise card specification still needs a page-level review that includes its real containers and representative viewport widths.

Both failure modes showed up in the same review cycle. One got better with a more explicit design specification, and the other with broader layout scope and multi-viewport verification.

When AI rebuilds a UI component, hand it the annotated design reference, including rules like title length and price position. Then make the review cover the page shell and more than one viewport width, since a correct component can still break inside its container. The assistant gives you a plausible first pass quickly. Correctness still depends on an explicit specification and on verification at the boundary between the component, its container, and the real user environment.