Google sprawdza plan, zanim Claude Code zacznie budować

Elephant-Goldfish Model (EGM) od Google to darmowy plugin do Claude Code, w którym recenzenci bez pamięci czytają twój plan, zanim powstanie jakikolwiek kod. Zainstalowaliśmy go i przeprowadziliśmy prawdziwą funkcję naszej własnej aplikacji od planu do działającego kodu: system rezerwacji dla rodzinnej listy prezentów, zbudowany w Next.js z bazą Notion, na kopii repozytorium.

Wyścig (race condition) planista znalazł sam. Dziury, które naprawdę miały znaczenie, były dwie i planista ich nie zauważył: rodzice mogli odczytać we własnych logach hostingu, kto co zarezerwował, a zapisane ciasteczko przeglądarki dało się odtworzyć, by anulować cudzą rezerwację. Znaleźli je tylko recenzenci bez pamięci. Funkcja zbudowana ze sprawdzonego planu miała dokładnie jednego zwycięzcę we wszystkich trzydziestu wyścigach o ostatni prezent, na atrapie Notion. A przy drobnej poprawce review kosztuje znacznie więcej niż sama poprawka, więc je pomijasz.

Przepływ poniżej ma pięć kroków: instalacja, brainstorm i draft, review, resolve, build. Ostatnia sekcja podaje regułę, kiedy pominąć to wszystko.

Gdy prosisz Claude Code o plan funkcji, agent, który go napisał, jest tym samym, którego prosisz o sprawdzenie, i nie widzi własnych martwych punktów. EGM, czyli Elephant-Goldfish Model, to darmowy plugin Google na ten właśnie problem. Repozytorium wprost mówi, że nie jest to oficjalnie wspierany produkt Google.

Słoń to agent, z którym rozmawiasz: trzyma w głowie całą rozmowę i pisze z tobą plan. Złote rybki to agenci-recenzenci bez pamięci. Czytają tylko plan i twój kod, tak jak kolega recenzuje pull request, nie siedząc na spotkaniu projektowym. Mogą czytać twój kod, ale nie mogą go zmieniać, nie widzą notatek twojego projektu, a ostatnie słowo w każdej kwestii, którą podniosą, należy do ciebie. Pomysł pochodzi od Dave'a Rensina, który napisał, że jeśli nie uważamy, to nie tylko piszemy kod szybciej, ale masowo produkujemy własne błędy.

Instalacja działa z folderu projektu i wymaga dwóch komend:

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

Pierwsza dodaje repozytorium Google jako marketplace pluginów, czyli listę, z której Claude Code może instalować pluginy. Druga instaluje plugin tylko dla tego projektu. Obie zwróciły zielony znaczek po około pięciu sekundach; uruchom nową sesję, żeby plugin się załadował. Dokumentacja wymaga Claude Code 2.1.271 lub nowszego, ponieważ recenzenci polegają na ustawieniu omitClaudeMd, które ukrywa przed nimi notatki twojego projektu.

Potem dodaj jedną linię do CLAUDE.md, żeby raporty trafiały do jednego folderu, a nie do głównego katalogu repozytorium:

EGM artifact directory: docs/egm

Komendy nic nie kosztują, dopóki jednej nie wpiszesz: żadna z nich nie ładuje się sama do twojej sesji. Ograniczenie: złote rybki czytają tylko dokumenty. Nie uruchamiają twojej aplikacji i używają tego samego modelu co ty, więc mogą dzielić jego martwe punkty.

Brainstorm jest na moment, gdy zamierzasz zbudować coś, przy czym zła decyzja drogo cię później kosztuje. Nasza aplikacja to rodzinna lista prezentów: krewni zaznaczają, co kupili, a lista żyje w bazie Notion. Wszystko działo się na kopii repozytorium, bez dostępu do prawdziwej listy.

Funkcja: pozwolić krewnemu zarezerwować prezent, żeby nikt nie kupił tego samego dwa razy, uniemożliwić rodzicom zobaczenie, kto co zarezerwował, i pozwolić na anulowanie. Wpisujesz komendę brainstormu, a po niej funkcję w jednym zdaniu:

/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.

Zanim o cokolwiek zapytał, przeczytał kod i zauważył, że aplikacja nie ma pojęcia, kim kto jest, bo wszyscy logują się jednym wspólnym hasłem. Potem zadaje pytania w kilku rundach, a mały rój złotych rybek ogląda pomysł, zanim powstanie jakakolwiek sekcja. Odpowiadasz jak product owner. Nasze odpowiedzi: jedno wspólne hasło, krewny wpisuje tylko imię i nic, co go wskazuje, nie trafia tam, gdzie patrzą rodzice. Rój podniósł coś, czego nie nazwaliśmy: stary route do edycji, przez który każdy nadal mógłby ręcznie zmienić ilość.

Planista sam też nazwał wyścig: krewni naciskający rezerwuj w tej samej chwili. Wyścig to sytuacja, gdy dwa żądania czytają tę samą starą wartość i oba zapisują, więc jedna aktualizacja ginie po cichu, a dokumentacja Notion nie oferuje sposobu, by atomowo dodać liczbę.

Dalej /egm:egm-draft docs/egm/concepts_brief.md pisze dokument projektowy sekcja po sekcji: spisany plan każdego pliku, zanim powstanie kod. Zatrzymał się, by zapytać, piętnaście razy. Zatwierdzasz sekcję albo wybierasz między opcjami architektury, z których każda ma opisane, jak zawodzi. Jedna decyzja dotyczyła tego, gdzie żyje rezerwacja krewnego; wybraliśmy podpisane ciasteczko w jego własnej przeglądarce, więc nic z jego imieniem nie trafia na serwer. Draft sam przyznał w swoich znanych ograniczeniach, że jego poprawka na wyścig nie działa, bo obaj krewni przeczytaliby tę samą wartość. Ten krok kończysz z zatwierdzonym dokumentem projektowym w repozytorium.

Review jest na moment, gdy ty i twój agent uważacie plan za solidny, czyli dokładnie wtedy, gdy nie widzisz, czego brakuje. Wpisujesz /egm:egm-review docs/egm/gift-reservations.md; pyta, czy recenzenci mają przeczytać coś jeszcze, a potem o tryb. Tryb skonsolidowany przechodzi przez wszystkie etapy bez zatrzymywania i zwraca jedną scaloną listę działań.

Pięć etapów to Initial Zoom Out Review (czy projekt rozwiązuje właściwy problem), Comprehension Review (czy nowa osoba by to zrozumiała), Design Critique (struktura i sformułowania), Intermediate Zoom Out Review oraz Implementation Readiness, który czyta twój rzeczywisty kod i sprawdza z nim każdy krok planu. Każdy etap wysyła świeże złote rybki, które nigdy nie widziały rozmowy.

Na naszym projekcie uruchomiło dziewięciu recenzentów w 7 minut 24 sekundy i nie dotknęło dokumentu; napisało tylko raporty.

Wynik review	Liczba
Subagenci-recenzenci	9
Surowe ustalenia	77
Blocker / Major / Nit	1 / 42 / 34
Scalone działania	12

Wyścigu nie znalazło: każde ustalenie o wyścigu cytowało z powrotem przyznanie się samego planisty. Znalazło dwie dziury, o których nikt nie wspomniał:

• Prywatność. Rodzice są właścicielami konta hostingowego i jego logów żądań, a te logi z godziną i prezentem pozwoliłyby ustalić, kto co zarezerwował.
• Bezpieczeństwo. Zapisaną kopię ciasteczka przeglądarki dało się odtworzyć, by anulować cudzą rezerwację.

Wyłapało też szczegóły kodu, które wyszłyby dopiero przy budowie, takie jak asynchroniczne parametry route'ów we frameworku i build, który przez dużą część planu pozostałby zepsuty. Przy wyścigu, który już znało, jego poprawką było osłabienie celu, a takiej rady warto się sprzeciwić.

Resolve to krok, w którym stos ustaleń staje się decyzją. /egm:egm-resolve zamienia każdy raport w jedną tabelę, każdy problem z sugestią: eskaluj, zakwestionuj, odrzuć albo zaproponuj poprawkę. Akceptujesz poprawkę albo kwestionujesz ją swoim uzasadnieniem, a on stosuje tylko to, co zaakceptujesz. Możesz sam odpowiedzieć na eskalowane problemy i pozwolić resztę przyjąć automatycznie.

Nasza lista miała trzydzieści siedem problemów, a resolve już sprawdził recenzentów z kodem: oznaczył jedno ustalenie jako błędne, plik uznany za nieużywany, który strona logowania nadal importuje.

Największą sprawą był wyścig. Blocker proponował przepisać cel na „zmniejsza liczbę podwójnych zakupów, nie zapobiega im". Zakwestionowaliśmy to i zażądaliśmy dokładnie jednego zwycięzcy, z Notion jako jedynym magazynem i bez imion. Agent odmówił udawania: „Notion nie ma jak tego zrobić. Nie ma warunkowego zapisu ani atomowego inkrementowania." Zaproponował kilka wyjść i wybraliśmy claim ledger: listę anonimowych notatek na własnej stronie prezentu w Notion, po jednej na rezerwację, czytanych po kolei, by rozstrzygnąć, kto dostaje prezent. To zamknęło też dziurę z ciasteczkiem, bo przeglądarka trzyma teraz tylko twój własny wpis, więc możesz anulować tylko to, co sam zarezerwowałeś.

Ograniczenie: ta poprawka pojawiła się po review, więc żadna złota rybka jej nie czytała, i opiera się na tym, że Notion zachowuje jedną kolejność równoczesnych zapisów, czego jego dokumentacja nie obiecuje. Projekt każe uruchomić jego test wyścigu na kopii prawdziwej bazy przed wdrożeniem.

Ryzyko przy budowie to agent, który w połowie improwizuje i odchodzi od tego, co ustaliłeś. Otwórz świeżą sesję, nową rozmowę, która zna tylko to, co jest w twoich plikach, i daj jej projekt:

Build the feature exactly to the approved design in docs/egm/gift-reservations.md; add tests.

Nasza pracowała sama 7 minut 56 sekund, zmieniła 24 pliki, a zestaw testów wrócił z Tests 216 passed (216). Zgłosiła, gdzie odeszła od planu (starsza wersja test runnera, bo najnowsza wymagała nowszego pakietu), i zapytała przed aktualizacją. Znalazła też niestabilny test we własnej konfiguracji i uczyniła go przewidywalnym.

Potem sam przetestuj ryzykowną ścieżkę, bo zielony zestaw dowodzi tylko tego, co komuś przyszło do głowy przetestować. Dwoje krewnych na ostatnim prezencie w tej samej sekundzie, trzydzieści razy z różnym timingiem: za każdym razem przeszła dokładnie jedna rezerwacja, a drugi usłyszał, że prezent jest zajęty. Widok rodziców pokazywał prezent jako kompletny, bez żadnego imienia, a anulowanie przywracało go.

Te testy działają na atrapie Notion, która zachowuje się jak oryginał, bez atomowego dodawania i z losowymi opóźnieniami. To ogólna reguła dla zewnętrznych usług w testach: podrabiasz je, ale podróbka ma być tak wroga jak prawdziwa. Przed wdrożeniem uruchom test wyścigu z projektu na kopii prawdziwej bazy; plik testowy dokumentuje nawet przypadek, w którym wygraliby obaj krewni.

W tej samej aplikacji README nadal twierdziło, że nie ma żadnego logowania, choć strona ma hasło: poprawka jednej linii. Sam Claude Code sprawdził kod i poprawił to w kilka sekund, bez żadnego pluginu.

Ścieżka	Koszt (ceny API, Sonnet 5.5)	Czas
Poprawka README, sam Claude Code	$0.0455	10 s
EGM brainstorm, draft, review, resolve (przed kodem)	$7.10	32 min

README Google mówi to samo: „Używaj tego, gdy funkcja wymaga decyzji projektowych przed implementacją. Przy małej, jasnej poprawce błędu użyj zwykłego przepływu pracy." FAQ dodaje, że ukończenie przepływu nie dowodzi wzrostu produktywności, a mały pilotaż na blogu o kodowaniu stwierdził, że review nic nie dodało przy funkcji, z którą zwykły plan już sobie radził.

EGM się opłaca tam, gdzie błąd kryje się poza rozmową, jak tutaj w logach rodziców i w ciasteczku do odtworzenia. Przy problemie, który planista już znał, decyzja, która go rozwiązała, była nasza. Reguła: zanim wpiszesz prompt budowy, zapytaj, czy błąd w tym miejscu dotyka cudzych danych, prywatności, uprawnień lub pieniędzy. Jeśli tak, uruchom review przed budową.