AIDiveDer Plan, den niemand prüfte
Googles Elephant-Goldfish Model (EGM) ist ein kostenloses Claude-Code-Plugin, bei dem Reviewer ohne Gedächtnis deinen Plan lesen, bevor irgendein Code geschrieben wird. Wir haben es installiert und ein echtes Feature unserer eigenen App vom Plan bis zum lauffähigen Code gebracht: ein Reservierungssystem für eine Familien-Wunschliste, gebaut mit Next.js und einer Notion-Datenbank, auf einer Kopie des Repos.
Die Race Condition hat der Planer selbst gefunden. Die Lücken, die wirklich zählten, waren zwei, die er nie sah: Die Eltern konnten in ihren eigenen Hosting-Logs lesen, wer was reserviert hat, und ein gespeichertes Browser-Cookie ließ sich wiedereinspielen, um die Reservierung eines anderen zu stornieren. Nur die Reviewer ohne Gedächtnis fanden sie. Das Feature, das aus dem geprüften Plan entstand, hatte in allen dreißig Races um das letzte Geschenk genau einen Gewinner, getestet gegen einen Ersatz für Notion. Und bei einem kleinen Fix kostet das Review weit mehr als der Fix selbst, also lässt du es weg.
Der Ablauf unten hat fünf Schritte: Installation, Brainstorm und Draft, Review, Resolve, Build. Der letzte Abschnitt gibt dir die Regel, wann du das alles überspringst.
Was EGM ist, und die Installation mit zwei Befehlen
Wenn du Claude Code einen Plan für ein Feature schreiben lässt, ist der Agent, der den Plan geschrieben hat, derselbe, den du bittest, ihn zu prüfen, und er sieht seine eigenen blinden Flecken nicht. EGM, das Elephant-Goldfish Model, ist Googles kostenloses Plugin für genau dieses Problem. Das Repository stellt klar, dass es kein offiziell unterstütztes Google-Produkt ist.
Der Elefant ist der Agent, mit dem du die ganze Zeit sprichst: Er hält das gesamte Gespräch im Kopf und schreibt den Plan mit dir. Die Goldfische sind Reviewer-Agenten ohne Gedächtnis. Sie lesen nur den Plan und deinen Code, so wie ein Kollege einen Pull Request prüft, ohne im Design-Meeting gesessen zu haben. Sie können deinen Code lesen, aber nicht ändern, sie sehen deine Projektnotizen nicht, und bei jeder Entscheidung, die sie aufwerfen, hast du das letzte Wort. Die Idee stammt von Dave Rensin, der schrieb, dass wir, wenn wir nicht aufpassen, nicht nur schneller Code schreiben, sondern unsere Fehler in Massen produzieren.
Die Installation läuft aus deinem Projektordner mit zwei Befehlen:
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm --scope project
Der erste fügt Googles Repo als Plugin-Marketplace hinzu, eine Liste, aus der Claude Code Plugins installieren kann. Der zweite installiert das Plugin nur für dieses Projekt. Beide gaben nach etwa fünf Sekunden ein grünes Häkchen zurück; starte eine neue Session, damit das Plugin geladen wird. Die Doku verlangt Claude Code 2.1.271 oder neuer, weil die Reviewer auf die Einstellung omitClaudeMd angewiesen sind, die deine Projektnotizen vor ihnen verbirgt.
Dann füge eine Zeile in deine CLAUDE.md ein, damit die Reports in einem Ordner landen statt im Wurzelverzeichnis des Repos:
EGM artifact directory: docs/egm
Die Befehle kosten nichts, bis du einen eingibst: Keiner von ihnen wird von selbst in deine Session geladen. Die Grenze: Die Goldfische lesen nur Dokumente. Sie führen deine App nicht aus, und sie nutzen dasselbe Modell wie du, können also dieselben blinden Flecken teilen.
Brainstorm und Draft an einem echten Feature
Der Brainstorm ist für den Moment, in dem du etwas bauen willst, bei dem eine falsche Entscheidung dich später teuer zu stehen kommt. Unsere App ist eine Familien-Wunschliste: Verwandte haken ab, was sie gekauft haben, und die Liste liegt in einer Notion-Datenbank. Alles lief auf einer Kopie des Repos, ohne Zugriff auf die echte Liste.
Das Feature: Ein Verwandter soll ein Geschenk reservieren können, damit niemand dasselbe Geschenk zweimal kauft; die Eltern sollen nicht sehen, wer was reserviert hat; und eine Stornierung soll möglich sein. Du tippst den Brainstorm-Befehl, gefolgt vom Feature in einem Satz:
/egm:egm-brainstorm Let a relative reserve a gift on the list so two people never buy the same one. Parents must not see who reserved what. A reservation can be cancelled.
Bevor er etwas fragte, las er den Code und wies darauf hin, dass die App gar nicht weiß, wer jemand ist, weil sich alle mit einem gemeinsamen Passwort anmelden. Dann stellt er in mehreren Runden Fragen, und ein kleiner Schwarm Goldfische schaut sich die Idee an, bevor ein Abschnitt geschrieben wird. Du antwortest wie der Product Owner. Unsere Antworten: ein gemeinsames Passwort, ein Verwandter tippt nur einen Vornamen, und nichts, was ihn benennt, landet dort, wo die Eltern hinschauen. Der Schwarm brachte etwas auf, das wir nicht benannt hatten: die alte Edit-Route, über die weiterhin jeder eine Menge von Hand ändern könnte.
Der Planer benannte auch die Race Condition selbst: Verwandte, die im selben Moment auf Reservieren drücken. Eine Race Condition liegt vor, wenn zwei Requests denselben alten Wert lesen und beide schreiben, sodass ein Update stillschweigend verloren geht, und Notions Doku bietet keine Möglichkeit, eine Zahl atomar zu erhöhen.
Als Nächstes schreibt /egm:egm-draft docs/egm/concepts_brief.md das Design-Dokument Abschnitt für Abschnitt: den schriftlichen Plan jeder Datei, bevor Code entsteht. Er hielt fünfzehnmal an, um zu fragen. Du genehmigst einen Abschnitt oder wählst zwischen Architekturoptionen, jede mit der Angabe, wie sie scheitert. Eine Wahl betraf den Ort der Reservierung eines Verwandten; wir nahmen ein signiertes Cookie im eigenen Browser, damit nichts mit seinem Namen den Server erreicht. Der Draft räumte in seinen eigenen bekannten Grenzen sogar ein, dass sein Fix für die Race nicht funktionierte, weil beide Verwandten denselben Wert lesen würden. Du beendest diesen Schritt mit einem genehmigten Design-Dokument in deinem Repo.
Das Blind-Review: neun Reviewer, zwei Lücken, die der Planer nie sah
Das Review ist für den Moment, in dem du und dein Agent den Plan beide für solide haltet, und genau dann siehst du nicht, was fehlt. Du tippst /egm:egm-review docs/egm/gift-reservations.md; es fragt, ob die Reviewer noch etwas anderes lesen sollen, und dann nach einem Modus. Der konsolidierte Modus fährt alle Stufen ohne Pause durch und liefert eine zusammengeführte Liste von Maßnahmen.
Die fünf Stufen sind Initial Zoom Out Review (löst das Design das richtige Problem), Comprehension Review (würde ein Neuling es verstehen), Design Critique (Struktur und Formulierung), Intermediate Zoom Out Review und Implementation Readiness, das deinen tatsächlichen Code liest und jeden Schritt des Plans dagegen prüft. Jede Stufe schickt frische Goldfische los, die das Gespräch nie gesehen haben.
Bei unserem Design liefen neun Reviewer in 7 Minuten 24 Sekunden, ohne das Dokument anzufassen; es schrieb nur Reports.
| Review-Ergebnis | Anzahl |
|---|---|
| Reviewer-Subagents | 9 |
| Rohbefunde | 77 |
| Blocker / Major / Nit | 1 / 42 / 34 |
| Zusammengeführte Maßnahmen | 12 |
Die Race fand es nicht: Jeder Befund zur Race zitierte nur das Eingeständnis des Planers zurück. Es fand zwei Lücken, die niemand angesprochen hatte:
- Privatsphäre. Den Eltern gehört der Hosting-Account samt Request-Logs, und diese Logs mit Uhrzeit und Geschenk würden verraten, wer was reserviert hat.
- Sicherheit. Eine gespeicherte Kopie des Browser-Cookies ließ sich wiedereinspielen, um die Reservierung eines anderen zu stornieren.
Es fing auch Code-Details ab, die erst beim Build aufgefallen wären, etwa dass die Route-Parameter des Frameworks asynchron sind und dass ein Build für einen großen Teil des Plans kaputt geblieben wäre. Bei der Race, die es schon kannte, bestand sein Fix darin, das Ziel abzuschwächen, und diesen Rat solltest du zurückweisen.
Resolve: Du entscheidest, auch gegen die Reviewer
Im Resolve-Schritt wird aus einem Haufen Befunde eine Entscheidung. /egm:egm-resolve macht aus jedem Report eine Tabelle, jedes Problem mit einem Vorschlag: eskalieren, anfechten, ablehnen oder einen Fix vorschlagen. Du nimmst einen Fix an oder fichtst ihn mit deiner Begründung an, und es wendet nur an, was du akzeptierst. Du kannst die eskalierten Probleme selbst beantworten und den Rest automatisch annehmen lassen.
Unser Lauf listete siebenunddreißig Probleme, und Resolve hatte die Reviewer bereits gegen den Code geprüft: Es markierte einen Befund als falsch, eine Datei, die als ungenutzt galt, obwohl die Login-Seite sie noch importiert.
Das große Thema war die Race. Der Blocker schlug vor, das Ziel umzuschreiben in „verringert doppelte Käufe, verhindert sie nicht". Wir fochten das an und verlangten genau einen Gewinner, mit Notion als einzigem Speicher und ohne Namen. Der Agent weigerte sich, das vorzutäuschen: „Notion kann das nicht. Es hat weder ein bedingtes Schreiben noch ein atomares Erhöhen." Er bot ein paar Auswege an, und wir wählten ein Claim Ledger: eine Liste anonymer Notizen auf der eigenen Notion-Seite des Geschenks, eine pro Reservierung, der Reihe nach gelesen, um zu entscheiden, wer das Geschenk bekommt. Das schloss auch die Cookie-Lücke, denn der Browser hält jetzt nur noch deinen eigenen Eintrag, sodass du nur stornieren kannst, was du selbst reserviert hast.
Die Grenze: Dieser Fix kam nach dem Review, also hat ihn kein Goldfisch gelesen, und er setzt voraus, dass Notion bei gleichzeitigen Schreibvorgängen eine einheitliche Reihenfolge einhält, was die Doku nicht verspricht. Das Design sagt, du sollst den Race-Check vor dem Release auf einer Kopie der echten Datenbank ausführen.
Build nach Plan in einer frischen Session, dann die Race testen
Das Risiko beim Build ist ein Agent, der auf halbem Weg improvisiert und von dem abweicht, was du entschieden hast. Öffne eine frische Session, eine neue Konversation, die nur weiß, was in deinen Dateien steht, und gib ihr das Design:
Build the feature exactly to the approved design in docs/egm/gift-reservations.md; add tests.
Unsere arbeitete 7 Minuten 56 Sekunden allein, änderte 24 Dateien, und die Suite kam mit Tests 216 passed (216) zurück. Sie meldete, wo sie vom Plan abgewichen war (eine ältere Version des Test-Runners, weil die neueste ein neueres Paket brauchte), und fragte vor dem Upgrade nach. Außerdem fand sie einen instabilen Test in ihrem eigenen Setup und machte ihn deterministisch.
Dann teste den riskanten Pfad selbst, denn eine grüne Suite beweist nur, was jemand zu testen eingefallen ist. Zwei Verwandte am letzten Geschenk in derselben Sekunde, dreißigmal mit unterschiedlichem Timing: Jedes Mal ging genau eine Reservierung durch, und der andere erfuhr, dass das Geschenk vergeben war. Die Ansicht der Eltern zeigte das Geschenk als vollständig, ohne irgendwo einen Namen, und eine Stornierung stellte es wieder her.
Diese Tests laufen gegen einen Ersatz für Notion, der sich wie das Original verhält, ohne atomares Erhöhen und mit zufälligen Verzögerungen. Das ist die allgemeine Regel für externe Dienste in Tests: Du fakest sie, aber der Fake muss so feindlich sein wie das Original. Führe vor dem Release den Race-Check des Designs auf einer Kopie der echten Datenbank aus; die Testdatei dokumentiert sogar den Fall, in dem beide Verwandten gewinnen würden.
Wann du es weglässt: die Regel
In derselben App behauptete die README noch, es gebe überhaupt keinen Login, obwohl die Seite ein Passwort hat: ein Fix von einer Zeile. Claude Code ohne Plugin prüfte den Code und behob es in Sekunden.
| Weg | Kosten (API-Preise, Sonnet 5.5) | Zeit |
|---|---|---|
| README-Fix, Claude Code ohne Plugin | $0.0455 | 10 s |
| EGM Brainstorm, Draft, Review, Resolve (vor jedem Code) | $7.10 | 32 min |
Googles README sagt dasselbe: „Nutze es, wenn ein Feature vor der Umsetzung Designentscheidungen braucht. Für einen kleinen, klaren Bugfix nimm deinen normalen Coding-Workflow." Die FAQ ergänzt, dass das Durchlaufen des Workflows keinen Produktivitätsgewinn beweist, und ein kleiner Pilotversuch auf einem Coding-Blog fand, dass das Review bei einem Feature, das ein einfacher Plan schon im Griff hatte, nichts brachte.
EGM lohnt sich dort, wo sich ein Fehler außerhalb des Gesprächs versteckt, wie hier in den Logs der Eltern und im wiedereinspielbaren Cookie. Beim Problem, das der Planer schon kannte, war die Entscheidung, die es löste, unsere. Die Regel: Bevor du den Build-Prompt tippst, frag dich, ob ein Fehler hier fremde Daten, Privatsphäre, Rechte oder Geld berührt. Wenn ja, führe das Review aus, bevor du baust.
