Elephant Goldfish Model: review plans before coding

Why it matters

An AI coding agent can implement a bad decision accurately. A product deletion endpoint might work exactly as requested while breaking the history of every order that references that product. Passing tests offers limited reassurance when nobody specified the rule those tests should protect.

The Elephant Goldfish Model, or EGM, separates developing a proposal from challenging it. The useful idea is that a design should remain understandable when it leaves the conversation that created it. For developers maintaining existing applications, that is a practical way to expose assumptions buried in chat history.

AI LABS provides the demonstration in this video. My contribution here is an evaluation method: pick a consequential change, write observable acceptance rules, require evidence for review findings, and account for the human effort involved. The project lives under Google's GitHub organization, but its README states that it is not an officially supported Google product. Official EGM repository.

Key points

• 00:31 Planning also produces completion criteria. This gives the eventual implementation a target that another developer can inspect without reading the original conversation.
• 01:34 The Elephant retains project knowledge and develops the proposal. Its useful output is a document that carries the necessary decisions forward.
• 02:06 Goldfish reviewers examine the plan and code without the earlier chat. Missing assumptions become harder to conceal behind conversational familiarity.
• 03:40 The video challenges reviewing a plan within the conversation that produced it. A separate reviewer has an opportunity to question previously accepted choices.
• 04:12 Human judgment filters the findings. A long report still needs someone to distinguish product decisions from actionable defects.
• 06:19 During the demonstrated setup, the agent generated an incorrect instruction about subagents. Generated configuration deserves inspection alongside generated code.
• 07:23 Bootstrap documents the existing application by directory. The demo produced 28 READMEs, illustrating a meaningful preparation cost.
• 08:26 The presenters discover that documentation needs a reliable route into the agent's work. They adjust project instructions to reference relevant READMEs.
• 10:36 Brainstorming develops the proposal and sends it through reviewers before producing a concept brief. Unresolved business choices belong here.
• 11:39 The design draft covers critical user journeys, boundaries, and alternatives. Those sections provide material for later acceptance tests.
• 12:42 Five review rounds challenge the design before implementation. Each round offers a chance to resolve an issue while changes are still relatively contained.
• 13:46 Drift reporting compares documentation with code. Differences need investigation because either side may have become outdated.
• 14:18 The channel reports finding a rule violation: sellers could delete previously sold products when the documented behavior allowed only hiding them.
• 14:49 The full process is positioned for consequential features. Small fixes may not justify the additional review stages.

How to apply

Give the Elephant Goldfish Model a focused trial

I would start with a change where an incorrect decision has an observable consequence: order cancellation, inventory updates, or access permissions. A copy change is unlikely to reveal much about the value of a detailed design review.

Write down the evaluation question first: “Can this review find a consequential failure that our usual planning missed?”. Save the initial plan before receiving feedback. Otherwise, it becomes difficult to tell which decisions the review actually improved.

Choose a feature small enough to finish and inspect. A complete application redesign introduces too many variables for a useful first trial.

Use today's installation instructions

The video records a particular setup at a particular time. The EGM documentation consulted for this draft gives these terminal commands for installing the Claude Code plugin:

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

Start a new session afterward. The setup guide calls for the complete plugin because copying only the skills omits files they need. Follow the instructions for your actual environment. EGM installation guide.

Inspect the resulting project changes. If a generated instruction makes a claim about subagent capabilities, check it against the installed version's behavior. Treat the video's troubleshooting episode as a reason to verify configuration rather than a universal edit to repeat.

Make the business rule observable

For a hypothetical exercise based on the video's store example, propose the following acceptance matrix before implementation:

| Situation | Expected behavior | Verification | | --- | --- | --- | | Delete a product with no sales | Authorized deletion succeeds | Integration test of the operation | | Delete a previously sold product | Deletion fails; archiving remains available | Attempts through both UI and API | | Open a historical order | Historical product details remain available | Query after archiving the product | | Sale and deletion happen concurrently | The approved rule still holds | Concurrency test using the project's database |

These are proposed requirements for the exercise, not additional findings from the video. Your application may need different rules. The important step is making those choices explicit enough to test.

For example, “preserve order history” still leaves open whether an order stores a snapshot of product details or reads the current product record. That choice changes what implementation and testing must establish.

Review a document that can stand on its own

If a useful design already exists, try reviewing it before documenting the entire repository. The current workflow guide allows individual skills to address the immediate need rather than requiring every stage for every task. EGM workflow guide.

Give the reviewer the design, necessary source references, and specific questions. A practical request would be:

Review this design and its referenced code. For each issue, identify the affected requirement, supporting evidence, a failure scenario, and a way to verify the fix. Separate demonstrable defects from questions requiring a human decision.

Ask the report to name the files it inspected. This helps distinguish findings grounded in the application from generic advice. It also makes missing references easier to spot.

Turn findings into implementation work

Record a disposition for each finding: fix, investigate, or accept with a reason. Attach accepted defects to completion criteria. In the store example, hiding a delete button is insufficient if an API request can still remove a sold product.

After implementation, run the relevant tests and compare the code with the approved design. An intentional behavior change calls for a documentation update. A violation of the approved rule calls for a code change. A clean drift report does not replace executing the tests.

Keep the findings and decisions close to the design so the next developer can understand why the implementation took its current shape.

Count the human work

Track elapsed time, model consumption, human review minutes, and concrete changes to the plan. In a hypothetical run, 30 minutes of agent execution plus 40 minutes spent reading findings represents 70 minutes in the workflow, even when some waiting overlaps other work.

My adoption criterion would be evidence-backed risks and useful tests at an acceptable cost for the change. If the output mostly repeats requirements or offers stylistic suggestions, narrow the next review. More reviewers are useful only when their findings improve decisions.