How Google tests Gemini 4 and uses agents to maintain code

The Google Cloud Show introduces Gemini 4 Argon and Carbon. The hosts say Argon is designed for deep reasoning and multistep work, while internal teams have seen Carbon pursue complex code problems for days.

The hosts also cite zero successful attacks on particular cheating and indirect prompt-injection evaluations. Those are results for the named tests, not a guarantee against every attack.

Smitha interviews Tulsee Doshi, Google DeepMind’s head of product for the Gemini model family, about development, rollout and use. Doshi previously led product for responsible AI at Google.

Doshi says Google expanded internal live testing during Gemini 4 development. One morning, enthusiastic messages from early employee testers convinced her there was something worth trying before she had properly tested that checkpoint herself.

She describes frequent releases and user feedback as established practice, but says the pace of internal iteration increased for Gemini 4. The team uses employee feedback to improve checkpoints before wider release.

The gap between announcement and general release gives cyber defenders early access to stress-test the model and its safeguards. Doshi says this staged process helps the team gather feedback before broader availability.

Compared with Gemini 3, Doshi expects the biggest difference on long-running tasks. She describes persistence as working around a blocker or edge case instead of giving up, repeatedly asking the user, or claiming an unsolved problem is solved.

Doshi says Carbon received further work on usability, including reduced fabrication, improved web-app aesthetics, coding and secure-code generation. She also says Argon remains a viable daily model and suggests developers try Carbon for themselves.

Web development illustrates the iteration: users liked Argon’s 3D visualizations but reported weaker web aesthetics. Doshi says some improvements arrived in Carbon and that the team will keep incorporating feedback.

Google works with Wiz, now part of Google, on cyber evaluations and early tests. Doshi says its Scan for Good program used the models while helping a hospital system identify and patch a vulnerability that could have exposed hundreds of thousands of patient records.

She frames the defender-first rollout as both a use of the models’ security capabilities and a way to test guardrails with a smaller group. The aim is to learn before giving the model to a wider audience.

For her own writing, Doshi uses a speech-to-text model in Antigravity to capture her thoughts, then asks Argon to structure them into a document she can edit. She sees this as a way to write in order to think and invite feedback.

The interviewer cites a Fortran-to-Rust migration and a Chrome patch comparison. Doshi says Google observed a 30% increase in agentic code submissions after Argon became available internally, and argues that more persistent tools can give developers room for creative work.

To compare checkpoints, Doshi repeatedly tests a personal childcare administration application: payments, health appointments and visualizations. She also asks models to aggregate data into documents or slides, then edits those artifacts with specific requirements.

Her advice to non-engineers is to use a model as a thought partner, not the source of truth. Bring an idea, ask what it misses or what consequences might follow, then iterate on the draft yourself.

The element names Argon and Carbon are intended to distinguish individual models while keeping a shared theme. Doshi also discusses keeping space for dance and, as a parent, preserving a child’s critical thinking, creativity and human relationships.

The show then switches to an AI Studio demo. Luke, Mollie and Billy inspect a 3D chess application whose board lacks familiar coordinates. One asks Argon to replace the symbols with letters and numbers; another asks for bright neon pieces.

They then add a shared leaderboard and login to a racing game. The demo accepts the Firebase and Firestore setup and the participants race against the shared results. They note that authentication used to require much more development effort.

Rody Davis demonstrates an Antigravity workflow for keeping code current across web, Android and iOS. The aim is to identify outdated APIs, compatibility code and unnecessary polyfills once supported platforms have moved on.

The workflow defines platform-version policies and custom subagents in Markdown. Separate workers address Node, Jetpack Compose and SwiftUI; a shared configuration specifies how many versions must remain supported.

With Argon at medium effort, Davis invokes the workflow using example issues and the codebase. The main agent first checks the policies and dispatches platform workers. Real teams could connect their own ticketing sources.

Davis compares the human’s role to a floor manager: inspect the work, stop it if quality drops and refine procedures. Separate subagent contexts allow parallel work while reporting progress to the main session.

Review subagents are configured as read-only, so they inspect changes without writing code. Antigravity lets the user inspect each conversation and send a message to steer or stop a subagent.

The final report records what the workers did, including removed legacy APIs and a code-freshness assessment based on Git history. Davis suggests using the automation panel to repeat the audit on a schedule or around platform releases.

For longer work, Davis points to Teamwork Preview and the /boost command. He describes Teamwork as using teams of subagents and Boost as a more linear workflow that creates subagents as needed.