AI Site Builder Self-Review Passed, But Browser QA Caught 4 Critical Bugs

An AI agent spent an afternoon building two fictional storefronts—a Warsaw watchmaker and a micro font foundry. It wrote the pages, ran them in a browser, and declared its work clean. But then we did something most AI-generated work never experiences: we graded it.

We call this process the "acceptance gate": a fixed pass/fail checklist executed item by item against the actual page at three breakpoints. Not "make it look premium," but a hard standard the AI can't bluff its way past.

The result: four problems were caught in work the same model had already signed off on.

Self-review is a rubber stamp; QA is the mirror that reveals the truth

Why can't AI self-checks be trusted? Because they evaluate intent, not the finished product. The model remembers it "intended" to place a responsive buy bar, "intended" to respect reduced-motion preferences, "intended" to make fonts adaptive. It's checking the blueprint in its head, not the actual DOM on screen that throws the price out of the viewport at 375px.

The four caught bugs each land squarely in the crack between "good intentions, broken product":

• A hero section where a table belonged. The watch page opens with an emotional headline, but what visitors actually need at that moment is a spec table: movement, case size, price. The page looks good but answers nothing.
• The buy bar collapsed at the 375px breakpoint. On mobile, the price floated off screen. Only one viewport was checked, and the layout happened to fit only that one width.
• The reduced-motion fallback wasn't actually "still." prefers-reduced-motion was honored—with a frozen frame that happened to stop mid-rotation. Motion-sensitive users saw a broken still, not a calm image.
• Auto-scaling fonts only fit short inputs. The font foundry's signature renderer typeset demo words beautifully, but real names overflowed their containers. The happy path shipped.

None of these are "AI can't design." They're all "nobody ran QA after the AI delivered"—and AI self-review is, at its core, stamping intent, not reality.

prefers-reduced-motion is a user preference exposed via CSS media query: when a user enables "reduce motion" at the OS level, the browser surfaces that flag to the page. Frontend developers should use it to disable or replace translation animations, parallax scrolling, and autoplay carousels. The common mistake is "freezing the current frame"—pausing the animation without resetting to the start—so the visual may stop mid-rotation, half-zoomed, or mid-fade. For users with vestibular disorders or motion sensitivity, this "broken still" can be more uncomfortable than continuous animation. The correct fallback is to remove animation entirely, jump to the end state, or use a static replacement image—not simply animation-play-state: paused.

Responsive breakpoint testing means verifying layout separately at a defined set of viewport widths (e.g., 320px, 375px, 768px, 1440px). Checking only a single breakpoint is a common trap: AI or developers often confirm "looks fine" at desktop width and ship, while price overflow, buttons pushed off screen, and text truncation only surface at narrow viewports. Even more insidious is "exactly one width is correct"—layouts mixing fixed px with vw units can be perfect at 375px and fall apart immediately at 414px or 360px. A fixed pass/fail checklist should capture screenshots and compare them at several typical breakpoints, rather than relying on visual memory.

Ten "tells": the structural weaknesses of AI site building

This exercise forced us to write down the patterns that recur in AI-built interfaces. Borrowing from poker logic—a tell is what you do when nobody's watching:

• Reflexive indigo gradients
• Always three equal-sized feature cards
• Glassmorphism nobody asked for
• Full-opacity hero sections that say nothing
• Copy that's almost real but doesn't hold up ("Revolutionize your workflow")
• A single, centered, unmissable CTA button
• Emoji bullets dressed up as a design system
• Pricing table numbers nobody actually committed to
• States that exist only on the happy path
• Layouts that are correct at exactly one viewport

The real point: expensive tells are structural, not visual. Indigo color is cheap—one line in a prompt kills it before code is even born, which is why classifiers trained on visual tells are always chasing a moving target. But "cramming a hero onto a screen that needs a table" survives any color change.

That's the kind of problem worth putting on the checklist. Color can be solved by prompt; structural errors can only be solved by examining the real artifact.

The distinction between structural tells vs. visual tells is the core judgment framework of this article. Visual tells (indigo gradients, glassmorphism, equal-sized cards, emoji bullets) are surface decoration, eliminable with a negative prompt or a design-system constraint. Structural tells involve information architecture and content decisions: putting a hero where a spec table belongs, missing error/loading/empty states, hollow pricing table numbers, states that only cover the happy path. These cannot be fixed by changing colors or fonts—they only surface by examining the real DOM, real data, and real artifacts at real breakpoints. They're more expensive because they're not "ugly"; they're "not answering the user's question right now."

Our solution: constraints up front + a browser acceptance gate

We produced two deliberately boring artifacts:

• A ~1KB pre-prompt constraint that kills those visual tells at generation time
• A pass/fail browser acceptance gate executed at 3 breakpoints, with failure screenshots stored directly as evidence—the case breakdowns in our playbook are exactly these, bugs included, because the bugs are the product

The core of this approach is taking "acceptance" out of the model's hands and handing it to a mechanism that won't pay for intentions.

As for the release, we published it under the name KURSYWA PRESS. To be clear: the full methodology is a $29 PDF, with a 2-page excerpt free.

More interestingly, we want to know what the acceptance gate would flag red on your AI page. Drop a screenshot description in the comments—the worst structural tell wins a free review.

One-line Summary

An AI self-review passing doesn't mean the product is acceptable—a fixed browser acceptance gate caught four structural bugs across three breakpoints.

Paragraph Summary

The article documents building two fictional storefronts with an AI agent (a Warsaw watchmaker and a micro font foundry). The model self-assessed its work as "clean," but the author introduced an "acceptance gate"—a fixed pass/fail checklist checked item by item against the actual page at three breakpoints—and caught four problems: a hero section where a spec table belonged, a buy bar breaking at the 375px breakpoint, a prefers-reduced-motion fallback frozen mid-rotation, and auto-scaling fonts overflowing. The author concludes that AI self-review stamps intent rather than reality, summarizes ten AI site-building "tells," and stresses that structural tells are far more expensive than visual ones. The solution is a ~1KB pre-prompt constraint plus a browser acceptance gate, with failure screenshots saved as evidence.