Disclosure: the author runs Ship Index Grow, a school on shipping AI products, and Superprompt Pro, a product design practice. Both are mentioned here because they teach and practice the review step described above.
Direct answer: Google I/O 2026 showed agents and prompts producing working apps. The designer's job shifts from drawing the first version to deciding what is acceptable.
At Google I/O 2026 the most useful announcements for product designers were not the flashy ones. Two of them point at the same shift: a plain-English prompt now produces working software, not a mockup.
Antigravity 2.0 is in public preview on macOS, Windows and Linux. It coordinates several AI agents at once. AI Studio can build a native Android app from a plain-English description, in Kotlin and Jetpack Compose, with an emulator inside Studio and a route to Google Play. The output is real code, which means the design question changes.
When generation is cheap, the expensive part is judging what came out. A designer's work moves from drawing the first version to deciding what counts as acceptable. Three review questions matter more now:
The same logic applies to image tools such as Google Pics, which edits text inside an image and keeps the original font. Inline editing is convenient, and it also makes it easier to ship a changed brand asset by accident.
For teams, the practical step this month is simple: write down the review checklist before the next generated build, not after the first bad release.
What reviewers actually have to check
When working code appears in minutes, the failure mode changes. A rough prototype looks rough. A generated app that runs looks finished, and reviewers are tempted to check only whether the main path works. That is the least informative test. The more useful questions ask what the app assumes about its users, its data and its permissions, and what happens at the edges: an empty state, a failed network call, a second language, a screen reader.
This is where design expertise becomes operational rather than decorative. A designer reviewing generated output should look at information hierarchy, at copy that promises more than the product can deliver, and at flows that quietly skip consent. None of those problems appear in a screenshot review. They appear when someone walks through the flow with the goal of breaking it.
Review needs a record, not only a verdict
When several agents change a product at once, a simple approve-or-reject decision is too coarse. Teams need to know which agent changed which screen, why, and what it assumed. A review that ends with "looks good" leaves no trail when something breaks two weeks later. A better pattern is a short decision record attached to each generated build: the goal, the constraints that were given, the parts a human explicitly approved, and the parts that were left as defaults. That record is worth more than another round of visual polish, because it tells the next reviewer where to look first.
Where review fits in a small team
Not every team can build a formal review process, but a small team can still do three things cheaply. First, keep a standing checklist of defaults the product must never ship with, such as analytics, marketing consent and data retention. Second, require one person to run the generated build on a real device before release, not only in a preview pane. Third, log every regeneration that changes user-facing copy, so wording changes are visible rather than silent. None of this slows generation down. It moves the moment of judgment to the point where it has the most effect.
The cost of a bad release also changes. When a team can regenerate an app in an afternoon, the instinct is to ship first and fix later. That instinct works only when the fix is as cheap as the first build. For products that handle money, health data or private messages, the fix is not cheap, because the damage has already reached users. Review is therefore the place to decide how much risk the team is willing to carry, and that decision belongs to the product owner as much as to the designer.
Related reading
Sources
- "Google Dropped 10 AI Products at I/O 2026. Here's What Designers Should Grab" (Towards AI, May 20, 2026): https://pub.towardsai.net/google-dropped-10-ai-products-at-i-o-2026-heres-what-designers-should-grab-5efee2c87c5c