How to Verify AI-Written UI Changes Across Viewports

The Gap Between an Agent's Check and a Rendered Page

The 2025 DORA report found that 90% of survey respondents report using AI at work, while 30% report little or no trust in the code generated by AI. The same report notes that AI adoption continues to have a negative relationship with software delivery stability.

Those two findings fit together once you look at what the agent can actually observe. An agent verifies by reading, running unit tests, and type checking, and all three inspect source code. When it does open a browser, it opens one, at one size.

That default matters more than it looks. Playwright ships with a 1280x720 viewport, so a self-check that renders the page inherits a comfortable desktop width nobody chose deliberately. Everything narrower is untested by construction.

Study Design: Components, Viewports, and Checks

We asked an AI coding agent for ten common interface pieces, one single-sentence prompt each, and accepted the first output without iteration. That is the state in which agent work usually arrives in a pull request.

• Components - a pricing row, navigation bar, deployment history table, confirmation modal, settings form, KPI tile row, sidebar dashboard layout, feature card grid, filter toolbar, and page header.
• Viewports - 1280x720 as the baseline, plus 1920x1080, 1440x900, 768x1024, 390x844 and 360x800.
• Browsers - Chrome and Microsoft Edge, both latest, on Windows 11, running on the TestMu AI cloud under build 102695939.
• Scale - 10 components across 6 viewports on 2 browsers, giving 120 measured renders.

Each render ran the same five checks in the page, all of them objective rather than a judgment about whether a layout looked good.

• Horizontal page overflow, where document scrollWidth exceeds the viewport width.
• Elements whose right edge falls outside the viewport.
• Content clipped by an ancestor that hides overflow.
• Interactive elements under 44 by 44 CSS pixels, applied only to the two mobile viewports.
• Sibling elements whose bounding boxes intersect.

The touch target threshold comes from WCAG Success Criterion 2.5.5, a Level AAA criterion requiring pointer targets of at least 44 by 44 CSS pixels, subject to four stated exceptions.

Defect Results by Viewport

Every component passed at every desktop width. Every component failed at both mobile widths. There was no middle ground in the results.

The tablet width caught three components: the navigation bar overflowed by 63px, the KPI tile row by 124px, and the filter toolbar by 135px. Those same three were the worst offenders on mobile, which makes 768px a useful early warning rather than a substitute for a real mobile check.

The filter toolbar shows the failure most plainly. At 390px the page rendered 903px wide, leaving two filter dropdowns, the export control, and the primary New deployment button beyond the right edge and out of reach.

Across the sweep the defects concentrated in two categories. Chrome logged 143 elements pushed past the viewport edge and 68 undersized touch targets, against 17 horizontal page overflows. No component produced clipped content or overlapping siblings at any width.

Three Failure Patterns Behind Every Defect

All 456 recorded defects trace back to three causes. Each one is a reasonable choice at the width it was written for, which is why review does not catch them.

• Flex rows that never wrap - the toolbar, KPI tiles, navigation bar and pricing row all used a horizontal flex container with no wrap rule and children carrying fixed or minimum widths. The children keep their size, the container cannot shrink them, and the row extends past the screen. This produced the largest overflows, up to 513px on the toolbar.
• Tables with unwrappable columns - the deployment history table set headers to avoid wrapping and filled cells with email addresses, environment names and timestamps. At 390px it needed 715px and pushed 26 separate elements off screen, the highest element count in the study.
• Touch targets sized for a mouse - buttons and links styled with desktop padding measured in the high thirties and low forties. The modal, settings form and sidebar layout produced no overflow whatsoever and failed on this alone, which is the case a horizontal scroll check would wave through.

That third pattern is the one worth internalising. Three of ten components were broken in a way that no amount of scroll detection would surface, and a reviewer scanning a screenshot would not measure a button to find it.

The Agent's Blind Spot Is Structural

None of this is a reasoning failure. An AI coding agent works on a closed surface made of text: it reads source, writes source, and verifies with tools that also read source. A button positioned outside the viewport is valid code and a broken interface at the same time, and only one of those two facts is visible to a compiler.

Our data puts a boundary on that blind spot. The same CSS was correct at three separate desktop widths on two browsers, which rules out bad CSS as the cause. What the numbers point at is the closing condition of the verification loop: it ends at whatever width the agent happened to render, and nobody set that width.

The related question of whether agents can close this loop themselves is covered in our analysis of whether coding agents can test their own code, which reaches the same conclusion from the requirements side rather than the rendering side.

How to Verify an AI-Written UI Change

The fix is narrow. Render the change at a width the agent did not pick, and assert against the rendering rather than the source.

Which width to add is not a close call. Statcounter put mobile at 52.61% of worldwide platform share in July 2026, against 45.89% for desktop and 1.5% for tablet.

• Add one mobile viewport between 360px and 390px. In our sweep this single addition separated ten passing components from ten failing ones.
• Add 768px next if the layout has any multi-column structure, since that is where the three worst components first showed damage.
• Skip the extra desktop widths. The three we tested agreed completely, so a second desktop viewport spends time to confirm what you already know.
• Check element geometry, not just page scroll, so the touch target class of failure does not pass silently.

For the browser half of this, Kane CLI is built for the case where the thing requesting verification is itself an agent. It drives a real Chrome browser through the Chrome DevTools Protocol from a natural language objective, with no selectors or page objects to maintain, and returns an evidence-backed pass or fail rather than a transcript. Its agent mode suppresses the terminal interface and emits NDJSON, one object per line, so a coding agent can consume the verdict and close its own loop.

# Agent mode: structured NDJSON on stdout, no display server needed
kane-cli run "Open the deployments page at 390px wide and confirm the New deployment button is fully visible" --agent --headless

The same binary and syntax run headed on a developer machine and headless in CI, which keeps the local check and the pipeline check honest about each other. Setup for both is in the Kane CLI agent mode documentation.

Turning One Verification Into Regression Coverage

A check that runs once tells you today's answer. The reason to capture the rendering is that the next change gets compared against it instead of judged again from scratch.

SmartUI handles that half by storing screenshot baselines per browser and per viewport, then flagging pixel-level differences while filtering rendering noise, dynamic content and anti-aliasing artifacts. Its viewport list is declared in configuration, so the widths that caught defects in this study become the widths every later build is measured at.

{
  "viewports": [[1920, 1080], [1280, 720], [768, 1024], [360, 640]]
}

Baselines also survive branching. When a feature branch merges, SmartUI merges the branch baselines and surfaces a conflict for manual resolution when both branches changed the same screen, which is the same shape as a Git merge conflict. The full option set is in the SmartUI SDK configuration options.

Where this sits in a broader merge gate is laid out in our vibe coding QA workflow, and the underlying principle has its own treatment in verification-driven development.

Limits of This Study

Ten components is a small sample and the findings should be read as directional. The sample is bounded in ways worth stating plainly before anyone generalises from it.

• One agent, one pass - every component came from a single model on a first attempt with no follow-up prompt. A prompt that names target viewports, or a second iteration, would very likely change the result.
• Standalone components - each piece was rendered on its own rather than inside an application with a design system, a CSS reset chain, or existing breakpoints that might have absorbed the problem.
• Two Chromium browsers - Chrome and Microsoft Edge share a rendering engine, so their perfect agreement across 60 paired runs says nothing about Safari or Firefox.

What the sample does support is narrower and still useful: for first-pass agent output rendered standalone, viewport width predicted failure completely and browser choice predicted nothing.

The First Check to Run

Open the last UI change an agent wrote for you and render it at 390px. That takes a minute and, on this evidence, is where the defects are.

If it holds up, add that width to your pull request gate so the next one is checked automatically. Kane CLI covers the browser verification and SmartUI keeps the baseline, and both run against the same TestMu AI grid alongside the test automation cloud your existing suite already uses. Getting the first run going is covered in the Kane CLI getting started guide.

The broader shift this sits inside, where agents write and a separate layer proves, is mapped in our guide to agentic coding CLI tools.