Ask an AI to review the plan it just wrote and it tends to call it a good plan. It already knows why every choice was made, so it fills in whatever the plan leaves out without noticing.

EGM (the Elephant-Goldfish Model) has a simple answer: don't show the reviewer the conversation. To see whether that actually helps, we built the same feature twice, once with EGM and once with Claude Code's plan mode.

The accompanying video is in Korean; this post covers the same experiment in English.

In this post we cover:

1. What EGM is and why it erases memory
2. How it differs from plan mode
3. How we ran the experiment
4. What a full EGM run looks like
5. The moment two goldfish made us remove a design decision
6. Results: a tie on tests, a 28x gap on cost
7. The real difference: one question nobody asked
8. When to use it and when not to
9. Limits of this experiment

How to read the numbers. [Official docs] means material written by the makers, such as the EGM repository and the Claude Code docs. [Measured] means results from our own runs. Every measurement used the same model (Claude Sonnet 5.5 at xhigh effort), and each method ran only once. Read them as "this is what happened this time."

1. What EGM is and why it erases memory

EGM is an open-source plugin released in September 2026 in the google/elephant-goldfish-model repository. The tagline at the top of the repository is "Design with an elephant. Review with a goldfish." Despite the location, the README ends by saying it is not an officially supported Google product [Official docs] (repository).

There are three roles [Official docs].

Goldfish are built with Claude Code subagents. A subagent is a separate AI that the main AI launches to take on a task. It starts in its own empty conversation and returns only its result [Official docs] (subagents docs). Because it never saw the earlier conversation, it can't be talked into anything, and assumptions that aren't written down get caught. It's the same reason people miss typos in their own writing.

Writing the design before the code, then generating the code from the design, is called Spec-Driven Development. EGM is one way of doing it.

2. How it differs from plan mode

Plan mode is built into Claude Code. It reads the code and shows you a plan before editing any files, and implements once you approve [Official docs] (permission modes docs).

3. How we ran the experiment

We prepared a small one-day class booking app of about 760 lines, with a class list, booking, "my bookings," and cancellation. The feature fit in one sentence, translated here from the Korean original:

Let people join a waitlist for full classes, and when someone cancels, automatically give the seat to the first person on the waitlist.

Both methods received exactly the same sentence, letter for letter. We measured in two separate runs. [Measured]

• The preliminary experiment. We fixed the tests before seeing any results. 28 hidden tests lived outside both project folders, and we confirmed that they never appeared in either transcript. We also tracked time and cost. Every test and cost number in this post comes from this run.
• The recorded run. For the video, we ran the same request again from scratch. The scenes and numbers in sections 4 and 5 mostly come from this run. Cost wasn't measured here.

We keep them apart for a reason: the same model given the same request produced different results. Section 7 returns to this.

4. What a full EGM run looks like

Install

These are the two lines from the README [Official docs].

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

Bootstrap: lay out notes for the goldfish

Run /egm:egm-bootstrap .. Goldfish can't see the conversation, so the code has to explain each folder's role on its own. Bootstrap writes a README per folder, a kind of contract covering what the folder does, what it exposes, and what it must always uphold. Here four subagents split the job and seven READMEs appeared. [Measured]

Brainstorm: the elephant's questions and six goldfish

We ran /egm:egm-brainstorm followed by the request. Where plan mode would write a plan, the elephant read the code and asked five questions: what people do today when a class fills up, how a waitlisted person learns they got a seat, what the waitlist limit should be, whether a database already exists, and so on. It also flagged a weakness in the request up front: there was no way to notify anyone. [Measured]

Once the answers were in, six goldfish launched at once. Each checked one thing: whether it makes sense, whether the structure holds, whether the design is good, whether there's an easier way, whether it can be built as written, and whether it matches the real code. Their results merged into a single concepts_brief.md, which took about nine minutes. [Measured]

One finding stood out.

The lifecycle of waitlist entries after a class starts is undefined. Nothing on the server cleans up, so waitlist rows stay behind after the class begins. All six lenses flagged the same issue, and we had never asked about it. [Measured]

Draft: decisions go to the human

/egm:egm-draft writes the design document one section at a time, pausing after each. Technical decisions come with a few options and the conditions under which each one fails, and you choose. In the recorded run we made four decisions ourselves, including the "no line-cutting" rule discussed in the next section. [Measured]

Five review stages

With /egm:egm-review, goldfish review the design document in five stages, numbered 5 through 9 [Official docs] (review skill).

In the recorded run this took over an hour and produced more than thirty significant findings. [Measured]

Build and drift report

We built the feature in a fresh session with the conversation cleared, working only from the design document. It took about eight minutes and 59 tests passed. Finally, /egm:egm-drift-report looks for mismatches between docs and code. Drift is what happens when the two gradually stop agreeing. It found zero places where code departed from the design and seven doc-side mismatches, such as a design status still marked "proposed" and a README missing a new call. [Measured]

5. The moment two goldfish made us remove a design decision

At the draft stage we chose no line-cutting: if a seat is open while people are waiting, reject new bookings.

Then the Stage 5 and Stage 7 goldfish, which know nothing of each other's conversations, separately raised the same objection. Normally the first person on the waitlist gets the seat the instant someone cancels, so an open seat with a waiting list simply doesn't occur. That state only appears when an operator edits the capacity directly in the database. We were adding rules, screens, and tests to guard against one rare case. [Measured]

So we reversed our own decision and dropped the rule. The design document moved it to "alternatives not adopted," with the reason recorded: the state it guards against can only be created through operator SQL, and the cost outweighs the benefit. A similar scene happened in the preliminary experiment, where three rules and about 90 lines went away. [Measured]

This was our favorite moment in the experiment. The review didn't add to the feature. It took something away.

6. Results: a tie on tests, a 28x gap on cost

These are the numbers from the preliminary experiment. [Measured] Cost is the cumulative session cost reported by Claude Code.

The hidden tests covered tricky cases such as waitlist order, bookings racing a cancellation, double cancellation, 20 simultaneous bookings, and migrating an old database. We also checked that the tests could fail: a version deliberately changed to promote "a moment after the cancel" did fail.

On an app this size, EGM did not pass more tests. Plan mode also handled promotion inside the same transaction as the cancellation (a transaction is a group of operations processed as one unit, so nothing can cut in halfway) and also skipped waitlisted people who already held a booking.

Most of EGM's $23.16 was spent before any code was written.

The goldfish produced 107 findings in total (13 in brainstorm, 94 in review). The 94 split into 30 Major and 64 minor Nit findings, with no Blockers. Writing the code was about 5% of the total, and more than half went to review and resolving findings.

7. The real difference: one question nobody asked

In the preliminary experiment, plan mode wrote down five assumptions and built without asking anything. EGM asked how waitlist entries should appear after a class starts, and left that decision to a human.

We ran both apps on the same data and opened a class that had started at 18:30 at around 21:40. [Measured]

• Plan mode app: "My bookings" still said the user was first on the waitlist and would be booked automatically when a seat opened.
• EGM app: That line was gone.

After seeing the results we wrote two extra tests: plan mode scored 0/2 and EGM 2/2. One covers this post-start waitlist display. The other is line-cutting in the operator SQL case from earlier.

This doesn't mean "EGM is more accurate," though. We wrote those tests after reading EGM's findings, and plan mode was never asked the question. It's not a fair pre-registered test. It's an observation of what the questioning stage does.

The recorded run changed the picture again. Plan mode again asked zero questions and finished building in about seven minutes with 48 tests passing, but this time its assumptions included hiding the waitlist for started classes. The same model varies from run to run. It also assumed "no waitlist limit" on its own, while we had around 20 per class in mind. [Measured]

So the difference isn't "plan mode misses things." In plan mode the AI decides for you, right or wrong. In EGM a human decides. With luck the answers match, but you may never learn that a decision was made.

8. When to use it and when not to

EGM's own docs say not to force this process onto a simple bug fix, and to use whichever skill addresses your current bottleneck [Official docs] (getting started). You don't have to run the whole sequence, so using just the goldfish review is an option. The README also states that a review doesn't replace tests or human judgment [Official docs].

In one line: it's expensive, but it makes you answer questions you didn't think to ask.

Limits of this experiment

• Each method ran once. As the recorded run showed, the same model varies, so we don't know the variance.
• This is a small 760-line app. Results may differ on a large repository or a project shared by many people.
• The two after-the-fact tests aren't a fair pre-registered test. We found no test in the other direction, where only EGM fails, but we didn't try very hard to find one.
• The preliminary experiment stopped without resolving the Stage 9 findings because of budget (4 Major findings left open). Apart from some confirmed defects, most Stage 5, 6, and 8 findings also went unresolved. Handling everything would have cost more.
• We saw the design document grow as a side effect: resolving findings took it from 1,077 to 1,186 lines, and some findings repeated across stages.
• We didn't do thorough human testing of the app itself.
• The experiment used EGM 0.1.0. The repository changes quickly, so commands and docs may have moved on.

Watch the video

The full process from install to build, with real execution screens (in Korean):

• Google's EGM vs Plan Mode: what happens when an AI with no memory reviews a design

Sources

• google/elephant-goldfish-model: README, install commands, role descriptions, license note
• EGM getting started, review skill
• Claude Code plugins docs, subagents docs, permission modes docs