Зачем мне несколько AI-разработчиков вместо одного

Долгое время идея использовать несколько AI-инструментов одновременно казалась мне избыточной.

Если один coding agent умеет читать проект, исследовать задачу, писать код, запускать тесты и делать review — зачем нужен второй? А потом третий?

Со стороны это легко выглядит как коллекционирование инструментов. Сегодня Claude Code. Завтра Codex. Потом Cursor. Ещё через месяц что-нибудь новое.

Но постепенно у меня появилась совсем другая причина использовать несколько AI-разработчиков. Не потому, что один из них обязательно слабее другого. А потому, что один и тот же агент слишком легко становится автором, reviewer и судьёй собственной работы одновременно.

Сначала всё было очень удобно

Один агент получает задачу. Он исследует проект. Предлагает решение. Пишет реализацию. Запускает тесты. Проверяет diff. Сообщает: всё готово.

Очень комфортная схема.

задача
    ↓
AI исследует
    ↓
AI планирует
    ↓
AI реализует
    ↓
AI проверяет
    ↓
готово

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

Но потом я начал замечать одну повторяющуюся проблему.

Автор очень хорошо понимает собственное решение

Иногда даже слишком хорошо.

Допустим, AI исследовал задачу и пришёл к определённому выводу: лучше добавить новый service. После этого он написал этот service. Затем я прошу: проверь свою реализацию.

Что происходит? Он снова смотрит на код. Но смотрит на него уже через собственное первоначальное решение. Он знает, почему создал этот класс. Почему выбрал такую abstraction. Почему изменил именно эти файлы.

И поэтому естественно проверяет примерно следующее: хорошо ли я реализовал выбранный мной подход?

А мне иногда нужен другой вопрос: а выбранный подход вообще был правильным? Это не одно и то же.

Я впервые заметил это на вполне нормальном review

AI реализовал небольшую feature. Код выглядел хорошо. Тесты проходили. Я попросил провести review собственной работы. Он нашёл несколько мелочей. Где-то можно упростить условие. Где-то улучшить название. Добавить один edge case в тестах. Исправил.

Повторная проверка: существенных проблем не найдено. На первый взгляд идеально.

Но потом я показал тот же diff другому агенту. Без всей истории предыдущего обсуждения. Только задача, ограничения и изменения. И почти сразу получил вопрос:

Почему здесь вообще создаётся новый сервис, если похожее поведение уже есть в другом модуле?

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

AI тоже может попасть в собственную колею

Мы обычно говорим о confirmation bias применительно к людям. С AI это, конечно, работает не буквально так же. У модели нет человеческой привязанности к собственному коду. Она не обидится, если удалить половину реализации.

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

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

Тогда я начал разделять роли

Не сразу и не как строгую систему. Скорее постепенно. Сначала просто иногда показывал результат другой модели. Потом стал делать это чаще. А затем из этого начала складываться более понятная схема.

Сегодня она примерно такая:

Cursor
    ↓
task / environment / verification
Claude Code
    ↓
implementation
Codex
    ↓
review / alternative implementation

Но сами названия здесь не главное. Через год инструменты могут поменяться. Роли, скорее всего, останутся.

Первый агент помогает поставить задачу в правильную среду

Для меня Cursor всё чаще становится местом, где задача встречается с проектом. Там удобно сформулировать задачу, быстро посмотреть связанные файлы, подготовить окружение, проверить состояние проекта, запустить локальную проверку, посмотреть итоговый diff.

То есть это не обязательно «главный программист». Скорее рабочая поверхность вокруг задачи. Место, где можно понять: мы вообще готовы отдавать эту работу агенту?

Есть ли нужный контекст. Работает ли окружение. Понятны ли ограничения. Есть ли тесты. Не находится ли repository уже в странном состоянии.

Это довольно скучная роль. Но чем больше автономности получает AI, тем важнее становится именно окружение.

Второй агент пишет реализацию

Здесь сейчас у меня часто оказывается Claude Code. Ему можно дать уже подготовленную задачу. Не «посмотри что-нибудь здесь и сделай как лучше». А гораздо более конкретную рамку.

Вот проблема. Вот область системы. Вот ограничения. Вот найденный контекст. Сначала исследуй. Покажи план. После согласования реализуй.

И дальше он может довольно долго самостоятельно работать внутри задачи. Именно здесь особенно удобно разделение ролей. Потому что мне не нужно одновременно думать: а кто потом независимо посмотрит на это решение? Я уже знаю, что implementation — не последняя точка процесса.

А потом приходит агент, который ничего не должен защищать

Например, Codex. Я стараюсь давать ему немного другую задачу. Не «проверь, всё ли правильно сделал Claude». Мне не нравится такая формулировка. Она уже предполагает, что решение в основном правильное и нужно найти ошибки.

Гораздо интереснее:

Вот исходная задача. Вот ограничения. Вот diff. Проведи независимый review. Отдельно проверь, правильно ли выбран сам подход. Если видишь более простой или безопасный вариант — предложи его.

И здесь начинает появляться ценность второго агента. Он не участвовал в первоначальном обсуждении. Не строил этот план. Не писал этот код. У него нет необходимости продолжать старую цепочку рассуждений. Он может начать почти с нуля.

Иногда я специально не передаю ему всю историю

Это оказалось неожиданно полезно. Есть соблазн передать reviewer весь предыдущий диалог. Чтобы он понимал, почему было принято каждое решение. Но иногда именно это и не нужно.

Если рассказать: мы долго обсуждали A, потом отказались от B, потому что C, поэтому выбрали D — второй агент довольно быстро оказывается внутри той же рамки. А мне полезен свежий взгляд.

Поэтому иногда я даю только:

исходная задача
+
важные ограничения
+
текущий код
+
diff

И спрашиваю: ты бы решал это так же?

Это один из самых интересных вопросов, которые можно задать AI-reviewer: если забыть историю появления этого diff, выглядит ли само решение разумным? Не просто: есть ли здесь bugs?

Второй агент часто находит не ошибки, а другие вопросы

Именно это мне особенно нравится. Обычный review легко свести к поиску дефектов. Здесь потенциальный null. Здесь нет теста. Здесь race condition. Здесь плохое название. Это всё важно.

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

Такие замечания особенно ценны. Потому что первый агент мог очень качественно выполнить собственный план. А проблема была в плане.

Иногда второй агент пишет альтернативную реализацию

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

Получается почти маленький эксперимент.

одна задача
    ↓
два независимых подхода
    ↓
сравнение

И здесь снова интересно не определить, какая модель «победила». Мне важнее увидеть различия. Один агент предлагает расширить существующий сервис. Другой — использовать событие. Первый делает новый Value Object. Второй замечает, что нужный уже существует. Один оптимизирует минимальный diff. Другой думает о расширяемости.

После этого можно принимать решение уже не между «принять / не принять AI-код», а между несколькими инженерными вариантами. Это совсем другой уровень взаимодействия.

Получился почти маленький виртуальный code review

В обычной команде мы ведь тоже редко хотим, чтобы разработчик сам написал задачу и сам окончательно подтвердил её корректность. Есть code review. Иногда architecture review. Для рискованных изменений — несколько участников.

И не потому, что автор плохой разработчик. А потому, что независимый взгляд сам по себе имеет ценность.

С AI я сначала почему-то хотел отказаться от этого принципа. Раз агент умеет review, пусть проверит самого себя. Но постепенно понял, что старое правило никуда не исчезло. Разделение ответственности полезно и здесь. Возможно, даже особенно полезно.

«Несколько AI» не означает «несколько одинаковых AI»

Если просто дать трём моделям один prompt «решите эту задачу», можно получить много шума. Три реализации. Три объяснения. Три набора тестов. А потом самому потратить больше времени на сравнение, чем заняла бы ручная разработка.

Поэтому мне важнее не количество агентов. А разные роли. Например:

один → исследует
другой → реализует
третий → пытается найти проблемы

или

один → предлагает решение
другой → пытается его опровергнуть

Вот это уже интересно. Потому что агенты не дублируют друг друга. Они создают разные точки зрения на одну задачу.

При этом несколько агентов не отменяют мою работу

Иногда такая схема звучит почти как автоматизированная команда: первый AI пишет, второй проверяет, всё, разработчик больше не нужен. У меня пока совсем не такое ощущение. Скорее наоборот.

Чем больше участников появляется в процессе, тем важнее становится человек, который понимает, зачем вообще существует задача. Кто-то должен решить: какое бизнес-поведение нам нужно; какие ограничения действительно важны; какой риск допустим; чьему замечанию доверять; когда альтернативная реализация действительно лучше; а когда второй агент просто предлагает ещё один технически возможный вариант.

Несколько моделей дают больше материала для решения. Но само решение не становится от этого автоматически правильным.

Иногда они противоречат друг другу

И это нормально. Claude говорит: текущая abstraction подходит. Codex пишет: я бы её не расширял. Один считает изменение безопасным. Другой видит потенциальный edge case.

И теперь невозможно просто спросить: кто прав? Приходится самому разбираться. Посмотреть код. Проверить предположения. Попросить одного агента ответить на аргумент другого. Запустить дополнительный тест.

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

Иногда спор агентов полезнее их ответа

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

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

Это ещё одна причина, почему мне нравится разделение ролей.

Самопроверка всё равно остаётся

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

Получается примерно так:

implementation
    ↓
self-check
    ↓
independent review
    ↓
human decision

Каждый уровень ловит немного разные проблемы. Self-check хорошо находит: я забыл обновить тест. Независимый review может заметить: этот тест проверяет неправильное поведение. А человек может сказать: всё технически верно, но продукт вообще не должен работать так.

Я начал думать не о моделях, а о системе сдержек

Наверное, это главный сдвиг. Раньше мой вопрос звучал: какой AI лучше использовать для разработки? Теперь всё чаще: как построить процесс так, чтобы ошибка одного агента не становилась автоматически итоговым решением?

Это уже совсем другой вопрос. Можно использовать одну модель в нескольких независимых сессиях. Можно разные модели. Можно разные инструменты. Суть не обязательно в брендах. Суть в независимости этапов.

Автор не должен быть единственным reviewer. Решение не должно проверяться только тестами, которые написал тот же агент. Исходное предположение желательно хотя бы один раз подвергнуть сомнению. И здесь несколько AI-разработчиков начинают иметь смысл.

Текущая схема появилась не потому, что мне нравится сложность

Наоборот. Я бы предпочёл одну кнопку: сделай правильно. Но такой кнопки пока нет. Поэтому сейчас мой процесс всё чаще напоминает небольшую команду.

Cursor
    ↓
подготовить задачу и окружение
Claude Code
    ↓
исследовать и реализовать
Codex
    ↓
проверить и попытаться найти альтернативу
я
    ↓
решить, чему доверять

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

Один очень хороший агент всё равно остаётся одним агентом

Даже если следующая модель станет значительно сильнее нынешних. Будет лучше понимать repository. Делать меньше ошибок. Писать качественнее. Работать автономнее.

Мне кажется, потребность в разделении ролей полностью не исчезнет. Потому что вопрос не только в качестве модели. Это тот же принцип, по которому хороший senior-разработчик всё равно отправляет код на review. Не потому, что мы ему не доверяем. А потому, что хороший процесс не должен зависеть от одного взгляда.

С AI я сначала пытался этот принцип забыть. Теперь постепенно возвращаю.

Поэтому мне понадобилось несколько AI-разработчиков

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

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

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

Наверное, именно поэтому одного AI-разработчика мне постепенно стало мало. Про инструкции, которые этот процесс заставляет писать, я уже рассказывал отдельно.