Comments 5
Когда одна и та же модель пишет код и проверяет его, она пропускает свои ошибки. Она «помнит», почему приняла именно это решение, и не ставит его под сомнение. Знакомо?
Не знакомо. У языковых моделей в принципе нет памяти, лишь набор записок на клочках, как у борющегося с деменцией человека.
В зависимости от того, как устроен ваш RAG, модель подгрузит контекст из текстовых файлов, чтобы у людей, мало знакомых с тем, как в принципе работают LLM, возникало ощущение «длительной сессии». На практике каждый новый запрос для модели начинается с абсолютно белого листа. Не сессия, каждый запрос.
Все современные помощники для того и заставляют скачивать тонну софта, чтобы распихать эти клочки бумаги по вашему локальному диску и создать иллюзию «памяти», как страдающий Альцгеймером — расклеивает стикеры по всей квартире.
Смена модели — это стрельба из пушки по воробьям, потому что часть этих «заметок о прошлом» валяется прямо в папке проекта и будет доступна всем моделям, хоть уменяйся. Вы наблюдаете наведенный эффект от потери той части «хлебных крошек», которые первая модель раскидала по тем местам, которые вторая не видит (и не увидит, потому что частично они лежат в облаке).
Вместо этого, нужно просто эксплицитно начать новую сессию и попросить сделать код ревью, не заглядывая в гайдлайны и файлы для агентов. Тогда и целый проект для слепого подкостыливания создавать не придется.
Спасибо за развернутый комментарий. Соглашусь, что сама модель - ближе к чистой функции, и выход полностью определяется входом в неи и seed генератора случайных чисел. Тем не менее, память - реализована в самом агенте, и в контесте задачи. Плюс, у разных моделей свои "паттерны" мышления.
Первую часть - набранный контекст, и ошибки мышления в нем - можно обойти отдельной сессией в агенте. Так тоже можно, так работает.
Но я в статье, и в своем опыте, пошел дальше - взял для ревью другого агента. Имеющего другие паттерны мышления.
Для меня - этот способ эффективен, и хорошо ловит косяки плана и реализации.
Это не значит, что работа только с одним агентом - плоха. Есть интересные статьи от Антропик, где они рассказывают про свои эксперименты с продвинутым harness и ревью Опус Опусом в независимых сессиях/агентах.
пошел дальше — взял для ревью другого агента
Это шаг вперед и два^W шаг назад: как минимум, все еще необходимо проинструктировать этого второго агента не читать до обеда советских газет^W^W^W^W агентские файлы, вот я это уже упоминал:
потому что часть этих «заметок о прошлом» валяется прямо в папке проекта и будет доступна всем моделям
В статье вы подробно описали три режима работы скилла (ревью плана прямо из Plan Mode, ревью кода по git diff и проверка соответствия кода плану), но не совсем ясно, как именно происходит автоматическое определение режима по контексту проекта. Например, по каким признакам (наличие файла плана, наличие staged changes, содержимое чата?) скилл сам решает, что сейчас нужно делать, и как избежать ложных срабатываний? Было бы интересно увидеть фрагмент логики из SKILL.md или примеры, когда автоопределение сбоило.
Ещё один момент, который остался не до конца понятным: вы пишете, что повторные раунды идут через resume для экономии токенов, а Codex запускается строго в read-only с high effort, но не уточнили, как именно удалось обойти типичные проблемы Claude с подтверждениями bash-команд и с «игнором» параметров effort при resume. Что конкретно пришлось доработать в промптах или в вызове CLI, чтобы цикл из 2–5 раундов работал стабильно без ручного вмешательства?
Режим работы определяется на шаге "Step 1: Determine review mode" скилла. Модель сама решает, исходя из набора признаков. Например, цитирую, " if context contains the system message "Plan mode is active" → mode = plan "
Подробнее условия, наверное лучше в сам скилл посмотреть: https://github.com/dementev-dev/adversarial-review/blob/master/SKILL.md
Если ссылка из комментария пропадет - она есть в тексте статьи, выше. Сам скилл публично доступен, можно пользоваться, дорабатывать, делиться с другими :)
Подтверждения в план режиме - полностью избежать не удалось. Удалось уменьшить количество, путем структурирования обращения к Кодекс, и внесением части команд в Allow список, как прописано в README.
Лайфхак - если при запросе на записи в файл нажать shift-tab, агент перейдет в рабочий режим из плана, но ничего не сломается. Планирование и подтверждение будут работать так же, только запросов меньше зададут.
Как я сделал скилл для AI-ревью плана и кода — и зачем мне две модели