Google’s Elephant-Goldfish Model: Review the Plan Before Code

12 min read · 2 Nov 2026
Last reviewed November 2, 2026

An AI agent can implement “add CSV export” without asking who may export which records. The missing decisions still get made. You discover them in the code.

Google’s Elephant-Goldfish Model (EGM) is an open-source plugin for reviewing software designs before implementation. A context-rich agent develops the specification; fresh reviewer sessions challenge what the document explains. Engineers resolve the trade-offs and approve the design. The workflow is useful when a feature still contains decisions that a coding agent would otherwise have to invent.

Google announced the open-source plugin on 22 October 2026 and says thousands of its engineers use it daily to ship production code. That establishes reported adoption, not a measured defect-reduction rate.

Source review: 2 November 2026. We inspected Google’s announcement and the repository at revision 403d8881. We did not run EGM against a client project. The feature example, cost calculation and pilot below are illustrative.

What is Google’s Elephant-Goldfish Model?

The Elephant-Goldfish Model separates design work from review by giving the roles different conversation histories. The project README assigns project context to the Elephant, fresh document review to the Goldfish, and architectural decisions to the human. EGM is a set of agent skills and instructions, rather than a newly trained language model.

Who sees what, and who decides
Role	Available context	Responsibility
Elephant	Requirements, architecture, discussion and recorded decisions.	Question the proposal and write the design.
Goldfish	The document, reviewer instructions and relevant referenced material, without the earlier design conversation.	Expose missing assumptions, ambiguity and implementation risks.
Human engineer	Product goals, constraints and the review findings.	Resolve trade-offs, accept responsibility and approve the specification.

The Elephant metaphor does not promise unlimited memory. The drafting skill explicitly anticipates a new session and tells the agent to reread rejected alternatives from the brief. Written decisions carry the context. Our guide to repository context for coding agents covers the wider engineering discipline behind that handoff.

The no-code rule also has a precise scope: EGM’s execution instructions prohibit production implementation during design, while allowing labeled illustrative code in Markdown or a scratchpad. Interface examples can help settle a design without turning the session into an implementation task.

How do brainstorm, draft and review fit together?

EGM moves a feature from discussion into a specification that another session can understand. The official workflow guide describes a core sequence, while allowing teams to use individual skills when appropriate.

egm-brainstorm: explore requirements and alternatives, challenge the concept with fresh reviewers, and record the agreed direction in concepts_brief.md.
egm-draft: develop design_draft.md section by section, including the problem, existing system, proposed changes and implementation plan.
egm-review: inspect the design through separate review stages, then choose which findings to resolve before approval.

After human approval, ask the coding agent to implement a bounded part of the plan. Keep the approved specification in version control, normally under docs/designs/. If you are choosing a broader specification workflow, our GitHub Spec Kit production guide covers that separate decision.

What happens in the five review stages?

The current EGM review skill runs five stages. It checks architectural direction, comprehension, design quality, unnecessary complexity and implementation readiness. The table’s CSV-export findings are examples of what to look for, not results from an executed review.

The current review sequence, with illustrative findings
Stage	Main question	Example finding
1. Initial Zoom Out	Does this solve the actual problem with the existing system?	A new export service duplicates the invoice module’s query path.
2. Comprehension	Can a fresh reader explain the proposal and current behavior?	The document says “account” but never distinguishes user account from tenant.
3. Critic Review	Where do the design, assumptions or dependencies fail?	An export request can select a tenant without proving membership.
4. Intermediate Zoom Out	Have the proposed fixes introduced avoidable architecture?	A queue and object-storage pipeline were added for a bounded export without evidence they are needed.
5. Implementation Readiness	Can the implementer proceed without inventing missing design choices?	The plan omits the row-limit behavior and the existing authorization method’s signature.

The Comprehension reviewer must paraphrase both the proposal and the document’s account of the existing system. If it cannot explain a section, that is a blocker. If its explanation differs from your intent, inspect the document for the missing connection.

The review can pause between stages or produce a consolidated report. A readiness finding is an input to the engineer’s decision. It does not authorize a release.

Why does EGM check for overengineering twice?

EGM’s second Zoom Out review matters because criticism can add complexity of its own. The Zoom Out standard asks reviewers to reject speculative features, avoid premature infrastructure and reuse established components. After detailed criticism, the design needs another check against the problem it was meant to solve.

Consider a reviewer asking what happens if an export grows to millions of rows. That is a useful question. Whether you need a job queue depends on the product requirement, the existing infrastructure and measured execution limits. An explicit cap might serve the current need; a larger export may justify background processing.

We would require every proposed component to resolve an observed constraint or an agreed requirement. Record why you rejected an alternative, too. Otherwise the next reviewer can reopen the same debate and make the design larger without making it better.

Worked example: a tenant-scoped CSV export

A useful export specification resolves who can access which records, what the file contains and how limits fail. The following is an original, abbreviated example for a hypothetical NestJS application. Its file names, permissions and limits are assumptions. Replace them with verified repository details before asking an agent to implement anything.

Assume the application already has authenticated tenant membership, an invoice repository and a tested CSV encoder. The product owner wants a synchronous export of at most 1,000 invoices. This cap is a product choice for the example; it is not a benchmark or a generally safe performance threshold.

Decisions that “add CSV export” leaves unanswered
Decision	Example specification	Acceptance check
Access	Require `invoices.export`. Derive the tenant from verified server-side membership. Accept no client-selected tenant parameter.	A user from tenant A cannot export tenant B’s rows; missing permission returns 403.
Selection	Filter `issued_at` from an inclusive UTC timestamp to an exclusive UTC timestamp. Reject malformed or reversed ranges with 400.	Rows exactly at the start are included; rows exactly at the end are excluded.
Output	Export only `invoice_id, issued_at, total_minor, currency`, ordered by `issued_at` then `invoice_id`. Reuse the CSV encoder.	Column order and stable row order match fixtures; no customer notes or extra fields appear.
Limit	Fetch at most 1,001 matching rows. If more than 1,000 exist, return 422 with `EXPORT_LIMIT_EXCEEDED` before sending CSV headers or bytes.	Exactly 1,000 rows succeed; 1,001 produce a complete error response, never a partial download.
Empty result	Return 200 with the CSV header row and no records.	An empty authorized selection has a valid, predictable download.

The implementation section should map those decisions to the actual code. An illustrative file list might start like this:

Modify src/invoices/invoices.controller.ts
  GET /api/invoices/export?from=...&to=...
  Reuse the existing authentication and permission guards.

Create src/invoices/invoice-export.service.ts
  buildCsv(principal: TenantPrincipal, range: ExportRange)
    -> Promise<InvoiceExport>
  InvoiceExport: { filename: string; csv: string }
  Complete authorization, selection and limit checks before response output.

Modify src/invoices/invoices.module.ts
  Register the export service with existing invoice dependencies.

Create test/invoices-export.e2e-spec.ts
  Exercise tenant boundaries, permissions, dates, columns and limits.

This excerpt is deliberately incomplete: a real plan must identify the guards and repository methods, define ExportRange and error mapping, and settle encoding, filename, cache headers and failure behavior. A fresh reviewer should flag those omissions. Adding plausible-looking file paths alone does not make a design executable.

For the pilot, remove the tenant rule from one copy and the 1,001-row behavior from another. Ask reviewers what happens in those cases. A useful finding names the missing decision and its consequence; silently assuming a policy is a failed detection.

What makes a plan ready for implementation?

EGM’s implementation-readiness standard requires settled design choices, an explicit file list, precise changes and concrete tests. It also calls for incremental phases that leave the project buildable and testable. Treat that as the target quality of the plan, not a promise that generated code will be correct on its first attempt.

Verify the references: every existing path, method and data structure must match the checked-out source revision. Clearly distinguish new symbols from existing ones.
Resolve behavior: define authorization, error cases and compatibility choices where they apply. “Handle errors appropriately” leaves the decision open.
Connect requirements to checks: specify observable outcomes, including boundary and failure cases. A test-file name without expected behavior is insufficient.
Sequence the work: state dependencies between phases and the checks required before continuing.

After implementation, apply independent QA for AI-generated code. A well-reviewed specification can still be implemented incorrectly.

How do you install and run EGM?

Install the complete EGM plugin in a coding environment that can create fresh subagents. The installation and host-capability guide warns that copying only the skills directory omits the personas and document standards. The commands below are the documented installation routes checked on 2 November 2026.

Claude Code

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

Codex

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

Antigravity CLI

agy plugin install https://github.com/google/elephant-goldfish-model

Start a new session after installation. In Claude Code and Antigravity CLI, use the /egm: prefix. For example:

/egm:egm-brainstorm Design a tenant-scoped invoice CSV export.
/egm:egm-draft
/egm:egm-review design_draft.md

Run these as successive workflow steps, responding to the design questions between them. Use the draft path returned by the agent. In Codex, select the corresponding EGM skill from the skill picker.

Check the host’s actual capabilities. The reviewed guide distinguishes Antigravity CLI, App and VS Code extension from the standalone Antigravity IDE, which lacks the required delegation tool. Cowork and ChatGPT Work have installation paths with documented verification gaps. When fresh subagents are unavailable, EGM stops the review; asking the same conversation to pretend to be a Goldfish does not provide the required separation.

Context separation and tool permissions are separate requirements. Check the host’s permission controls for reviewers rather than treating a design-only instruction as a filesystem sandbox.

What does EGM cost, and does it save time?

EGM’s source is available under the Apache 2.0 license. Running it still consumes your coding agent’s allowance or API usage and the team’s review time. The repository also states that EGM is not an officially supported Google product.

The project’s testing playbook describes checks for plugin structure and selected native execution paths. These checks do not establish a general reduction in escaped defects or delivery time. The official FAQ explicitly recognizes that review can become a bottleneck and recommends measuring useful findings and rework.

A hypothetical labor calculation makes the trade-off explicit:

Assume engineering time is valued at €90 per hour.
An extra 20 minutes of review costs €30. Add an assumed €6 of agent usage: €36 total.
If the process avoids 45 minutes of later rework, that time is worth €67.50. The assumed net benefit is €31.50.
The break-even point is €36 / €90 × 60 = 24 minutes of avoided effort.

These are chosen inputs, not Wavect prices, EGM pricing or measured savings. Count all additional drafting, review, resolution and documentation time when you replace them with your own numbers. Track elapsed delivery time separately: a short review that waits two days for an approver can still delay the release.

How would we test EGM on a real team?

We would evaluate EGM on a bounded feature with known acceptance criteria, then compare the whole delivery process with the team’s normal approach. Start with a specification test before trusting review verdicts. The following is a proposed evaluation, including deliberate omissions whose detection you can check.

Fix the baseline: record the repository and plugin revisions, host, model, permissions and the version of the specification under review.
Check separation: put a harmless test phrase only in the author’s conversation. Ask a reviewer to explain the design from the supplied artifacts. Seeing the phrase would reveal leakage; not seeing it is only a smoke test, not proof of perfect isolation.
Seed known omissions: use separate copies of the export example with the tenant rule or over-limit behavior removed. Repeat reviews in fresh sessions and record detection, missed issues and incorrect findings.
Review the reviewers: have an engineer classify each finding as a real missing decision, a useful clarification or unnecessary work. Require a reason before adding a dependency or component.
Implement and measure: compare accepted changes, total human effort, agent usage, reopened work and defects found by the same acceptance checks. Repeated runs and comparable tasks reduce the risk of mistaking one favorable result for a reliable improvement.

Set the pass criteria before running the pilot. For this example, require the seeded access and limit omissions to be identified, no unresolved high-impact design decisions at approval, and an agreed ceiling for additional review effort. Failure should lead to a smaller workflow, different reviewer instructions or a decision to stop using it for that class of task.

When is the full workflow worth using?

We would use the full EGM workflow when important design choices remain open and resolving them late would be expensive. Choose a lighter path when the behavior is already clear. That follows the project’s guidance to use the skills selectively, while keeping the adoption decision tied to your own delivery evidence.

Our proposed fit criteria
Work	Suggested approach	Reason
New feature with permissions or data boundaries	Pilot the full design and review flow.	Missing behavior can become expensive implementation work.
Change spanning existing modules	Review the specification against current code.	Compatibility and ownership need explicit decisions.
Existing, detailed specification	Start with the relevant review stages.	Rewriting a useful document adds little by itself.
Small fix with a precise failing test	Use the normal fix, test and review process.	The behavioral decision may already be settled.
Unvalidated product idea	Test the user need before detailing implementation.	A coherent design cannot establish customer demand.

Our recommendation

Pick one feature whose unresolved decisions you can name. Use EGM to make those decisions reviewable, keep the implementation scope small and measure whether the added review earns its cost. Preserve rejected alternatives so the next session can understand the choices without replaying the conversation.

Wavect’s AI enablement service can help define that pilot around your repository and acceptance criteria.

After implementation, EGM’s drift-report skill can compare design documents with current source and report discrepancies. Use those findings to maintain the design and review deviations alongside test results.

Elephant-Goldfish Model FAQ

Is EGM a new Google language model?

EGM is an open-source plugin containing skills, reviewer personas and document standards for coding agents. It does not provide a new set of model weights. Your chosen environment supplies the language model and tools. Evaluate the complete setup, including the model, permissions and review instructions, when deciding whether the workflow helps your team.

Must Elephant and Goldfish use different models?

The defining separation is conversation context. A Goldfish must not inherit the conversation that produced the design. Using a different model is a separate choice you can evaluate, but it does not replace that requirement. Two models given the same incomplete specification can still miss the same issue, so keep concrete acceptance checks and human review.

Can I use an existing design document?

Yes. The review skill accepts a target document, and the workflow supports choosing the stages that address your current need. Check that the document explains the system and links to the source it relies on. If it lacks an implementation plan, review the feature design first instead of treating missing implementation details as completed work.

Do I have to accept every reviewer suggestion?

No. The engineer owns architectural decisions. Check each finding against the requirement and current code, then resolve it or record why another choice is appropriate. The second Zoom Out stage is useful when criticism has added unnecessary components. A longer report or a more complicated architecture is not evidence of a better result.

Does fresh context guarantee an unbiased review?

Fresh context removes the earlier conversation as a source of unstated knowledge. It does not guarantee independent reasoning, complete source material or correct conclusions. Reviewers can share model limitations and misunderstand the same requirement. Use explicit criteria, compare findings with repository evidence and retain human accountability for consequential decisions.

What should happen when implementation changes the design?

Record the changed requirement or justified deviation in the design document, and link it to the implementation change. EGM’s drift report can help identify disagreements between documentation and source. A report with no findings is not proof of correctness: run the acceptance tests and review the affected behavior before accepting the change.