13 агентів замикають цикл тестів і виправлень

Як працює цикл із 13 агентів

Тут привертає увагу сама механіка: 13 паралельних підписок Codex і Claude використовують як пул спеціалізованих агентів. Одні запускають тести та готують звіти про помилки, інші автоматично створюють виправлення. На момент обговорення сукупні витрати оцінювали у межах від 100 до 200 доларів.

Сильна сторона схеми не в кількості підписок, а в поділі ролей. Агент тестування формулює відтворюваний дефект, агент-виконавець отримує обмежене завдання, після чого результат знову має пройти перевірку. Так виникає замкнений контур, а не просто натовп моделей, що одночасно редагують один репозиторій.

Формальну рамку для такого підходу Microsoft описує у довідковій архітектурі мультиагентних систем і документації з мультиагентних патернів. Акцент зроблено на оркестрації, керуванні та обміні повідомленнями між спеціалізованими агентами, зокрема A2A для міжплатформної взаємодії. Це вже мова виробничої архітектури, а не ефектної демонстрації.

Є і суворіша перевірка самої ідеї автономного ремонту. У дослідженні Google агентний підхід оцінювали на 178 помилках із внутрішньої системи обліку. За 20 траєкторій і Gemini 1.5 Pro система Passerine підготувала правдоподібні патчі для 73% машинних звітів і 25,6% звітів, створених людьми. Правдоподібний патч, звісно, ще не означає безпечне злиття змін.

Насамперед я б перевірив чотири межі:

• ізоляцію робочих копій і середовищ;
• захист від конфліктних патчів;
• незалежність агента тестування від автора виправлення;
• умови зупинки нескінченного циклу тестів і правок.

Що насправді змінюється в розробці

Практичний зсув реальний: агенти починають ділити інженерний процес на ролі, а не просто відповідати по черзі в одному чаті. Це дає змогу паралельно шукати дефекти, готувати патчі та перевіряти зміни, особливо коли завдання добре ізольовані й мають виконувані тести.

Проте один клієнтський кейс не доводить масового впровадження такої схеми в компаніях. Документи Microsoft і Salesforce показують, що мультиагентні архітектури вже формалізують для корпоративних систем, а SWE-bench, RepairBench і DevAgentBench пропонують способи вимірювати виправлення коду, генерацію тестів і рев'ю. Між архітектурним патерном і надійним автономним конвеєром усе ще лежить контроль якості.

Головний ризик тут доволі іронічний: прискорити генерацію патчів простіше, ніж довести, що агенти не навчилися колективно підтверджувати власні помилки. Справжня автономність почнеться там, де незалежна перевірка витримає швидкість цього циклу.

Раніше ми розглядали, як паралельні агенти Claude Code можуть перевіряти pull request'и та виявляти race conditions до потрапляння в CI/CD. Цей підхід доповнює мультиагентні процеси тестування й виправлення помилок, що розподіляють завдання розробки між спеціалізованими LLM-агентами.