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.
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.
AI-generated UI usually gets reviewed in its most flattering state:
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. 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.
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.
Every important screen should show more than its happy path. At minimum, inspect:
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.
Replace tidy demo text with inputs that strain the layout:
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.
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.
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.
The last check is intentionally unglamorous:
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.
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 , 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. 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.
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](https://medium.com/@marcusykim)
DEV.to: [https://dev.to/marcusykim](https://dev.to/marcusykim)
Website: [https://marcusykim.com/](https://marcusykim.com/)
X: [https://x.com/marcusykim](https://x.com/marcusykim)
LinkedIn: [https://www.linkedin.com/in/marcusykim/](https://www.linkedin.com/in/marcusykim/)