Споры всегда остаются в истории чата

Мой агент отлично помнит, почему вчера я забраковал второй вариант API. Он записал мои слова про сложность поддержки, и сегодня, когда я вернулся к той же ветке, он вежливо напомнил: «Судя по предыдущему обсуждению, вы отвергли подход с двойными эндпоинтами». Это удобно. Моя мысль продолжается там, где я остановился, и не нужно снова объяснять контекст. Но я же не просил его забыть альтернативу, которую мы уже обсудили. Она просто лежит в истории, как зачёркнутый пункт в блокноте.

Открытый плагин Elephant Goldfish Model предлагает сделать следующий шаг: разделить процесс на две роли с разной «памятью». Сначала «Слон» — агент, который помнит проект, требования и прошлые решения, — исследует задачу и пишет черновик спецификации. Затем задачу берут «Золотые рыбки» — рецензенты, которые проверяют этот черновик и исходные материалы, но не видят предыдущего разговора. Их задача — выявить неявные предположения, неясные требования и риски реализации, которые автор мог не заметить.

Контекст как благо и как помеха

Контекст — это не всегда помощь. Представьте, что вы объясняли ассистенту, почему выбрали библиотеку X. Он это запомнил и, видя её в черновике, считает решение обоснованным. А рецензент, который не участвовал в том обсуждении, спрашивает: «А почему именно X, а не Y, которая лучше документирована для нашей задачи?» Вопрос не в том, что ваши доводы были плохи. Они просто перестали быть очевидными, когда их вынули из потока разговора. Именно это разделение EGM и называет «памятью» — доступ к предыдущему диалогу.

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

Чем это ревью похоже на человеческое

Это напоминает хорошую практику в команде: вы пишете тикет, описываете проблему и предлагаете решение. Коллега, который не сидел с вами у монитора, читает описание с нуля. Если в нём есть пробелы или допущения, он задаёт вопросы. Иногда они кажутся наивными: «А зачем нам этот параметр?» Но именно эта «наивность» и вытаскивает на свет скрытые проблемы. EGM формализует этот принцип для ИИ-ассистентов: проектировщик работает в контексте, рецензент — вне его.

Такое разделение меняет взгляд на само код-ревью. Это не просто поиск багов в уже написанном коде. Это структурный сдвиг: ещё до первой строчки кода мы пытаемся выявить изъяны в плане. И делаем это взглядом со стороны, который не знает, как мы к этому плану пришли.

В работе студии мы постоянно сталкиваемся с обратным. Клиент присылает задачу, мы обсуждаем её в чате, приходим к решению. Потом, через неделю, новый сотрудник читает итоговый брифинг и спрашивает: «А откуда здесь это ограничение?» Оказывается, оно было озвучено устно и не попало в документацию. «Золотая рыбка» — будь то человек или агент — нашла бы это сразу.