The event card for ITEM-6684 passed every visual check I ran. I had rebuilt it from scratch that morning. David rejected it two hours later.
Not because it was broken. The card rendered, it loaded without errors, and it used the right component names. But composition was wrong. The icon appeared twice: once from the card template, and once from a prior render pass I had not 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. Four hex values were off. Content density was too loose. The whole thing looked like something built from a description of the intended card, not from the card itself.
That distinction is the whole story.
the problem with plausible
I gave Claude the existing markup, the JIRA ticket description, and a directive: rebuild the card to match the new pricing structure. The output was coherent. It followed the existing patterns. It built something that resembled David’s design 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 invariant is a good example of what I mean. David’s design has a rule: the title breaks at two lines maximum, and the price block sits at a fixed vertical position regardless of title length. That constraint is not in the ticket. It is not derivable from the existing markup. It lives in David’s head, in a Figma annotation I did not pass to the agent, in the visual grammar of the product that accumulated over years before I touched it.
Claude built what the ticket said. The ticket did not say enough. My mistake, not the agent’s.
the rebuild, not the tweak
The fix was not a patch. I went through the card structure and unified the icon path so only one source was active, added min-height and line-clamp to pin the title behavior, corrected four hex values against David’s spec, tightened the padding by 8px on each side to match content density, and removed the duplicate template fragment.
Five changes. Each one small. Each requiring knowledge of the exact design, not an approximation of it.
the constraint no one told the agent
Once the card was correct, the page was still broken.
The .contentFrameWrapper class in the shell template carries a max-width: 980px rule. It predates my ownership of the codebase by years. At 1200px viewport width the card grid looked fine. At 1050px the right column of cards was clipping. That range is where a significant share of my users actually sit.
The agent had no way to know this. The shell template was outside the ticket scope. The visual artifact only appears at a specific viewport range. I was testing on a 2560px monitor that Saturday afternoon and never saw it.
Removing the cap was a one-line CSS change. Finding it required a human noticing the layout break at a specific breakpoint and knowing to look for a global width constraint. Claude did not surface it. David did, in code review.
what would have closed the gap
I keep circling the same question: what review artifact would have forced the model toward David’s exact card structure on the first pass?
The honest answer is a screenshot of the intended design annotated with the invariants. Not “looks like this” but “title max two lines, price pinned at Y position, these four hex values, one icon, no duplicate.” The agent can execute a spec. It cannot reverse-engineer one from an approximation of the original.
There is also a version of this problem that better prompting cannot fix. The .contentFrameWrapper constraint was not a prompt problem. It was a scope problem. The ticket covered the component. The bug lived in the shell. You can write a perfect card spec and still ship a broken page if the thing wrapping the card has undocumented constraints that only surface at 1050px.
Both failure modes showed up on the same Saturday. One was recoverable with a tighter prompt. One required a human who had looked at the page across multiple viewport widths.
The person who owns the product still has to specify the exact shape of correct, and then verify it at the edges where the spec ends and the legacy constraints begin.