Автор пет-проекта IDE столкнулся с типичной проблемой при работе с coding-агентами: модель находит правдоподобную причину бага, уверенно меняет код, но ошибка не уходит. На просьбу «проверь себя» агент не возвращается к исходной задаче, а достраивает свою версию костылями — добавляет условия, исключения, проверки. В итоге вокруг посредственного решения вырастает конструкция, которую приходится поддерживать, хотя стоило бы пересмотреть саму гипотезу.
Чтобы остановить агента до первой правки, разработчик решил внедрить в IDE многоролевое планирование. Идея не нова: multi-agent debate и фреймворки вроде AutoGen существуют давно. Автор взял эту основу и описал собственную схему управления обсуждением. В каждом эксперименте четыре роли — архитектор, разработчик, рецензент и тестировщик — исполняла одна и та же LLM, но отдельными вызовами с разными инструкциями. Сначала это был DeepSeek, затем Qwen. Первый круг делался независимым: участники не видели ответы друг друга, иначе вместо четырех версий получалась одна и три вежливых согласия. После этого они читали предложения коллег, критиковали их, а отдельный вызов собирал общий план. Только потом генерировался патч.
| Режим | Что происходит | Вызовов на задачу |
|---|---|---|
| Сразу к коду | Сразу генерируем патч | 1 |
| Один план | Сначала план, потом патч | 2 |
| Полный совет | Четыре роли, обязательная критика, план, патч | 10 |
| BVC | Тот же совет, но критика включается условно | 6 или 10 |
Полный совет стоил десять вызовов на задачу: четыре первоначальных ответа, четыре критики, общий план и патч. Даже когда дополнительный круг не менял направление решения, в правилах не было варианта «на этом достаточно». Умножив совещание на число задач, автор заметил, что контекст отправляется модели повторно, ответы удлиняются, счетчик токенов растет. Возникла инженерная мысль: зачем запускать дорогую часть процесса без проверки, нужна ли она.
Так появился Budgeted Verified Council (BVC). У полного совета появилась развилка перед критикой. Роли должны были вернуть структурированные позиции: предполагаемую причину ошибки, способ исправления, затрагиваемые зависимости и тесты. Система сравнивала эти поля и решала, нужен ли второй круг. Если оснований продолжать нет — сразу собирается план, получается шесть вызовов вместо десяти. Если есть — запускается критика, и расходы остаются прежними. На бумаге схема выглядит просто, но вся сложность в том, чтобы ранняя остановка не выбрасывала полезную проверку. И нужно было убедиться, что система правильно понимает, когда участники расходятся во мнениях.
Для тестов автор взял 60 задач SWE-bench Verified из 11 Python-проектов. Это настоящие issue и исходники: нужно получить патч, который применится к нужному состоянию репозитория и пройдет тесты. Выборка намеренно была сложнее средней: самые легкие задачи, оцененные менее чем в 15 минут работы, не вошли. Для каждой задачи сравнивались четыре режима: «сразу к коду» (один вызов), «один план» (два вызова), «полный совет» (десять вызовов) и BVC (шесть или десять). Режим «один план» особенно важен: он позволяет отделить пользу от многоролевого обсуждения от эффекта простой просьбы сначала подумать.
Внутри каждой модельной серии методы получали одинаковое описание задачи и одинаковые файлы. Контекст выбирался поиском по репозиторию; все 245 выбранных файлов автор сверил с исходными ревизиями — совпали побайтно. Эталонные патчи и проверочные тесты в запросы к модели не попадали. Настройки и список задач были зафиксированы до получения результатов, неудачные ответы тоже оставались в выборке.
В итоге — 480 основных запусков, две модели и несколько миллионов токенов, которые можно было не тратить. Самая полезная находка оказалась не в итоговой таблице, а в понимании, когда останавливать агентов. BVC показал, что можно сократить расходы без потери качества, если правильно определять момент, когда спорить уже не о чем. Однако автор признает, что у системы были проблемы с распознаванием реальных разногласий, и это направление требует дальнейшей работы.
