A fresh reader is a useful constraint
A long AI coding conversation can feel productive right up to the moment someone else tries to implement it. The missing detail is often something everyone in the chat thinks is obvious. Google’s October 22 open-source announcement offers a structured response: the Elephant-Goldfish Model plugin separates a context-rich design session from fresh sessions that critique the resulting specification.
In Google's description, the Elephant develops the plan while Goldfish reviewers inspect it without the designer's conversational history. The announced process includes checking comprehension, challenging assumptions, and deciding whether the specification is ready for implementation. The plugin is Apache 2.0 licensed. These are workflow mechanisms and stated goals, not a guarantee that generated software will be correct.
The repository describes a path from brainstorming to a living design document, review, and implementation against an approved plan. It also provides installation guidance for several agent environments. Check the instructions for your actual environment rather than copying a command intended for another one.
Our interpretation is that the most useful beginner lesson is surprisingly human: make the plan understandable to someone who was not there when you invented it. You can practice that with a person, a fresh AI conversation, or the documented plugin workflow. The exercise below is our own proposed example, not a claim that we used the plugin to build or test a real application.
Imagine a tiny website where students save public event links. It sounds simple enough to prompt in one sentence. But what does save mean? Can people edit each other's entries? What happens when a link is duplicated? Is the list private? A good design discussion turns those hidden decisions into readable commitments before implementation starts.
Source: Google Open Source: Introducing the Elephant-Goldfish Model plugin ↗ · Google: Elephant-Goldfish Model repository ↗ · Google: EGM getting started ↗
Give the example a small, testable promise
Start the hypothetical project with a plain promise: one person can keep a private list of event links on one device. That is intentionally narrower than a social platform. The proposed first version does not need accounts, invitations, a recommendation engine, or automated reminders. A narrow promise gives the reviewer a boundary they can actually examine.
Now write a concrete interaction. A user pastes a public event URL, enters a title, and saves the entry. The entry appears in a list and remains available after a page reload in the intended environment. If any of those statements is undecided, leave it as a question rather than letting an implementer guess.
Then describe failure. The URL might be empty. The title might contain only spaces. The same link might already be saved. The browser might not allow persistence. For this exercise, decide what the user should see in each case. You do not need elaborate wording yet; you need an agreed behavior.
This is where a planning conversation earns its time. Ask the AI to find decisions you have not made, rather than to expand the feature list. A suggestion to add team sharing may sound exciting but does not resolve what the save button does when storage is unavailable.
Write an explicit non-goal paragraph. For the example, say the first version is not intended to sync across devices or handle sensitive records. That helps stop a reviewer from evaluating the plan as if it promised a full service. It also stops an implementer from silently adding complexity.
Finally, write one acceptance example in ordinary language. Given an empty list, when a valid title and URL are saved, the list shows one entry. Then add an error example. These examples are proposed design aids, not executable tests we have run. They make the desired behavior discussable before anyone writes a component.
Turn the chat into a handoff document
A conversation contains decisions, rejected ideas, jokes, tentative suggestions, and corrections. A handoff document should make the current decision easy to find. For our example, use a short structure: problem, intended user, behavior, data, constraints, unresolved questions, and acceptance examples. You can adapt that structure without claiming it is the plugin's required template.
In the behavior section, describe the add, edit, remove, and empty states only if they belong in your first version. Avoid phrases such as intuitive editing. They sound finished while leaving the actual interaction undefined. Does editing replace the saved value immediately or require a second save? What happens if the user cancels? A reviewer needs those answers.
The data section can be simple. Name the information each entry needs and what identifies an entry independently of its visible title. If you do not know the correct implementation, state the required behavior and ask the designer to propose alternatives. Do not invent a technical detail just to make the document look complete.
Keep rationale close to the decision it explains. If you choose to allow duplicate URLs, explain why. Perhaps the same event may be saved for different purposes. If you choose to reject duplicates, explain what counts as the same URL. The point is not to find a universal answer; it is to avoid an invisible rule.
For an existing repository, a useful plan also identifies which files or interfaces are expected to change after inspecting the actual code. A model should not fabricate paths from a vague project description. If the plan depends on a file, verify that it exists and that its role matches the plan.
End the handoff with unresolved questions. An honest open question is less dangerous than a confident paragraph that quietly chooses for you. The document becomes useful when another person can tell which decisions are final, why they were made, and what still needs an owner.
Ask the fresh reviewer to explain before criticizing
For the first review pass, give the reviewer only the document they are supposed to implement from. Ask them to describe the user journey, the stored information, and the failure behavior in their own words. This is a proposed practice inspired by the announcement's comprehension stage. It tests the clarity of the artifact, not the reviewer's talent for guessing your intent.
Suppose the fresh reader says the example app synchronizes entries across devices. If your plan never promised that, find the phrase that suggested it. Maybe saved securely in your account slipped into the draft even though the project has no accounts. Fix the contradiction instead of adding another chat message saying what you really meant.
Next ask for ambiguities that could produce two reasonable implementations. This wording is useful because it moves beyond vague criticism. A reviewer might identify that deleting an entry could mean immediate removal or a confirmation step. You can then choose one based on the actual user need.
Do not treat agreement among several AI reviewers as independent proof. They may share assumptions or overlook the same issue. The fresh context is a way to reduce dependence on a particular conversation, not a guarantee of independent judgment. A human still needs to decide which objections matter.
A helpful response format for the reviewer is: ambiguous statement, two possible interpretations, consequence, and question for the owner. For example, persistence after reload could mean local browser storage or server storage. Those interpretations change privacy, availability, and implementation work. The plan should say which promise it makes.
Keep each critique attached to a decision. If the reviewer proposes unrelated features, ask whether they are necessary to satisfy the stated first-version promise. Review is most useful when it sharpens the existing project rather than turning a small application into an endless planning exercise.
Resolve objections with evidence, not more confidence
The design conversation now has a concrete job: resolve the review findings. For each issue, record the decision and its reason. If the reviewer misunderstood a clearly written boundary, you may decide no change is needed. If the plan contains two conflicting requirements, revise it. If the answer depends on the existing code, inspect the code before declaring the question settled.
For the event-list example, imagine an objection about storage failure. A weak response says the app will handle errors gracefully. A stronger proposed decision says the entry stays in the editing form, a clear message explains that saving did not complete, and the list does not show a success state. That gives implementation and review something observable.
Another hypothetical objection concerns imported links. The first-version plan might allow arbitrary pasted text but describe it as a URL. Decide what validation is required and how rejected input is explained. Do not let a visual mockup stand in for a data-handling decision.
There is also a stopping rule. Set a small review budget appropriate to the project, then identify which open issues block implementation and which can wait. A private prototype might tolerate rough visual polish. An unresolved promise about where data is stored affects the basic design and should be answered first.
The goal is not to produce the longest document. It is to remove consequential guessing. If a paragraph does not help someone understand the desired behavior, a constraint, or a trade-off, shorten it. If an example exposes a missing decision, keep it even if the example looks less sophisticated than the architecture diagram.
This is also where the owner should challenge the AI's additions. Ask which requirement justifies a proposed dependency or service. If no requirement needs it, the simplest useful plan may leave it out. A design review should make choices clearer, including the choice to build less.
Carry the approved plan into implementation and learning
Once the example plan is stable, treat implementation as a separate stage with its own evidence. The EGM repository explicitly places implementation after design review. In our proposed exercise, the implementation request should identify the approved document and ask the coding agent to flag contradictions instead of silently changing the product promise.
Keep the first implementation slice small. Build the empty list, the form, and a single successful save path before expanding. Then check the failure examples you wrote. This is a suggested workflow for a future project; we are not reporting that a particular generated app passed these checks.
When a code change forces a design change, update the plan deliberately. Perhaps the chosen environment cannot provide the persistence behavior you expected. That is a reason to revisit the promise, explain the trade-off, and review the revised behavior. It is not a reason to leave the document describing something the app no longer does.
For a learner, the useful artifact is the difference between the first plan and the reviewed plan. Save both. Highlight the ambiguities the fresh reader found and the decisions you changed. That record teaches more than a screenshot of a finished interface because it shows how your judgment developed.
You can run the communication part of this exercise without installing anything. Write the one-page event-list plan, hand it to a friend who missed the conversation, and ask them to explain what they would build. If they must ask about core behavior, you have found worthwhile planning work.
Google's new plugin makes this design-and-review pattern easier to organize in supported agent environments. The durable idea is accessible even before installation: put a readable artifact between intention and action, then let a fresh reader challenge it. Faster code is useful when the person directing it can still explain what the software is supposed to do.
Try this, then make it yours.
Write a one-page plan for a private event-link list. Give it to a fresh reader with no chat history. Ask for their reconstruction of the behavior and three places where two implementations could reasonably differ.
Explore the tool ↗Follow the signal.
Our reporting starts here. Practical suggestions are our analysis, and vendor performance statements are claims unless independently verified. We haven’t hands-on tested this release.
- Google Open Source: Introducing the Elephant-Goldfish Model plugin ↗ · 2026-10-22
- Google: Elephant-Goldfish Model repository ↗
- Google: EGM getting started ↗
