Google разделила подготовку ИИ-спецификаций на две роли в плагине EGM

Вы полчаса обсуждаете с ИИ новую функцию. Он задаёт вопросы, соглашается с решениями, пишет подробную спецификацию. Просите проверить — всё выглядит убедительно. А после запуска выясняется, что повторное событие от платёжного сервиса дважды продлевает подписку. В разговоре все подразумевали защиту от дублей, в документ она не попала.

На такую проблему нацелен Elephant-Goldfish Model, или EGM: открытый плагин для подготовки и проверки технических документов с помощью ИИ. Один агент собирает решения, другие проверяют результат без истории обсуждения. Практический смысл — обнаружить недоговорённости до реализации, пока исправление ещё помещается в несколько строк спецификации.

Зачем проверяющему забывать разговор

В EGM две роли. «Слон» сохраняет контекст проекта и готовит документ. «Золотые рыбки» получают документ и связанные исходники, но не предыдущий разговор. Разработчик выбирает, какие замечания принять, разрешает противоречия и утверждает проект перед написанием кода. Так процесс описан в репозитории Google.

Отсутствие истории здесь — условие проверки. Если решение понятно только участникам длинного чата, будущему исполнителю может не хватить информации. Свежий проверяющий должен оценить то, что действительно записано, без возможности мысленно дополнить документ прежними договорённостями.

При этом выражение «нулевой контекст» легко понять слишком буквально. Проверяющий получает материалы для работы. Изолируют предысторию обсуждения, а не всю информацию о системе. Поэтому качество спецификации и выбор исходников по-прежнему имеют значение.

Как это выглядит на примере платежей

Представим, что команда добавляет обработку уведомлений об оплате. В первом варианте документа написано: получить событие, найти пользователя, продлить подписку. Для демонстрации функции достаточно. Для рабочего сервиса остаются вопросы.

Что делать, если одно событие пришло дважды? Если база сохранила продление, а сервер не успел подтвердить приём? Если уведомление об отмене платежа поступило раньше уведомления об успешной оплате? Это пример возможных вопросов ревью, а не отчёт о результатах EGM.

Автор документа мог обсуждать повторы в чате и считать вопрос закрытым. Проверяющий без этой истории видит пробел: правила обработки повторных событий в спецификации отсутствуют. Инженеру придётся определить, как распознавать дубли, где хранить результат обработки и какое поведение считать правильным после сбоя.

Для продакта здесь тоже есть работа. Возврат денег, отмена подписки и повторная доставка уведомления затрагивают обещания пользователю. Их нельзя полностью отдать на усмотрение агента, который пишет код. Сначала команда договаривается о поведении продукта, затем фиксирует его так, чтобы другой человек или агент смог его проверить.

Что попробовать и где пределы

На сайте EGM описаны этапы обсуждения идеи, подготовки документа и ревью. Там же представлены инструменты для создания документации существующего проекта и поиска расхождений между спецификацией и кодом. Начать разумно с одной функции, где есть спорные решения: платежей, прав доступа или фоновых задач.

До проверки полезно записать ограничения и критерии приёмки. После неё — разобрать замечания, исправить документ и только затем переходить к реализации. Для оценки пользы можно считать подтверждённые пробелы, найденные до написания кода, и время, потраченное на проверку. Это предлагаемый способ оценки, а не опубликованные показатели эффективности плагина.

EGM не даёт оснований обещать устранение архитектурных ошибок. Отдельные агенты могут повторять одинаковые заблуждения, а убедительное замечание может оказаться неверным. Дополнительные раунды также требуют времени и расходуют токены. Цена проверки должна соответствовать цене возможной ошибки.

Проект распространяется под Apache 2.0; авторы отдельно указывают, что это не официально поддерживаемый продукт Google. Для ревью требуются свежие контексты субагентов, а сам процесс не заменяет тесты и инженерное решение — эти ограничения прямо перечислены в README.

Полезная привычка, которую предлагает EGM: перед реализацией дать спецификацию тому, кто не участвовал в её обсуждении. Если без устных пояснений её невозможно исполнить, документ ещё требует работы.