Google’s Elephant-Goldfish workflow gives AI designs a fresh reader

An AI coding assistant can hold a large amount of project context and still make the same incorrect assumption for hours. The longer the conversation lasts, the easier it is for a weak design decision to become an unquestioned fact that every subsequent suggestion inherits. Google has released an open-source plugin aimed at that failure mode: separate the AI that remembers the plan from fresh AI reviewers that have never participated in writing it.[1]

The company calls the approach the Elephant-Goldfish Model. Its long-context 'Elephant' session handles design, decisions and architectural memory. Independent 'Goldfish' sessions begin with none of that conversational history and are asked to evaluate a written specification as outsiders. Google introduced the plugin on 22 October, saying it was developed for internal software engineering workflows and is used by thousands of its staff each day. That usage figure is Google's claim, not an independent measure of defect reduction.[1]

The long memory can become a liability

Keeping architectural decisions in one chat solves a real problem: an AI assistant working on a substantial application needs to know dependencies, file boundaries, deployment constraints and what the user has already ruled out. Losing that context can make every subsequent change a regression. But long-lived context has the opposite hazard: the agent remembers not just the correct decisions but also early misunderstandings and unjustified simplifications.[1]

The Elephant's task is to clarify intent and produce a comprehensive design, explicitly avoiding immediate coding in the first stage. Google describes a brainstorming phase followed by drafting a Markdown specification with requirements, alternatives and concrete files to change. The document, rather than the chat's implicit assumptions, is what passes into the review phase.[1]

The Goldfish reviewers act as an adversarial reading group. One must be able to explain the architecture back to the designer; failure signals ambiguity. Others search for edge cases, incompatibilities and unintended consequences. A final reviewer applies a go/no-go test for whether the plan specifies enough detail to implement without guessing about interfaces or data structures.[1]

Why an isolated critic may be useful

There is a familiar human equivalent. A developer who wrote a plan may remember the conversation that supplied missing detail and silently fill the gaps. A colleague given the specification without the conversation cannot do so. The fresh reader is testing the quality of the document rather than the quality of the author's memory. An AI reviewer can play a similar role if it is truly deprived of the preceding discussion.[1]

This is a stronger idea than simply asking the same model to check its own code. A single conversation can produce apparently critical reviews while preserving its original assumptions, because the model's context still contains a persuasive account of why those assumptions were made. The stateless session forces the design to stand on its own. Its criticism may still be wrong, but it exposes what the next implementer can legitimately infer from the document alone.[1]

The plugin supplies Markdown rules, review roles and process orchestration, initially for Google's Antigravity development environment. It is distributed under an Apache 2.0 licence, opening the opportunity for teams to adapt the checks to different languages, architectures and risk tolerances. An organisation can use the method without adopting the idea that Google's version is the only valid engineering workflow.[1][2]

Fresh context can expose an assumption that a long-running design conversation has stopped questioning. It does not give reviewers independent training or guarantee sound criticism. The specification still needs to survive implementation and testing; the plugin’s immediate contribution is to make gaps visible before coding begins.[1][2]

Report an error or suggest a correction