AIDiveПлан, который никто не проверил
Elephant-Goldfish Model (EGM) от Google это бесплатный плагин для Claude Code: ревьюеры без памяти читают ваш план до того, как написана хоть одна строка кода. Мы установили его и довели настоящую фичу нашего собственного приложения от плана до рабочего кода: система резервирования для семейного списка подарков на Next.js с базой Notion, на копии репозитория.
Состояние гонки планировщик нашёл сам. А вот две дыры, которые действительно имели значение, он не увидел: родители могли прочитать, кто что зарезервировал, в логах собственного хостинга, а сохранённый в браузере cookie можно было воспроизвести и отменить чужой резерв. Нашли их только ревьюеры без памяти. Фича, собранная по проверенному плану, в тридцати гонках за последний подарок каждый раз давала ровно одного победителя, правда на заглушке вместо Notion. А на мелкой правке ревью стоит куда больше самой правки, так что его пропускают.
Процесс ниже состоит из пяти шагов: установка, брейнсторм и черновик, ревью, resolve, сборка. В последнем разделе дано правило, когда всё это пропустить.
Что такое EGM и установка двумя командами
Когда вы просите Claude Code спланировать фичу, агент, написавший план, и агент, которого вы просите его проверить, это один и тот же агент, и он не видит собственных слепых пятен. EGM, Elephant-Goldfish Model, это бесплатный плагин Google для решения этой проблемы. В репозитории прямо сказано, что это не официально поддерживаемый продукт Google.
Слон это агент, с которым вы разговариваете: он держит в голове весь разговор и пишет план вместе с вами. Золотые рыбки это агенты-ревьюеры без памяти. Они читают только план и ваш код, как коллега, который смотрит pull request, не сидев на встрече по дизайну. Код они читать могут, а менять нет, заметок вашего проекта они не видят, а окончательное решение по каждому поднятому вопросу остаётся за вами. Идея принадлежит Дейву Ренсину, который написал, что если мы не будем осторожны, то не просто станем быстрее писать код, а начнём массово производить свои ошибки.
Установка выполняется из папки проекта двумя командами:
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm --scope project
Первая добавляет репозиторий Google как маркетплейс плагинов, то есть список, из которого Claude Code умеет ставить плагины. Вторая устанавливает плагин только для этого проекта. Обе вернули зелёную галочку примерно за пять секунд; откройте новую сессию, чтобы плагин загрузился. В документации требуется Claude Code 2.1.271 или новее, потому что ревьюеры опираются на настройку omitClaudeMd, которая прячет от них заметки вашего проекта.
Затем добавьте в CLAUDE.md одну строку, чтобы отчёты ложились в одну папку, а не в корень репозитория:
EGM artifact directory: docs/egm
Команды ничего не стоят, пока вы не набрали одну из них: ни одна не загружается в сессию сама. Ограничение в том, что золотые рыбки только читают документы. Они не запускают ваше приложение и работают на той же модели, что и вы, поэтому могут разделять её слепые пятна.
Брейнсторм и черновик на настоящей фиче
Брейнсторм нужен в момент, когда вы собираетесь строить то, где неверное решение дорого обойдётся позже. Наше приложение это семейный список подарков: родственники отмечают, что они купили, а список хранится в базе Notion. Всё шло на копии репозитория, без доступа к настоящему списку.
Фича: дать родственнику зарезервировать подарок, чтобы двое не купили одно и то же, не давать родителям видеть, кто что зарезервировал, и разрешить отмену. Вы вводите команду брейнсторма и после неё фичу одним предложением:
/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.
Прежде чем что-либо спросить, она прочитала код и заметила, что приложение не знает, кто есть кто, потому что все входят по одному общему паролю. Дальше она задаёт вопросы в несколько раундов, а небольшой рой золотых рыбок смотрит на идею до того, как написан любой раздел. Вы отвечаете как владелец продукта. У нас так: один общий пароль, родственник вводит только имя, и ничто, называющее его, не попадает туда, куда смотрят родители. Рой поднял то, что мы не назвали: старый маршрут редактирования, который всё ещё позволил бы любому вручную менять количество.
Состояние гонки планировщик тоже назвал сам: родственники, нажимающие «зарезервировать» в один и тот же момент. Состояние гонки это когда два запроса читают одно и то же старое значение и оба пишут, из-за чего одно обновление молча теряется, а в документации Notion нет способа атомарно прибавить число.
Дальше /egm:egm-draft docs/egm/concepts_brief.md пишет проектный документ по одному разделу за раз: письменный план каждого файла до любого кода. Она останавливалась с вопросом пятнадцать раз. Вы утверждаете раздел или выбираете между вариантами архитектуры, у каждого из которых указано, как он ломается. Один выбор был о том, где живёт резерв родственника; мы выбрали подписанный cookie в его собственном браузере, чтобы ничто с его именем не попадало на сервер. Черновик даже признал в собственных известных ограничениях, что его решение для гонки не работает, потому что оба родственника прочитают одно и то же значение. Этот шаг заканчивается утверждённым проектным документом в вашем репозитории.
Слепое ревью: девять ревьюеров, две дыры, которых планировщик не видел
Ревью нужно тогда, когда вы и ваш агент оба считаете план надёжным, а это как раз момент, когда вы не видите, чего не хватает. Вы вводите /egm:egm-review docs/egm/gift-reservations.md; она спрашивает, должны ли ревьюеры читать что-то ещё, а затем просит выбрать режим. Сводный режим проходит все стадии без остановок и возвращает один объединённый список действий.
Пять стадий: Initial Zoom Out Review (решает ли дизайн правильную задачу), Comprehension Review (поймёт ли новичок), Design Critique (структура и формулировки), Intermediate Zoom Out Review и Implementation Readiness, которая читает ваш настоящий код и сверяет с ним каждый шаг плана. На каждой стадии запускаются свежие золотые рыбки, никогда не видевшие разговора.
На нашем дизайне она запустила девять ревьюеров за 7 минут 24 секунды и не тронула документ, а только написала отчёты.
| Результат ревью | Кол-во |
|---|---|
| Субагенты-ревьюеры | 9 |
| Сырые находки | 77 |
| Blocker / Major / Nit | 1 / 42 / 34 |
| Объединённые пункты действий | 12 |
Гонку она не нашла: каждая находка про гонку цитировала собственное признание планировщика. Зато она нашла две дыры, которых никто не поднимал:
- Приватность. Родители владеют аккаунтом хостинга и его логами запросов, а время и подарок в них позволили бы вычислить, кто что зарезервировал.
- Безопасность. Сохранённую копию cookie браузера можно воспроизвести и отменить чужой резерв.
Она также поймала детали кода, которые всплыли бы только при сборке, например что параметры маршрутов во фреймворке асинхронные и что сборка осталась бы сломанной на большей части плана. По гонке, о которой планировщик уже знал, её решением было ослабить цель, и это совет, которому стоит возразить.
Resolve: решаете вы, даже против ревьюеров
Шаг resolve это место, где груда находок превращается в решение. /egm:egm-resolve сводит каждый отчёт в одну таблицу, где у каждой проблемы есть рекомендация: эскалировать, оспорить, отклонить или предложить исправление. Вы принимаете исправление или оспариваете его со своей причиной, и применяется только принятое. Вы можете сами ответить на эскалированные вопросы, а остальное дать принять автоматически.
В нашем списке было тридцать семь проблем, и resolve уже сверил ревьюеров с кодом: одну находку он пометил как ошибочную, файл, названный неиспользуемым, который страница входа всё ещё импортирует.
Главной была гонка. Blocker предложил переписать цель как «reduces duplicate purchases, does not prevent them» (сокращает число повторных покупок, но не предотвращает их). Мы оспорили это и потребовали ровно одного победителя, с Notion как единственным хранилищем и без имён. Агент отказался имитировать: «Notion has no way to do that. It has no conditional write and no atomic increment.» (В Notion нет способа это сделать. Там нет условной записи и атомарного инкремента.) Он предложил несколько выходов, и мы выбрали журнал заявок (claim ledger): список анонимных заметок на странице самого подарка в Notion, по одной на резерв, которые читаются по порядку, чтобы решить, кому достался подарок. Это закрыло и дыру с cookie, ведь теперь браузер хранит только вашу собственную заявку, так что отменить можно лишь то, что вы зарезервировали.
Ограничение: это исправление появилось после ревью, поэтому его не читала ни одна золотая рыбка, и оно опирается на то, что Notion сохраняет один порядок для одновременных записей, чего его документация не обещает. В дизайне сказано запустить его проверку гонки на копии настоящей базы перед выкаткой.
Сборка по плану в новой сессии и проверка гонки
Риск на этапе сборки в том, что агент начинает импровизировать на полпути и уходит от того, что вы решили. Откройте новую сессию, то есть новый разговор, который знает только то, что лежит в ваших файлах, и дайте ей дизайн:
Build the feature exactly to the approved design in docs/egm/gift-reservations.md; add tests.
Наш агент работал сам 7 минут 56 секунд, изменил 24 файла, и набор тестов вернул Tests 216 passed (216). Он отметил, где отступил от плана (взял более старую версию запускалки тестов, потому что самой новой нужен был более новый пакет), и спросил, прежде чем обновлять. Ещё он нашёл нестабильный тест в собственной настройке и сделал его предсказуемым.
Затем рискованный путь проверяйте сами, потому что зелёный набор тестов доказывает лишь то, что кому-то пришло в голову проверить. Двое родственников берут последний подарок в одну и ту же секунду, и так тридцать раз с разными задержками: каждый раз ровно один резерв проходил, а второму говорили, что подарок уже занят. В виде для родителей подарок значился выполненным без единого имени, а отмена возвращала его обратно.
Эти тесты идут против заглушки вместо Notion, которая ведёт себя как он: без атомарного сложения и со случайными задержками. Это общее правило для внешних сервисов в тестах: подделывайте их, но делайте подделку такой же враждебной, как настоящий сервис. Перед выкаткой запустите собственную проверку гонки из дизайна на копии настоящей базы; в тестовом файле даже описан случай, когда победили бы оба родственника.
Когда пропустить: правило
В том же приложении в README всё ещё говорилось, что входа нет вообще, хотя на сайте есть пароль: правка в одну строку. Обычный Claude Code проверил код и исправил это за секунды, без всякого плагина.
| Путь | Стоимость (цены API, Sonnet 5.5) | Время |
|---|---|---|
| Правка README, обычный Claude Code | $0.0455 | 10 с |
| EGM: брейнсторм, черновик, ревью, resolve (до любого кода) | $7.10 | 32 мин |
README Google говорит то же самое: «Use it when a feature needs design decisions before implementation. For a small, clear bug fix, use your normal coding workflow.» (Используйте его, когда фиче нужны проектные решения до реализации. Для небольшого, понятного исправления бага используйте обычный рабочий процесс.) Его FAQ добавляет, что завершение процесса не доказывает прироста продуктивности, а небольшой пилот в блоге о программировании показал, что ревью ничего не добавило на фиче, с которой простой план и так справился.
EGM окупается там, где ошибка прячется за пределами разговора, как здесь: в логах родителей и в cookie, который можно воспроизвести. На проблеме, о которой планировщик уже знал, решение, которое её закрыло, приняли мы. Правило такое: прежде чем вводить промпт на сборку, спросите себя, касается ли ошибка здесь чужих данных, приватности, прав или денег. Если касается, запустите ревью до сборки.
