On August 13, Google introduced Gemini 3.7 Flash as its latest “workhorse” model for coding and agents. One detail should matter to anyone using AI to build an app: Google says the model improved at web development and can show strong design adherence when you give it a screenshot, image, or full design system as a reference.
That is useful progress. A beginner can describe a screen, attach a visual target, and get something recognizable much faster than before.
It also creates a more convincing trap.
A generated screen can match a screenshot and still fail as software. The button may not lead anywhere. The layout may collapse when real text arrives. The empty state may not exist. Keyboard focus may jump in a nonsense order. The “saved” result may disappear after refresh.
The durable beginner lesson is this:
A screenshot proves appearance. A screen-proof checklist proves an interface.
What changed, and what did not
Google’s announcement emphasizes better first-pass coding, instruction following, web development, and UI generation from visual references. The release also extends the model across developer surfaces including the Gemini API, Google Antigravity, Google AI Studio, and Android Studio.
This continues the direction Google described at I/O 2026: moving from a prompt toward a production-ready application through agentic tools. The distance between “I described a screen” and “I can run a screen” keeps shrinking.
But production-ready is not a visual style.
Apple’s interface guidance still asks layouts to preserve hierarchy, adapt to different device and system conditions, and keep controls understandable. The W3C’s accessibility guidance still cares about things a static image cannot prove, including focus order, visible focus, reflow, target size, labels, and error prevention.
The model can produce more of the first draft. You still need a repeatable way to decide whether that draft deserves to stay.
The beginner mistake: reviewing the best-looking moment
AI-generated UI usually gets reviewed in its most flattering state:
- one desktop width;
- ideal sample data;
- no loading delay;
- no errors;
- no keyboard;
- no long names;
- and no confused first-time user.
That is not a test. It is a portrait session.
I have learned to review screens as changing systems. A useful interface has to explain what matters, accept an action, show what happened, survive awkward inputs, and let the user recover. Visual quality matters, but visual quality is only one layer of the evidence.
If you need help defining the user, workflow, screen responsibilities, and success criteria before AI starts generating UI, my AI App Builder Starter Prompts are free. The immediate job is to give the tool a screen contract it can be judged against, not just a mood and a color palette.
My seven-point AI-generated screen-proof checklist
1. Give the screen one job
Write this before you review pixels:
This screen helps [user] do [action] so they can get [result].
Then name the primary control that moves that job forward.
If you cannot identify one main action, the screen may be a planning board disguised as a product. AI loves giving every idea its own card, badge, metric, and button. The result can look busy and complete while the user has no obvious next move.
Proof: show the screen to someone for five seconds, hide it, and ask what they think it does and what they would press first.
2. Run the primary journey with real inputs
Do not review only the landing state. Tap, type, select, submit, go back, and return.
For a task screen, create a task and reopen it. For a search screen, type a query and choose a result. For an onboarding screen, finish the first useful action instead of merely swiping through explanations.
Proof: record the exact starting state, actions, and expected ending state. The journey passes only when the user result is visible and understandable.
3. Build a state sheet
Every important screen should show more than its happy path. At minimum, inspect:
- loading;
- empty;
- normal success;
- invalid input;
- unavailable or failed request;
- and completed or saved state.
You do not need six completely different designs. You need six honest answers to “What does the user see now, and what can they do next?”
Proof: capture each state at the target viewport. If two states look identical but require different user actions, the interface is hiding important information.
4. Pressure-test the content
Replace tidy demo text with inputs that strain the layout:
- a long name;
- a long title;
- no image;
- several lines of body copy;
- a large number;
- zero results;
- and enough rows to require scrolling.
This is where “design adherence” meets actual product data. A screenshot reference cannot predict every name, localization change, or user-created mess.
Proof: no essential control is covered, clipped, pushed offscreen, or made ambiguous by realistic content.
5. Test the viewport, keyboard, and safe areas
For web, test at least a narrow phone width and the desktop width you expect people to use. For mobile, test a smaller supported phone, a larger phone, the software keyboard, text-size changes, and the platform’s safe areas.
Apple’s layout guidance emphasizes adaptation across screen sizes, orientation, text size, locale, and system features. Your first version does not need to support every device ever made, but it must behave deliberately on the devices you claim to support.
Proof: the primary journey remains usable without horizontal scrolling, covered controls, accidental cropping, or a keyboard that traps the user.
6. Run the non-mouse test
On the web, use only the keyboard for the primary journey. Confirm that focus is visible and moves in an order that preserves meaning. On mobile, confirm controls have clear labels, comfortable target sizes, and an onscreen alternative when a gesture is not obvious or essential.
WCAG 2.2 includes guidance for focus order, visible focus, target size, and alternatives to dragging. Apple similarly recommends sufficiently sized controls, spacing between them, familiar interactions, and alternatives to gestures.
Proof: you can identify where focus is, activate the important controls, understand labels without color alone, and recover from an error without guessing.
7. Prove that the screen is connected to the product
The last check is intentionally unglamorous:
- Does the primary action write or retrieve the correct state?
- Does that state survive refresh, relaunch, or navigation when it should?
- Does Back return to the expected place?
- Does another account see only what it is allowed to see?
- Does a failure leave the previous good state intact?
This is the line between a generated interface and a working product. A button animation is feedback. It is not proof that the user’s goal happened.
Proof: inspect the visible result after leaving and returning to the workflow. If the product promises persistence or ownership, test it with the smallest realistic example.
A reusable screen evidence table
Use one row per delivered screen:
| Proof area | Question | Evidence |
|---|---|---|
| Job | Can a first-time user name the screen’s purpose and primary action? | five-second result |
| Journey | Can the user complete the intended action? | exact start, steps, and end state |
| States | Are loading, empty, success, failure, and recovery clear? | state captures |
| Content | Does real and awkward data stay readable? | long, empty, and missing-content runs |
| Viewports | Does the supported layout adapt? | target viewport captures |
| Access | Can the journey work with keyboard or accessible controls? | focus, labels, targets, and alternatives |
| Product | Does the action connect to real navigation and state? | refresh, relaunch, account, or persistence proof |
If a row has no evidence, label it unverified. Do not upgrade confidence because the gradient is nice.
The tradeoff
This checklist slows down the moment when you can call the UI done. That is the cost.
It may also make you throw away a generated screen that looked impressive on the first pass. You may discover that a simpler layout survives more states, supports larger text, and gives the main action more room. The quieter design can be the stronger product.
The checklist is not a promise that one screen can be perfect for every person and device. Accessibility testing can go much deeper, platform conventions differ, and real user research can overturn your assumptions. The point is to replace screenshot confidence with a minimum evidence floor.
What you should do next
Take one important screen from your app. Write its one-sentence job, then create the seven proof rows before asking AI for another redesign.
Give the AI the failed rows, not a vague request to “make it better.” Ask it to preserve what passed, repair what failed, and show the new evidence at the same viewports and states.
For the immediate guided action, start with the AI App Builder Starter Prompts, which are free and help you turn an idea into a bounded workflow AI can build and you can verify. For the organized path from idea to publication, AI App Builder From Zero is my $19 field manual covering scope, screens, stack, prompting, architecture, QA, deployment, and launch.
The faster AI gets at producing convincing screens, the more valuable this distinction becomes:
Do not approve the screenshot. Approve the evidence.
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Top comments (0)