Когда одна и та же модель пишет код и проверяет его, она пропускает свои ошибки. Она «помнит», почему приняла именно это решение, и не ставит его под сомнение. Знакомо? Как вычитывать собственный текст: глаз замыливается, мозг подставляет правильный смысл туда, где его нет.

В нормальной команде эта проблема решена давно: автор кода ≠ ревьюер. Два человека с разным контекстом и разными слепыми пятнами. С LLM можно сделать то же самое, взяв две модели от разных вендоров. Другая архитектура, другой pretrain - другие слепые пятна. Одна пишет, другая проверяет.

В англоязычной среде этот подход называют adversarial review, «состязательное ревью». Суть: ревьюер не подтверждает, что все хорошо, а пытается сломать уверенность в решении. Я называю это проще: перекрестное ревью.

У меня Claude (Opus) планирует и пишет код, а Codex (GPT-5.4) ревьюит. Автоматически, в цикле, пока не одобрит. Все это - один файл-скилл для Claude Code. О нем и расскажу.


Зачем ревьюить план, а не только код

Многие инструменты AI-ревью работают с кодом. Логично: код конкретен, diff понятен, замечания привязаны к строкам. Но код - самый дешевый уровень ошибок.

Дороже обходятся ошибки в плане. Неправильно декомпозировал задачу, не учел зависимость, пропустил шаг. Код будет технически корректным, но решать не ту проблему или решать ее не в том порядке. А ведь план почти никто не ревьюит. Хотя именно его качество определяет качество всей реализации.

Есть и уровень выше - продуктовая документация (PRD, общий план работ), которая помогает агенту лучше планировать конкретные задачи. Но это уже за пределами данной статьи.

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

Как я к этому пришел

Мой рабочий цикл с AI: план → ревью → код → ревью. Пишу и план, и код с Claude Opus. На ревью отправляю в Codex, последние модели GPT. Работает хорошо: модели мощные, а из-за разницы в «мышлении» баги выявляются отлично.

Боль была одна: копипаста. 2-4 круга ревью плана, потом столько же с кодом. Скопировал из одного чата, вставил в другой, дождался ответа, скопировал замечания обратно, поправил, снова скопировал. Раздражало, но жить можно.

Автоматизировать? Думал. Но не хотелось городить сложных решений. Хотелось видеть, что пишет ревьюер, контролировать процесс. И задачи достаточно разнообразные, не засунешь их в прокрустово ложе жесткого скрипта. Автоматизация должна экономить время, а не поглощать его.

Все изменилось, когда появились скиллы для Claude Code, и я узнал, что из скилла можно запускать внешние программы. Скилл - текстовая инструкция для агента, а не код. Та гибкость, которой не хватало.

Нашел на GitHub скилл BenedictKing/codex-review. Попробовал. Споткнулся: огромное количество запросов на подтверждение действий. И не было удобного ревью плана, только код.

Взялся «немного поправить под себя». Переписал все. Несколько раз.

Уже позже, когда рабочий вариант был отлажен, увидел официальный плагин от OpenAI (codex-plugin-cc). Посмотрел, вдохновился рядом решений. Но свой скилл не заменил, и вот почему.


Зачем свой скилл, если есть плагин OpenAI

У плагина OpenAI есть чему поучиться: продуманные промпты для ревью, настройка ревьюера на скептицизм, готовые чеклисты проверок. Часть этих идей я взял себе (и указал это в README). Но два отличия для меня оказались принципиальными.

Первое: плагин OpenAI ревьюит только код. Мой скилл работает в трех режимах: ревью плана, ревью кода и ревью кода против плана. Причем ревью плана работает прямо из Plan Mode в Claude Code, когда код еще не написан, а план только сформирован.

Второе: плагин OpenAI - это ~15 JS-модулей, App Server, JSON-RPC брокер, lifecycle hooks. Мой скилл - один SKILL.md. Текстовая инструкция, которую агент интерпретирует. Понятно устроен, легко доработать и адаптировать под другого ревьюера. Не нужен сервер, не нужен брокер, нет зависимостей кроме CLI ревьюера.

Скилл - инструкция для агента, не программа. Агент сам решает, как выполнить каждый шаг, учитывая контекст задачи.


Как это устроено

Claude пишет план или код. Скилл собирает материал (diff или файл плана), формирует промпт и запускает Codex CLI в read-only режиме. Codex ревьюит и выносит вердикт: APPROVED или REVISE. Если REVISE, Claude читает замечания, правит и отправляет на повторное ревью. До 5 раундов, на практике хватает 2-3.

Скилл работает в трех режимах: ревью плана (до написания кода, в том числе прямо из Plan Mode), ревью кода (git diff) и ревью кода против плана (проверить соответствие). Режим определяется автоматически по контексту или задается явно.

Несколько решений, к которым пришел не сразу. Codex работает в read-only sandbox: ревьюер не должен править, он должен находить. Замечания показываются как есть, без пересказа. Claude не «фильтрует» и не смягчает, иначе теряется смысл второго мнения. Повторные раунды идут через resume - продолжение сессии, экономия токенов.

Adversarial промпты

Нейтральный промпт вроде «проверь код на баги и стиль» дает мягкое ревью: «выглядит хорошо, может добавить тесты». Adversarial промпт задает другую установку - ревьюер по умолчанию скептичен и пытается найти, что сломается.

Промпты структурированы через XML-секции: <attack_surface> - конкретный чеклист (авторизация, целостность данных, race conditions, rollback safety); <finding_bar> - каждое замечание обязано ответить на 4 вопроса: что сломается, почему уязвим, импакт, рекомендация; <scope_exclusions> - не комментировать стиль и спекулятивные улучшения. Одно сильное замечание лучше пяти слабых. Если код solid, ревьюер должен сказать это прямо, ложные срабатывания подрывают доверие.

Пример запуска:

timeout 600 codex exec \
  -m gpt-5.4 \
  -c model_reasoning_effort=high \
  -s read-only \
  -o /tmp/codex-review-1711872000-4821.md \
  "ПРОМПТ"

Полный текст промптов и детали каждого шага - в SKILL.md.


Грабли

Permission prompts

Claude Code спрашивает подтверждение на каждую bash-команду. При 3-4 раундах ревью это десятки подтверждений. Часть решается через permissions.allow в настройках (шаблон есть в README). Часть - переписыванием шагов на встроенные инструменты: Write tool вместо bash для записи файлов. Полностью избавиться не удалось, но стало терпимо.

Resume и настройки модели

codex exec resume продолжает сессию и экономит токены, но есть подвох. При resume Codex игнорирует переданные параметры модели и reasoning effort, берет текущие настройки пользователя. Если у вас по умолчанию medium reasoning, ревью будет поверхностнее, чем ожидаете. У меня было наоборот: скидывало на xhigh вместо указанного high, лишние токены.

Diff vs список файлов

Первые версии передавали полный diff в промпт, раздувало контекст, особенно на больших изменениях. Сейчас в промпт идет только --name-only список и команды для получения diff. Codex читает diff сам. Контекст чистый, токены не тратятся на дублирование.

Таймауты

Codex иногда зависает. Без timeout ждешь бесконечно. С timeout 600 через 10 минут получаешь exit code 124 и можно повторить. Просто, но без этого было больно.


Как попробовать

Что нужно: Claude Code CLI, OpenAI Codex CLI (npm install -g @openai/codex) с активной подпиской OpenAI.

Установка:

git clone https://github.com/dementev-dev/adversarial-review.git
mkdir -p ~/.agents/skills
ln -s "$(pwd)/adversarial-review" ~/.agents/skills/adversarial-review

Первый запуск - откройте проект в Claude Code:

/adversarial-review          # автоопределение режима
/adversarial-review plan     # ревью плана
/adversarial-review code     # ревью кода

Рекомендуемые разрешения для минимизации подтверждений - в README проекта.


Дмитрий Дементьев, эксперт по хранилищам данных и аналитическим платформам, «Концепт Разработка». Контакты: GitHub · Канал в Telegram · me@dementev.space

Комментарии (5)


  1. amcured
    08.04.2026 06:51

    Когда одна и та же модель пишет код и проверяет его, она пропускает свои ошибки. Она «помнит», почему приняла именно это решение, и не ставит его под сомнение. Знакомо?

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

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

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

    Смена модели — это стрельба из пушки по воробьям, потому что часть этих «заметок о прошлом» валяется прямо в папке проекта и будет доступна всем моделям, хоть уменяйся. Вы наблюдаете наведенный эффект от потери той части «хлебных крошек», которые первая модель раскидала по тем местам, которые вторая не видит (и не увидит, потому что частично они лежат в облаке).

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


    1. ddmitry Автор
      08.04.2026 06:51

      Спасибо за развернутый комментарий. Соглашусь, что сама модель - ближе к чистой функции, и выход полностью определяется входом в неи и seed генератора случайных чисел. Тем не менее, память - реализована в самом агенте, и в контесте задачи. Плюс, у разных моделей свои "паттерны" мышления.
      Первую часть - набранный контекст, и ошибки мышления в нем - можно обойти отдельной сессией в агенте. Так тоже можно, так работает.
      Но я в статье, и в своем опыте, пошел дальше - взял для ревью другого агента. Имеющего другие паттерны мышления.
      Для меня - этот способ эффективен, и хорошо ловит косяки плана и реализации.
      Это не значит, что работа только с одним агентом - плоха. Есть интересные статьи от Антропик, где они рассказывают про свои эксперименты с продвинутым harness и ревью Опус Опусом в независимых сессиях/агентах.


      1. amcured
        08.04.2026 06:51

        пошел дальше — взял для ревью другого агента

        Это шаг вперед и два^W шаг назад: как минимум, все еще необходимо проинструктировать этого второго агента не читать до обеда советских газет^W^W^W^W агентские файлы, вот я это уже упоминал:

        потому что часть этих «заметок о прошлом» валяется прямо в папке проекта и будет доступна всем моделям


  1. NTDim1973
    08.04.2026 06:51

    В статье вы подробно описали три режима работы скилла (ревью плана прямо из Plan Mode, ревью кода по git diff и проверка соответствия кода плану), но не совсем ясно, как именно происходит автоматическое определение режима по контексту проекта. Например, по каким признакам (наличие файла плана, наличие staged changes, содержимое чата?) скилл сам решает, что сейчас нужно делать, и как избежать ложных срабатываний? Было бы интересно увидеть фрагмент логики из SKILL.md или примеры, когда автоопределение сбоило.

    Ещё один момент, который остался не до конца понятным: вы пишете, что повторные раунды идут через resume для экономии токенов, а Codex запускается строго в read-only с high effort, но не уточнили, как именно удалось обойти типичные проблемы Claude с подтверждениями bash-команд и с «игнором» параметров effort при resume. Что конкретно пришлось доработать в промптах или в вызове CLI, чтобы цикл из 2–5 раундов работал стабильно без ручного вмешательства?


    1. ddmitry Автор
      08.04.2026 06:51

      Режим работы определяется на шаге "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, агент перейдет в рабочий режим из плана, но ничего не сломается. Планирование и подтверждение будут работать так же, только запросов меньше зададут.