Building in the Gemini Era – Kat Kampf & Ammaar Reshi, Google DeepMind

Do you want a polished website from one prompt, or an agent that can work through a large codebase? Those tasks demand different capabilities. Kat Kampf, who works on vibe coding and AI Studio, and Ammaar Reshi, who leads its product and design team, introduce both as parts of the same building experience. The historical backdrop runs through the Transformer and AlphaGo; even their timeline, ending at Gemini 2.5, has already fallen behind the launch week.

Gemini 3 Pro, announced earlier that week, is presented along two axes:

• Design understanding: generate a website with coherent aesthetics and a usable interface in one shot.
• Agentic tool calling: perform more complex work across large codebases through tools and successive actions.

Kat reports that Gemini 3 outperformed the comparison models in a SWE-bench experiment using a base agent harness. The talk does not supply enough evaluation detail to turn that chart into a reproducible comparison; its practical role here is to introduce the tool-driven side of the model before the live application demos.

Nano Banana Pro, introduced as having launched the previous day, supplies the image capabilities used later in the applications. Ammaar starts with a tea-making question. Google Search provides information that the model turns into an illustrated recipe: the selected slide shows cardamom chai ingredients, preparation steps and tips. Search grounding supplies the informational context; image generation arranges it into a diagram with readable text.

Text rendering matters beyond flat labels. Ammaar shows lettering wrapped around a can, then a Korean localization that retains the reference image's composition. He next describes a group image with 14 people as the team's consistency benchmark so far, rather than a hard maximum. That spoken example differs from the published launch specification, which distinguishes up to 14 input images from maintaining the resemblance of up to five people.

The next comparison is a selective edit: a woman and flowers remain in the scene, but the focal subject changes. The instruction is simply, “Change the focus to the flowers.” The useful property is preservation: the requested attribute changes without asking for a new composition. Multiple aspect ratios then extend the same image workflow to wallpapers, banners and advertising boards.

Google AI Studio provides model chat and API-key access, but Kat moves into its Build experience. An example gallery gives users starting points; a prompt field lets them request an application directly. The AI chips below it expose capabilities beyond model selection, including Google Search grounding and Google Maps grounding. They make those capabilities part of the application request rather than a separate integration exercise.

The Live API adds continuous interaction. Kat describes an app that watches a webcam view of her tennis swing and gives corrections, alongside a posture-feedback example that reacts when someone leans too far forward. These are applications in which the input changes over time and the response needs to arrive while the activity is happening.

In the experience described onstage, prompt-to-app building is free, most models do not require an API key, and visitors to shared applications use their own AI Studio free quota. Kat presents this as protection against a popular shared app generating an unexpected bill for its creator. This is historical billing behavior: current Build documentation assigns shared-app usage to the creator, with paid-model charges where applicable.

Kat then starts a laptop-sticker application, drawing on a trend of generating personalized sticker illustrations. The request combines Google Search grounding with the Pro image-model chip. The roles are distinct: Gemini 3 builds the application; the image model supplies the application's generated images.

1. Kat submits the sticker-app request with the Pro-model capability selected.
2. Gemini 3 breaks down the task and generates the end-to-end application.
3. While generation runs, the loading screen uses Gemini to suggest ways the app could be extended.

The build remains in progress as Ammaar moves to other examples. Even the waiting screen is treated as an opportunity to refine the user's intent.

Improved text rendering and character consistency suggest a natural application: put yourself into a comic book. Ammaar's generated app accepts face uploads and offers genre and language choices. He selects Kat and himself, then supplies a premise: they are presenting AI Studio at AI Engineer in New York, vibe coding and winging their presentation. That request starts the comic generation.

While the comic renders, he switches to a website example. His complaint about earlier generated sites is specific: too many purple gradients. This site instead uses shader animations, transitions across pages, visual effects and typography selected by the model. The initial request was to create a slick animation website, with an explicit instruction excluding cyberpunk styling. The example connects Gemini 3's design capability to a practical prompting technique: specify the desired effect and rule out an aesthetic you do not want. Ammaar presents this as a way for people who struggle with design tools such as Figma to reach a useful visual starting point.

Returning to the comic, the generated pages combine story text with images of the presenters rushing to the conference. An AI Engineer banner appears in the background. Gemini 3 supplies the narrative, while Nano Banana Pro supplies the images and rendered lettering. Their combination lets the app produce a story in which the environment, characters and text all contribute to the scene.

The app also lets the reader choose a direction midway through. Should the characters find a quiet corner and check their API keys, or embrace the situation and improvise? Ammaar chooses improv. The story changes, and the remaining pages begin generating from that choice. One line describes a “suspiciously functional robot dog,” illustrating the kind of incidental humor he likes in the output. The interaction is more than a request for another picture: a user decision becomes context for the next part of a multimodal narrative.

Back in Kat's app, the first step is adding an API key. The newly launched image model is a paid experience in AI Studio at the time, an exception to the earlier description of keyless access for most models. The generated interface offers two input paths: enter words for sticker themes or use Google Search. Kat chooses Search, enters Ammaar's name and selects 1K image resolution. The intended sequence is to retrieve current sources, build context about him and turn that context into plausible laptop stickers.

The completed image includes a Weekend Builder design and references to Ammaar's children's book, Alice and Sparkle. Those details make the grounding visible: the output reflects information associated with the person searched for, rather than only generic sticker motifs. Kat then extends the same mechanism to news, where retrieving information from that day can provide context beyond the model's training cutoff.

The next application begins with a product-team constraint: Kat and Ammaar have more ideas than available engineering time. They use AI Studio to explore interactions before committing to an implementation. One such idea is a path into Antigravity, Google's newly announced agentic IDE. A browser-based builder may be enough to start an application, but certain features or mobile-specific work can require moving into an IDE.

Kat supplies a screenshot of AI Studio and asks the model to clone the interface closely, then add an export flow to Antigravity. The generated prototype reproduces the light-mode interface and adds an Antigravity button, an export interaction and a route to opening the project in the IDE. This is a product concept being explored, not a demonstration of a generally available export integration.

The value is also in the alternatives. Kat asks the model to be creative rather than stay inside existing AI Studio patterns. Across iterations, it sometimes produces a command-line-style display of export status. A screenshot constrains the surrounding interface while the prompt leaves room to invent the new interaction, making the prototype useful for comparing product directions.

Ammaar next opens a 3D racing game generated with Three.js. Simple prompts produced the scene, a bot opponent and a start screen. He then added a boost so that he could pull ahead of the bot. This is a different test of generated software from the earlier website: the output has a running scene, player input and game behavior, not just a visual layout.

Up to this point, Ammaar says, the applications have been frontend React apps. He now previews backend support and a full-stack runtime, described as coming soon in the recorded experience. Examples include installing shadcn by prompt and translating a request for a multiplayer app into an Express backend with the necessary wiring. The proposed interface starts with the desired behavior; the builder infers the supporting packages and server work.

The presenters have already converted the racing game to multiplayer with a couple of prompts. They display a QR code and invite the audience to join, noting that they have never tried it with nearly this many people. Cars begin loading into the game, and Ammaar asks everyone to mark themselves ready.

Two application rules become visible under the larger crowd. Car-to-car collisions are enabled, so vehicles bounce against one another and crowd the starting line. Ammaar calls out 19, then 20, then 23 players in the lobby. These are observed lobby participation counts, not measurements of completed-race capacity.

The other rule is a readiness barrier: every player must be ready before the race starts. A JavaScript expression of that rule makes the blocking condition clear:

const players = [
  { id: "kat", ready: true },
  { id: "ammaar", ready: true },
  { id: "guest", ready: false }
];

function canStartRace(players) {
  return players.length > 0 && players.every(player => player.ready);
}

const before = canStartRace(players); // false

const updatedPlayers = players.map(player =>
  player.id === "guest" ? { ...player, ready: true } : player
);

const after = canStartRace(updatedPlayers); // true

In this three-player illustration, the final guest becoming ready releases the barrier. In the live demo, the barrier remains unresolved: the presenters cannot start the race. The crowd has exposed a coordination problem as well as a collision problem.

Ammaar nevertheless reports that the runtime did not crash. That separates three outcomes that would otherwise be easy to conflate:

The live result is a populated multiplayer application with a stalled game flow. It demonstrates the connection path while also revealing rules that need to change for an audience-sized session.

The runtime's intended scope extends beyond games. Kat describes plans to make first-party and popular third-party APIs easier to integrate over the following months. A backend provides somewhere to connect those services and support capabilities that cannot live entirely in a frontend preview.

The reason to build that infrastructure into the experience is a change in who gets to make software. Kat recalls meeting a tech-support worker that morning who had started building in AI Studio after watching a YouTube video. For that user, a conventional IDE need not be the entry point. The tool's job is to understand enough of the desired application to help the person build it.

User intent should imply the required capability. Kat's closing examples are storage and payments: an application that needs persistence should receive storage without requiring its creator to ask explicitly for a database; an e-commerce application should have a path to a payment solution. These are product ambitions in the talk, rather than completed demonstrations. They set a more demanding goal for the builder than generating an attractive first screen: infer what the application needs to do, then supply the software capabilities that make it possible.