Antigravity AI для команды выбирают по управлению задачами и проверке артефактов

Antigravity предлагает CTO больше, чем окно переписки с агентом. На 7 октября Google показывает отдельное приложение Antigravity 2.0 для управления агентами и Antigravity IDE для работы в редакторе. У этих поверхностей разные способы организации работы. В пилоте запишите, какую именно вы используете.

В Antigravity 2.0 проект объединяет разговоры и рабочие папки. Новую работу можно вести в общей локальной папке или в отдельной рабочей копии Git, worktree. Это даёт выбор между совместной правкой файлов и разделением изменений до их проверки.

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

После знакомства со средой выберите рабочую задачу с понятной проверкой. Демонстрация, где агент написал новый экран, оставляет открытым вопрос: выдержит ли этот экран правила вашего действующего сервиса.

Представьте задачу «добавить выгрузку отчёта». Это условный пример. Можно поручить агентам интерфейс и подготовку файла, но сначала надо договориться, какие данные выгружать, кто имеет к ним доступ и что делать при пустом результате. Эти условия одинаковы для обоих исполнителей.

В постановке задачи агенту результат описывают до запуска. Для выгрузки это файл с теми же фильтрами, что на экране, с согласованными полями и проверкой доступа. Формулировка «сделать удобный экспорт» оставляет агенту решения, которые меняют продукт.

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

Если задачи постоянно задевают одно место, последовательная работа может стоить команде меньше. Разделять стоит независимые изменения, для которых заранее понятен способ объединения.

План отвечает на вопрос «что агент собирается менять». В документации Google действие Proceed продолжает работу по плану. CTO стоит отделить это разрешение от приёмки готового изменения: до выполнения ещё нет результата, который можно принять.

Итоговый отчёт walkthrough описывает сделанное. Для браузерных задач он может включать кадры или запись экрана. Красивый кадр выгрузки не показывает, что доступ закрыт другому пользователю, а пустой список обработан правильно. Проверяющий возвращается к исходным условиям и воспроизводит сценарии.

Вопрос ответственности за ошибки возникает именно здесь. Агент готовит доказательства, инженер оценивает, достаточно ли их для принятия правки. В Antigravity 2.0 в режиме Planning настройка Request review ставит ручную остановку для предложенного плана или изменения кода; Always proceed убирает её. Выбирайте остановки под риск задачи.

В примере с выгрузкой готовность наступает после проверки фильтров, полей, доступа и пустого результата на собранной версии. Фраза агента «всё работает» этих проверок не заменяет.

У нас нет клиентского кейса внедрения Antigravity. Наш опыт относится к тому, как инженер ведёт машину vibecoding.ru: ставит задачи агентам и проверяет результат. Эти правила можно использовать как требования к пилоту новой среды, но они не доказывают её скорость.

На живом /open 7 октября указаны 2 685 тестов при каждом пуше и ревью. Это описание нашего порядка проверки на дату чтения. Из него нельзя вывести процент найденных ошибок или выигрыш от Antigravity.

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

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

Цена доступа к среде покрывает только часть исполнения беклога. Команда тратит время на постановку, проверку и возвраты. В условной задаче на выгрузку исправление фильтров после первого отчёта относится к стоимости этой же задачи.

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

В пилоте отмечайте, где задача ждала лимита среды, где ждала человека, сколько времени заняли проверка и переделки. Для сроков разработки важен весь путь до принятия. Быстрее подготовленный код может просто раньше встать в очередь на ревью.

Чтобы получить цену принятой задачи, сложите плату за доступ, дополнительное потребление и стоимость времени команды за выбранный период. Затем разделите сумму на число принятых задач. Если принимающий инженер перегружен, сначала меняйте очередь и пакет сдачи. Покупка дополнительных доступов сама по себе эту очередь не разгрузит.

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

В нашей подписке на разработку «Один проект» стоит 250 000 ₽ в месяц на 7 октября 2026. Инженер ведёт машину агентов и сдаёт правки в клиентскую ветку. Это предложение по исполнению задач; внедрение Antigravity в вашу команду в этой статье мы не обещаем.

Если пока неясно, какие задачи можно отдавать агентам, начните с теста для руководителя. Затем выберите проверяемую задачу и назначьте принимающего. До запуска Antigravity проверьте доступ рабочего аккаунта, условия выбранного плана, права и оплату: доступность для конкретной компании в РФ мы здесь не проверяли.

1. Выбирайте Antigravity по пути задачи до принятой правки. Зафиксируйте, какую поверхность и какой план проверяете.

2. До запуска опишите результат, границы изменений и общие договорённости агентов. Назначьте принимающего инженера.

3. Разделяйте разрешение выполнить план и приёмку результата. Проверяйте артефакты на сдаваемой версии кода.

4. Считайте доступ, время людей и переделки на принятую задачу. По итогам пилота решайте, вести процесс командой или передать поток исполнителю.