Google's Elephant-Goldfish Plugin Makes Your AI Agent Stress-Test the Spec Before It Writes Code

One agent with full context drafts the design. Reviewers with zero memory try to break it. Here is how to run it in Claude Code or Codex, and what it will not do for you.

The agent that wrote your plan is the worst possible reader of it.

It spent an hour with you. It knows why the cache exists, which table is legacy, and that "the sync job" means the nightly one. So when it writes the design doc, it skips all of that, because to the agent it is obvious. Then a different session picks up the doc, or you do three weeks later, and the gaps open up right where the code goes.

A plugin trending on GitHub this week attacks that exact gap. Google's elephant-goldfish-model (EGM for short) splits the work between two kinds of AI: one that remembers everything and one that remembers nothing. The one with no memory has a single job, which is to find out whether the spec actually says what you think it says.

What EGM is

EGM describes itself as "an open-source plugin for Spec-Driven Development with AI coding agents." Spec-driven development is a simple idea with a fancy name: write down what you are going to build, check that write-up, and only then build it.

It installs into the coding agents most builders already use, including Claude Code (Anthropic's terminal coding agent), OpenAI's Codex, and Google's Antigravity, per the README. It is Apache-2.0 licensed, has no tagged releases yet, and had roughly 1.3k stars when it sat at #24 on Trendshift's live board at about 07:15 ET on Monday (the board reorders through the day). One line in the README matters before you get excited: it is "not an officially supported Google product."

The method comes from an essay by Dave Rensin, Elephants, Goldfish and the New Golden Age of Software Engineering, which Google Research lists as a 2026 publication. His argument, compressed: once AI writes code faster than people can read it, the design document matters more than the code.

The elephant and the goldfish

The names do most of the explaining.

The elephant never forgets. It is a long, context-heavy session that loads your system's history, architecture, component boundaries and user journeys, then brainstorms with you and drafts the spec. This is the agent that knows everything about your project.

The goldfish remembers nothing. In the README's words, goldfish are "stateless, isolated subagents" that "read only the draft spec and live source code, without conversational bias." A subagent here means a helper session the main agent starts with a clean slate.

Think of the goldfish as a new hire on day one. You hand them the design doc and the repo, and nothing else. If they cannot figure out what to build, the doc is not finished. It does not matter how clear it seemed in the meeting.

That is the insight worth keeping even if you never install the plugin: the conversation is not the spec. Whatever lives only in chat history will be gone the moment someone, human or agent, starts fresh. A reviewer with no memory is the cheapest way to find out what that is.

What the goldfish actually check

EGM's review is not one generic "looks good to me" pass. Its architecture doc lays out four stages, each run by isolated reviewers against a written rubric:

1. Zoom Out review: is this the simplest design that works, and does it reuse what the codebase already has? (It checks for YAGNI, the "you aren't gonna need it" habit of building features nobody asked for.)
2. Comprehension test: a naive reader checks whether the doc stands on its own and flags background knowledge it assumes.
3. Critic review: system design, scale bottlenecks and failure modes.
4. Implementation readiness test: do the file paths, function signatures and test cases in the doc actually line up with the code?

The reviewers come from persona files in the repo's agents/ folder. The README's list includes a Design Critic, a Naive Reader, a Tech Lead, a Codebase Auditor and a Zoom Out Architect, among others. A synthesizer persona runs them in parallel, merges what they find and removes duplicates.

The fourth stage is the one I would watch most closely. Plenty of specs read well and still name a function that does not exist. A reviewer that opens the live code catches that before an agent builds on top of it.

Here is the kind of gap this is built to surface (an illustration, not output from the tool). A spec says "reuse the existing rate limiter for the new export endpoint." The elephant knows which one you meant, because you discussed it an hour ago. A goldfish opens the repo, finds two rate limiters in different folders with different defaults, and asks which one, and whether the export job should share a quota with the API. That question costs one line to answer in the doc. Discovered after the code ships, it costs an incident.

Put this into practice

You can try the idea with zero installs, then add the plugin once you like it.

The no-install version. EGM's getting started guide says the manual sequence is free and "you don't have to install anything." Here is the core of it. Finish a design doc in your normal long session. Open a brand-new chat with no history. Paste only the doc and say: "You are about to build this. List every question you would need answered first." Every question is a hole in the doc. Fix the doc, not the chat, and repeat until the questions are boring.

Install in Claude Code:

claude plugin marketplace add google/elephant-goldfish-model && claude plugin install egm@egm

Install in Codex:

codex plugin marketplace add google/elephant-goldfish-model && codex plugin add egm@egm

The setup notes warn against copying only the skills/ folder: the skills read agents/ and resources/document_standards/ at run time, so a partial install breaks EGM.

Run the core loop. In Claude Code the commands carry an /egm: prefix:

/egm:egm-brainstorm
/egm:egm-draft
/egm:egm-review docs/designs/<feature>.md
/egm:egm-resolve

Brainstorm clarifies the idea and sends a swarm of goldfish at it from several angles. Draft builds the design doc section by section and saves it under docs/designs/. Review runs the four-stage pipeline above. Resolve walks you through the findings and patches the doc. Then the guide's advice is to send the design through a normal pull request to a human, and only then ask the agent to build it.

Two extras for later. /egm-drift-report scans for places where the code has wandered away from the spec, and the guide suggests running it weekly. /egm-bootstrap <path> writes README files across an existing codebase so the elephant has something to load.

What to expect. A lot of feedback. The guide says so directly and tells you to take what is relevant and ignore the rest. Your first review will flag things you consider obvious. That is the point: obvious to you, invisible to anyone starting fresh.

Not every agent isolates the goldfish the same way

The whole method rests on the goldfish truly starting blank, and that depends on which coding agent runs it. The setup notes are candid about the differences.

In Claude Code, EGM ships reviewer definitions that limit the goldfish to read-only tools. In Codex, there are no named personas; a general-purpose subagent reads the persona file instead. In ChatGPT modes that cannot start a fresh-context helper, the review skills stop rather than review inside the same conversation, which is the right call, since a goldfish with memory is just another elephant. Claude Cowork installs work, but hooks (scripts that run automatically at set points in a session) are not available there, and both Cowork and ChatGPT still have open issues for verifying that runs in the cloud behave as tested.

All five listed setups install. Claude Code, Codex and Antigravity are the ones the notes mark as passing automated tests for installation, reviewer isolation and the end-to-end workflow.

Honest limitations

It is not an official Google product. The README says so. Treat it like any open-source plugin from a team you do not have a support contract with.

There are no measured results. The README makes no claims about fewer bugs or faster delivery. The method is persuasive. It is not proven.

Reviews cost tokens, and nobody says how many. The guide calls EGM "free" apart from your time, which is true of the license and not of your API bill or plan usage. A swarm of parallel reviewers on every spec adds up, and neither the README nor the guide gives a token or dollar estimate.

It is young. There are no tagged releases, so the install commands pull whatever is on the main branch that day, and the architecture doc does not explain how the drift scanner works.

It is overkill for small changes. The guide itself says a simple bug fix may not need the design-first loop. Use it where a wrong design is expensive: new features, data model changes, anything several people or agents will build on.

It does not replace a human reviewer. EGM "does not replace human oversight, but encourages it," per the guide. The goldfish find gaps. A person still decides which tradeoffs are acceptable.

Where to start

Do the free version this week. Take the next design doc you finish with an agent, open a clean session, give it only the doc, and ask what it would need to know before building. Count the questions.

If the count is zero, your doc is better than most. If it is twelve, you just found twelve bugs that would have shown up as code. Either way you will know whether EGM's commands are worth installing, and you will have learned the one habit the plugin is built on: never let the agent that wrote the plan be the only one that reads it.

Sources: google/elephant-goldfish-model README, getting started guide, architecture doc and setup notes, all read on the main branch on October 26, 2026 (the repo has no tagged releases); Dave Rensin, Elephants, Goldfish and the New Golden Age of Software Engineering (Google Research listing, 2026); Trendshift daily board, read about 07:15 ET October 26, 2026 (a live board, so the rank moves); star count from shields.io the same morning.