# UI generation gains still need reference fidelity checks

Why Gemini 3.7 Flash UI claims need separate checks for screenshot resemblance, design-system rules and functional interaction states.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-13
Original announcement: https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-3-7-flash/
Canonical URL: https://retrivium.ai/retrospectives/flash37-web-ui-reference-fidelity/

## Reference-driven UI work gained attention

[The May 19, 2026 Gemini 3.5 announcement](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5/) preceded [the July 21 Flash-family release](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-6-flash-3-5-flash-lite-3-5-flash-cyber/). [Gemini 3.7 Flash followed on August 13](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-3-7-flash/) with claims about web development and reference adherence. Such a claim contains several possible meanings. A generated page can resemble a screenshot, preserve a design system's rules, or implement the intended interaction. These achievements can overlap, but none automatically proves the others.

## A screenshot captures one state

An illustrative reference shows a search field and a filtered table. Matching that image establishes something about layout in the displayed state. It does not establish that typing changes the rows, that clearing restores them, or that an empty result remains understandable. The evaluator needs a behavioral specification alongside the visual reference. Otherwise a static imitation can score well while failing the reason the interface exists. This is a limitation of screenshot evidence, not an allegation that any particular model always generates nonfunctional controls.

## A design rule applies beyond the reference

A design system may specify spacing, typography and component states that are not all visible in one image. Reproducing the reference at a single width can still violate those rules elsewhere. A useful evaluation inspects the generated implementation at relevant widths and states rather than measuring resemblance only in the original viewport. The expected states should follow the task's actual needs, avoiding a gratuitous test inventory. The important distinction is between copying visible pixels and applying reusable rules to conditions the reference does not explicitly show.

## A bounded visual-and-behavior fixture

A practical illustrative task asks for a searchable table using a supplied reference and a small fixed dataset. Review the initial rendered view, a matching search, an empty result and a narrow layout. Inspect whether the same component rules remain coherent across those conditions. No visual score or local model result is asserted. The fixture connects appearance to function while keeping the task small enough that a reviewer can identify whether an error arose from layout interpretation, missing behavior or inconsistent component styling.

## Fidelity needs an explicit target

The August release makes reference-based generation worth testing, but “looks right” is too broad to explain a result. The target may be a screenshot, a set of design rules, an interaction contract or a combination. A retrospective should name which kind of fidelity is under discussion and preserve the evidence for it. That allows a strong visual draft to receive appropriate credit without being misreported as a finished application. Functional acceptance begins where the reference stops showing what the user will do next.

## Related reading

- [Defining observable acceptance](/journal/inference-benchmark-method/)
- [Keeping comparison conditions clear](/journal/gpu-benchmark-median-dispersion/)