Інженер xAI побудував команду з 200+ агентів

Як розкласти систему на ролі, а не на один універсальний бот

У показаній схемі п’ять інженерних ботів розподіляють між собою iOS, Android, Desktop, CI/CD, інфраструктуру та Grok Bot harness. Вони не виконують усю роботу самі, а керують більш ніж 200 Cursor cloud agents. Відтворювати тут варто не кількість агентів, а поділ на спеціалізації та окремий рівень нагляду.

Перший робочий сценарій — супровід потоку змін. Спеціалізовані боти кожні 30 хвилин читають спільну базу PR у Notion і перевіряють стан роботи. Послідовність можна зафіксувати так:

• визначити, який бот відповідає за конкретний клієнт, CI/CD, інфраструктуру або harness;
• дати ботам одну зовнішню пам’ять із даними про PR;
• за розкладом перевіряти CI, конфлікти, security findings і коментарі;
• дозволяти автоматичний merge лише тоді, коли перевірки пройдено і зміна не є великою.

Формулювання для такого контролера може бути прямим: Переглянь базу PR. Для кожного PR перевір CI, конфлікти, security findings і коментарі. Якщо все гаразд і зміна не велика, передай PR на автоматичний merge.

Ще два сценарії: нічний аудит і контроль самих ботів

Другий сценарій не прив’язаний до окремого PR. О 3:00 окремі аудити перевіряють стан продукту: мертвий код, швидкість запуску застосунків, розміри пакетів і ключових модулів, безпеку, локалізацію та розбіжності між клієнтськими застосунками. Це окремий контур контролю, бо звичайна перевірка PR не охоплює весь перелік.

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

Третій сценарій — операційний нагляд за агентами. Бот Jenny не пише код. О 5:00 він проводить щоденні 1:1 з іншими ботами, переглядає playbooks і шукає проблеми. Після помилки запускає postmortem, а висновок переносить у правила. Робоче формулювання: Переглянь роботу кожного бота і його playbook. Знайди проблеми. Після помилки проведи postmortem та онови правила так, щоб інші агенти не повторили її.

Де автоматизацію треба обмежити

Автоматичний merge у цій моделі не є дозволом на злиття будь-яких змін. У джерелі він допускається, якщо перевірки не виявили проблем і PR не містить великих змін. Отже, великий PR виходить за межі автоматичного сценарію навіть за успішного CI.

Режим P0 теж не підходить для постійної роботи. У ньому бот приблизно кожні п’ять хвилин перевіряє прогрес і активно втручається. Автор прямо попереджає: такий темп швидко витрачає токени. Його варто відокремити від стандартного 30-хвилинного циклу і вмикати саме для критичних задач.

• Не переносити автоматичний merge на великі зміни.
• Не тримати всі задачі в режимі P0 через швидкі витрати токенів.
• Не зводити контроль лише до PR: нічні аудити перевіряють інші типи проблем.
• Не доручати операційному боту написання коду, якщо його роль — 1:1, playbooks, postmortem і правила.

Що перевірити людині перед довірою до результату

Перевірка має повторювати контрольні точки самої системи. Для PR це стан CI, наявність конфліктів, security findings, невраховані коментарі та масштаб зміни. Для нічного аудиту — чи охоплено всі заявлені напрями, включно з локалізацією і розбіжностями між клієнтами. Після збою треба перевірити, чи відбувся postmortem і чи справді оновлено правила.

• Чи є PR у спільній базі та чи бачить його відповідальний бот.
• Чи пройдено CI і чи немає конфліктів, security findings або коментарів без реакції.
• Чи не класифіковано велику зміну як придатну до автоматичного merge.
• Чи зафіксував нічний аудит проблеми в кожній зі своїх категорій.
• Чи перетворено висновки postmortem на оновлення playbook або правил.