Четыре ИИ-субагента нашли ошибку одиночного агента

Автор эксперимента на платформе «Хабр» сравнил одиночного ИИ-агента и команду из четырёх субагентов на одной и той же задаче — исправлении платёжного инцидента в локальном монорепозитории с React, TypeScript, двумя сервисами на Java 21 и Spring Boot, PostgreSQL и Redis Streams. Обе версии работали на модели Koda Pro на базе GLM 5.3 в режиме «Очень высокий» и проверялись внешним набором из восьми скрытых HTTP-сценариев. В контрольном запуске делегирование было запрещено, в командном основной агент получил четыре read-only-роли и единолично вносил правки в файлы.

Суть дефекта оказалась многослойной. Клиент отправлял запрос на оплату, mock-провайдер создавал платёж и только потом отвечал; при медленном тестовом токене ответ занимал более 700 мс, API получал read timeout, а клиент повторял запрос. Frontend генерировал новый Idempotency-Key на каждую попытку, Spring Boot API игнорировал заголовок и записывал собственный UUID, а до провайдера ключ вообще не доходил. Дополнительно провайдер доставлял одно событие дважды, а worker не дедуплицировал event_id и не оборачивал изменения в транзакцию, что приводило к повторному исполнению заказа.

Роли в командном запуске были разделены не по файлам, а по областям неопределённости: frontend-tracer разбирал таймауты и жизненный цикл Idempotency-Key, payment-backend — транзакции и ограничения PostgreSQL, webhook-worker — подписи, Redis Streams и повторную доставку, adversarial-qa проектировал конкурентные и негативные сценарии. Такая декомпозиция позволила быстрее разложить инцидент по слоям и сформулировать проверяемые инварианты. Основной агент на основе этих данных добавил HMAC-проверку webhook по сырому телу, транзакционную обработку события, consumer group с XACK, reconciliation зависших платежей и стабильный ключ на фронтенде.

Итоговый патч команды затронул 19 файлов против 15 у одиночного агента. Внешний evaluator из восьми сценариев включал 20 конкурентных запросов с одним ключом, повтор запроса после таймаута, повтор webhook, повторную оплату заказа, новую попытку после отказа, один ключ для разных заказов, подмену суммы и неверную подпись. Одиночный агент набрал 7/8: он пропустил сценарий, в котором новый checkout уже оплаченного заказа возвращал 200 вместо ожидаемого отклонения. Командный вариант вернул 409 и получил 8/8.

Показательно, что обе версии успешно проходили production build и собственные тесты, а внутренний отчёт Kodacode был зелёным. Ошибку выявила только независимая внешняя проверка, что подчёркивает ограничения самоотчётов ИИ-агентов. Автор отдельно отмечает, что не сравнивал время и стоимость: интерфейсное время не отражало реальную продолжительность из-за пауз между сессиями, один запуск упёрся в лимит обращений, а командный агент дополнительно тратил время на поиск доступного Docker runtime.

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