А зачем вообще это объяснять?

Я всё чаще ловлю себя на том, что разговоры про ИИ-инструменты превращаются в странный спор про любимую команду. Один говорит, что ChatGPT лучше рассуждает. Второй говорит, что Claude лучше пишет код. Третий приносит Gemini и рассказывает, что все остальные просто не умеют работать с большим контекстом. Потом приходит человек с Codex и говорит, что чат - это вообще не то, нужен нормальный агент внутри репозитория.

И в каком-то смысле все могут быть правы. Или все могут быть не правы. Потому что сам вопрос слишком общий.

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

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

Спор "кто круче" плохо работает

С моделями есть неприятная особенность: их почти никогда не сравнивают в вакууме. В одном месте сравнивают обычный чат, в другом - coding agent, в третьем - работу с картинками, в четвертом - исправление реальных issues в репозиториях. Потом кто-то берет один результат и начинает делать из него вывод уровня "ну всё, теперь эта модель лучшая вообще".

Я не против бенчмарков. Наоборот, без них обсуждение окончательно превращается в разговор на уровне "мне понравилось" и "а мне не понравилось".

Например, SWE-bench полезен как бенчмарк для software engineering задач. Там важна способность решать реальные проблемы из репозиториев, проходить тесты и не разваливать проект по дороге.

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

То же самое видно по LMArena: там есть разные арены и категории. Где-то сравнивается общий чат, где-то код, где-то vision, где-то webdev, где-то работа с документами. Уже само наличие разных категорий намекает, что фраза "модель X лучше модели Y" без уточнения задачи звучит подозрительно.

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

Как я на это смотрю

Мне кажется, с ИИ-агентами полезно думать примерно так же, как с людьми в разработке. Один человек может написать код, но это не значит, что ему нужно самому же без внешнего взгляда принимать этот код в main. Ревью существует не потому, что ревьюер всегда умнее автора. Иногда автор как раз сильнее. Просто другой человек смотрит на задачу с другой стороны.

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

Поэтому мне нравится разделять роли:

• один агент помогает сформулировать план;
• он же в другой сессии или другой агент делает основную работу;
• отдельный агент смотрит на результат как ревьюер;
• человек принимает финальное решение.

Звучит чуть формально, но по факту это довольно бытовая схема. Один помогает сделать, второй помогает не слишком поверить первому. Всё.

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

Моя текущая схема

Сейчас мой подход довольно простой: Codex - для плана и разработки, Claude - для ревью.

Codex мне удобен именно как агент внутри репозитория. Он достаточно быстро собирает контекст, нормально ходит по файлам и не так часто теряется, когда задача звучит в духе: "посмотри, как это уже сделано в проекте, и сделай рядом в таком же стиле". Для меня это важно, потому что большая часть реальной разработки выглядит именно так, а не как написание идеального кода на пустом месте.

Ему хорошо давать задачу с границами: вот файл, вот стиль, вот что нельзя трогать, вот как проверить результат. Чем лучше задана рамка, тем меньше он начинает творить лишнее. В режиме планирования он тоже обычно нормально раскладывает работу и не оставляет совсем уж странных белых пятен.

Claude в моей схеме занимает другую роль. Мне нравится использовать его как внешнего ревьюера: показать план, diff, статью или архитектурное решение и попросить найти слабые места. Не похвалить. Не переписать всё по-своему. Именно найти проблемы.

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

Например, для кода я обычно хочу услышать что-то такое:

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

Для текста вопросы похожие:

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

Я не хочу утверждать, что Claude объективно лучше ревьюит, а Codex объективно лучше пишет. Это было бы слишком сильное заявление. Просто мне сейчас так удобнее: Codex держать ближе к репозиторию и выполнению, Claude - ближе к критике результата.

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

Самый обычный сценарий в разработке выглядит так.

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

Потом Codex делает реализацию. В нормальном случае он сам читает нужные файлы, правит код, запускает тесты или хотя бы релевантные проверки. После этого я смотрю diff. Уже на этом этапе можно многое поймать руками, потому что иногда проблема не в тестах, а в том, что решение просто не похоже на остальной проект.

Например, формально всё может быть рабочим, но видно, что агент сделал слишком красивую абстракцию там, где в проекте рядом лежат три простые функции. Или наоборот, полез в локальную заплатку, хотя в коде уже есть нормальный helper для такой задачи. Тесты это не всегда поймают. А глаз по diff'у иногда поймает.

После этого можно отдать diff или краткое описание Claude и попросить ревью. Тут важно формулировать задачу именно как ревью. Иначе агент легко воспринимает это как просьбу проверить синтаксис, тесты и линтеры. Лучше прямо просить искать баги, спорные решения, недостающие проверки и слишком уверенные выводы.

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

После ревью начинается самая важная часть: не надо автоматически применять всё, что сказал второй агент. Иногда он прав. Иногда он не понял контекст. Иногда предлагает сделать "красивее", но на самом деле просто тянет проект в другую сторону. Его замечания нужно разбирать так же, как замечания человека на ревью: часть принять, часть отклонить, часть уточнить.

Финальное решение всё равно остаётся за человеком. Если два агента спорят, это не значит, что нужно усреднить их ответы. Нужно понять, где аргумент, а где просто уверенно написанный текст.

Это не универсальный подход

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

Во-вторых, есть вопрос приватности. Чем больше инструментов участвует в процессе, тем больше мест, куда можно случайно отправить лишний контекст. Если в задаче есть персональные данные, коммерческая тайна, внутренние документы или доступы, нужно сначала думать головой, а потом уже радоваться красивому agent workflow.

В-третьих, агенты могут спорить друг с другом. Один говорит "так нормально", второй говорит "тут всё плохо". Но тут уже человеку нужно иметь своё понимание задачи. Если его нет, можно попасть в глупый бесконечный цикл: один агент пишет, второй критикует, первый исправляет, второй критикует исправления, и где-то там умирает весь смысл автоматизации.

Бенчмарки тоже быстро устаревают. Сегодня одна модель лучше на конкретном наборе задач, завтра вышла новая версия, послезавтра изменился продукт, через неделю поменялись лимиты или интерфейс. Я сам ушёл с Claude как основного инструмента на Codex по причине низких лимитов, а потом их сильно повысили. Поэтому я бы не строил процесс на мысли "эта модель навсегда лучшая". С ИИ сейчас вообще странно делать вид, что привычка, которая сработала полгода назад, обязана работать дальше.

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

Итог

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

Для меня сейчас рабочая схема такая, что Codex помогает планировать и делать изменения в проекте, Claude помогает смотреть на результат со стороны. Возможно, через какое-то время схема поменяется. Может быть, появится другой агент, который будет лучше закрывать ревью. Может быть, Codex станет удобнее использовать и для этой роли. Может я перейду на автоматические ревью с BugBot от Cursor. Это нормально.

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

Небольшой апдейт

Написание данной статьи затянулось на несколько месяцев, и, как я и говорил, подход поменялся. Я протестировал, как Codex и Claude Code работают в ревью кода и понял, что платить отдельно за Claude мне не нужно, и я могу полностью перейти на Codex.

В моем случае достаточно будет начать новую сессию, и просто дать ту же задачу по ревью кода. Всё работает как часы, и в некоторых ситуациях Codex отрабатывает лучше, и находит больше багов, хотя не всегда.

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