Google добавил в свою среду разработки Antigravity новую команду под названием /boost. Её вызов запускает многоагентный конвейер рассуждений вместо одного ассистента для программирования: оркестратор читает задачу и разбивает её на подзадачи, распределяет их между специализированными агентами, работающими в изолированных областях, а затем пропускает результат через независимые раунды проверки, которые действительно запускают тесты, прежде чем что-либо дойдёт до вас. Главная новость не в том, что ИИ пишет код быстрее. А в том, что инструменты для программирования начали встраивать проверку в сам инструмент.

Что именно объявил Google

Согласно официальной документации Antigravity, /boost предназначен именно для сложной программной инженерии: ошибок параллелизма и состояний гонки, алгоритмической оптимизации, тонких регрессий, которые то появляются, то исчезают, и запутанного рефакторинга в нескольких файлах. Это именно те задачи, на которых проваливается обычный ассистент с одним ходом, потому что для их решения нужны эксперименты и откаты, а не прямая генерация.

Команда выполняется в три чётких этапа:

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

Всё это выполняется во временных изолированных worktree, то есть агенты не экспериментируют с вашей рабочей копией проекта.

Три режима, а не один

Google описывает три разных режима выполнения, и разница между ними и есть практически полезная часть:

  • Агент по умолчанию: интерактивное программирование, навигация по кодовой базе и общий рефакторинг. Горизонт задачи от секунд до минут, цикл с одним агентом, проверка за один проход. Доступен на всех тарифах.
  • /boost: глубокие рассуждения и упорные ошибки. Горизонт задачи от секунд до часов, трёхфазная иерархия, многораундовая независимая проверка. Доступен на платных тарифах.
  • /teamwork-preview: команды агентов, которые днями работают над крупными миграциями или созданием целых подсистем, с именованными ролями, такими как Explorer, Worker, Critic и Auditor, а также с контрольными точками проверки, которые намеренно пытаются сломать код, прежде чем этап будет одобрен.

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

Почему это важно владельцу бизнеса, а не только разработчику

Последние два года разговор об ИИ в программировании был разговором о скорости: сколько строк генерируется в минуту. Проблема в том, что скорость не является узким местом в реальных проектах. Узкое место — доверие. Действительно ли этот код работает в случаях, которые никто не проверял?

Архитектура /boost неявно говорит о том, что отрасль пришла к тому же выводу. Код, который приходит быстрее, ничего не стоит, если после передачи он обходится в две недели отладки. Поэтому инструмент построен вокруг трёх правил, применимых к любой технической команде, с ИИ или без:

  • Автор не оценивает собственную работу: проверяющая сторона отделена от той, что выполнила реализацию. На этом принципе десятилетиями строилось ревью кода. Теперь он закреплён внутри инструмента.
  • Доказательство — это выполнение, а не утверждение: тесты действительно запускаются, и проверяется их реальный вывод, вместо того чтобы принимать на веру заявление, что они прошли.
  • Изоляция защищает оригинал: эксперименты проводятся в отдельной копии, поэтому неудачные попытки никогда не попадают в проект.

Если вы заказываете разработку ПО, это ровно те три вопроса, которые стоит задать поставщику: кто проверяет, каково доказательство, что тесты прошли, и где проводятся эксперименты?

Что не меняется

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

И права доступа — меньшая половина дела. Агент решает задачу, которую вы описали. Он не может знать, что само описание было неверным. Он не знает, что ваш расчётный период закрывается 25-го, а не 30-го числа, что это поле никогда не должно быть видно менеджеру по продажам или что когда ваш клиент говорит "заказ", он имеет в виду не то, что вы. Определение требований, понимание предметной области и ответственность за решение остаются целиком человеческой работой.

Как мы смотрим на это в Origami

Мы относимся к многоагентным инструментам так же, как к любому инструменту продуктивности: они ускоряют выполнение, но не передают ответственность. Проект у нас по-прежнему проходит через письменные спецификации, ревью людьми, набор тестов и staging-среду перед продакшеном, независимо от того, написал ли код человек или сгенерировал агент. Инструмент, который сам запускает свои тесты, — желанное дополнение к этой цепочке, но это её звено, а не замена.

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

Источники