Google open-sources Elephant-Goldfish, a plugin that stress-tests AI coding plans

What Google released

Google has open-sourced the Elephant-Goldfish Model plugin, a set of skills and reviewer personas that makes an AI coding agent write and defend a design document before any code is produced. The announcement on Google's Open Source Blog, dated 22 October 2026, is signed by Brian Suchy, Jim Quinn, Elise Ewing, Oliver Newth and Dave Rensin for the project team. It says the plugin was first built for Google's own software engineers and that thousands of Googlers use it every day to ship production code. Google has not published a number or a measurement behind that statement.

The code sits in the google/elephant-goldfish-model repository on GitHub under the Apache 2.0 licence. The repository was created on 13 September 2026, its plugin manifest lists version 0.1.0 with Google LLC as author, and it had about 1,150 stars when AI Lookout checked it on 26 October. The README also carries a line that matters for anyone planning to depend on it: this is not an officially supported Google product. Help Net Security reported the release on 26 October.

How the Elephant and the Goldfish split the work

The name describes two kinds of AI session. The Elephant is a long-running session that holds the whole project in view: the architecture, the intent and the small decisions taken along the way. Google's post says no code is written there. The Elephant interviews the developer, argues over trade-offs and keeps the record of what was decided and why.

A Goldfish is the opposite. Each one starts in a fresh context with no memory of the design conversation and reads only the draft specification and the live source code. Google's argument is that a reviewer who sat through the design discussion shares its blind spots, while one who did not will trip over whatever the document fails to say. The README adds a third role, the human, who owns architectural decisions, trade-offs and final outcomes, with the AI acting as exploration partner and automated auditor.

The Goldfish personas are deliberately limited. The Design Critic file, for example, tells the subagent that it is strictly read-only, has no tools to modify the workspace, and must read the document as a naive team member who has just joined the project. The shipped personas include a Design Critic, a Naive Reader, a Tech Lead, a Codebase Auditor, a Structural Validator, a Style Editor and a Zoom Out Architect.

The commands and the reviewer swarm

Google's blog post describes three phases, each a command. In egm-brainstorm the developer and the Elephant work under a no-code rule, debating options and testing assumptions. In egm-draft they turn that into a Markdown design document covering the problem, the technical plan, the alternatives considered, and an implementation plan that names the specific files to change.

The Goldfish arrive in egm-review. In the blog's version, one Goldfish reads the whole document and must explain the design back to the Elephant; if it gets the plan wrong, the document is treated as ambiguous and goes back for more drafting. Several more act as hostile reviewers looking for edge cases, hidden dependencies and logical gaps, and their objections go back to the Elephant. A final Goldfish makes a go or no-go call on whether file paths, data structures and function signatures are present and unambiguous.

The repository has already moved past that three-step summary. Its review skill lists five phases: an initial zoom-out review, a comprehension review, a design critique, an intermediate zoom-out review and an implementation-readiness check. The README lists seven commands in all, adding a review loop that dispatches reviewers in parallel, a resolve step that triages findings and applies patches, a drift report that compares checked-in design documents with the code and lists where they diverge, and a bootstrap command that writes README files describing each directory's interfaces and side effects.

One rule shows how seriously the project takes the isolation. If the harness has no way to start a subagent with a fresh context, the review skill is told to stop and tell the user, because, in the skill's words, a review in the same context is not a Goldfish review.

Where it runs and how to install it

Google's post says the plugin's core goal is to bring the method into Antigravity, its agentic development environment, with other environments to follow. The repository is further along than that.

Its harness guide gives install routes for Antigravity, Claude Code, Codex, Claude Cowork and ChatGPT, all built from the same skills, personas and document standards rather than per-tool forks. In Antigravity the command is agy plugin install followed by the repository URL. Claude Code and Codex users add the repository as a plugin marketplace and install the egm plugin from it. The README also suggests simply asking any agent to install the repository.

The guide warns against installing only the skills folder, because the skills read the persona files and document standards at run time. It also maps the generic instruction to spawn a subagent onto each tool: invoke_subagent in Antigravity, the Agent tool in Claude Code and native spawn tools in Codex. Recent commits, the latest merged on 24 October, let users choose where EGM writes its briefs and reports and add a hook so Claude Code can read the plugin's own files without repeated prompts.

Why Google wants design before code

The case Google makes is about speed without guardrails. Its post argues that AI tools have increased coding speed but also the speed of bugs, low-quality output and what it calls session context collapse, so that teams risk scaling their mistakes. It quotes Rensin's essay on the method: design is the new code. The stated goal is for the agent to produce the code the developer wanted on the first attempt, with the developer acting as executive reviewer instead of micromanager.

The release lands in the middle of an argument about how many agents a coding workflow needs. Anthropic recently told enterprises to fold most subagents into a single agent loop and keep separate subagents only for problems such as context bloat or parallel work. EGM uses subagents for exactly the reason Anthropic still allows: a reviewer whose context has not been filled by the conversation it is judging.

It also fits a wider shift toward checking AI work before it merges. Anthropic's Claude Code team has described layers of automated review and risk-based human approval, and Google Research separately released Harness², a framework that tunes an agent's harness instead of its weights. EGM moves the check earlier, to the design document, before code exists to review.

What Google does not claim

The project is unusually frank about its limits. Its FAQ says design and review take time and may not pay off for a small, well-understood change. It says extra design documents can become a human review bottleneck and recommends using EGM for what is important now rather than for everything. It also says that completing the workflow alone does not demonstrate a productivity improvement, and asks teams to compare total time, useful findings and rework on their own tasks.

Google publishes no benchmark, error rate or before-and-after comparison for the plugin. The claim that thousands of engineers use it daily is the only usage figure, and it comes from Google. The FAQ also concedes that a design complete enough for a zero-context agent is realistic only sometimes, since the models remain non-deterministic and developers still need to correct small mistakes or return to the design when the output is far off.

The project applies its method to itself. Its contribution policy rejects purely autonomous contributions, bans pasting reviewers' comments into a model and posting the reply unchecked, and asks anyone changing more than 100 non-test lines, or three or more core files, to get an EGM design document approved before opening an implementation pull request.

Who should try it

EGM is aimed at teams already letting agents write meaningful amounts of code who find the results drifting from what they meant. Because it is Markdown skills and personas rather than a service, there is nothing to sign up for, and the review step runs on whatever model and token budget the chosen harness already uses. That also means every Goldfish pass costs tokens, which teams should weigh against the rework it saves.

The practical test is the one the FAQ suggests: pick a change that is uncertain or consequential, run it through brainstorm, draft and review, and count what the Goldfish caught that a normal review would have missed. For a one-line fix, Google's own documentation says to skip it.