Cloud Agent без composer install: зачем AI нужны заранее собранные development environments
Почему готовая VM влияет не только на скорость старта, но и на воспроизводимость, verification и стоимость автономной работы.

Build до задачи, а не после

13 августа 2026 года Cursor добавил Builds для Cloud Agents. Раньше новая cloud session могла потратить первые минуты на clone repository, установку dependencies и project setup. Теперь Cursor готовит копию development environment в фоне и держит успешную версию прогретой.

Раньше

Task → VM → clone → install → setup → work

Теперь

Build → ready VM → wait
                     ↓
                   Task → work

По внутренним измерениям Cursor, environment стал загружаться в десять раз быстрее, а показатель time to first token уменьшился втрое. Это цифры инфраструктуры самой Cursor, а не обещание одинакового ускорения любому проекту. Для меня важнее другое: setup исчезает из critical path конкретной задачи.

Build — не кеш для красивой метрики. Это заранее подготовленный рабочий компьютер виртуального разработчика.

Environment — часть capability агента

Сильной модели можно дать repository, большой context и хорошие instructions. Но если первая команда отвечает composer: command not found, автономность заканчивается раньше reasoning.

То же происходит, когда PHPUnit не видит PostgreSQL, Redis не запущен, private Composer registry недоступен или Node отличается от локальной версии. Агент ещё может предложить правдоподобный patch, но уже не способен замкнуть инженерный цикл:

research
   ↓
change code
   ↓
run application
   ↓
observe failure
   ↓
fix and verify

Поэтому реальный stack длиннее привычного набора model + tools + context. В него входит environment: runtime, package managers, services, test data, credentials и команды проверки. Без этого получается агент, который умеет рассуждать о программе, но не может доказать, что программа работает.

Почему composer install особенно заметен на короткой задаче

Возьмём обычный Symfony-проект: PHP 8.4, PostgreSQL, Redis, Messenger, Node, PHPUnit и PHPStan. «Установить зависимости» здесь редко означает одну команду. Нужно подготовить extensions, получить доступ к private packages, создать test database, применить migrations и иногда собрать frontend.

Если условное исправление правила validation занимает две минуты, а новый worker восемь минут поднимает проект, infrastructure дороже самой работы. При одном ручном запуске это раздражает. При десятках background agents — становится характеристикой платформы:

100 agent runs
× clone
× composer install
× npm ci
× project setup
= одна и та же работа 100 раз

Build переносит повторяемую подготовку в фон. Agent session получает repository, tools и disk state уже на месте, а reasoning budget тратится на issue, а не на повторный onboarding.

Что готовить в Build, а что оставлять session

В документации Builds Cursor проводит полезную границу. Команда install выполняется во время Build. Она подходит для повторяемой подготовки, результат которой сохраняется на диске: dependencies, generated code, compiled artifacts и прогретые disk caches.

start запускается уже для конкретного agent run. Там должны жить процессы, которым требуется свежее session state: Docker daemon, databases, tunnels и другие services. Долгоживущие app processes можно вынести в отдельные terminals.

BUILD TIME
composer install
npm ci
generate code
compile assets

SESSION START
start Docker
start PostgreSQL / Redis
start dev server
prepare disposable test state

Причина техническая: Build сохраняет disk state, но не работающие процессы, shell exports и in-memory caches. Поэтому попытка «запечь» поднятую PostgreSQL в snapshot создаёт иллюзию готовности. Сохранять нужно воспроизводимые артефакты, а volatile state — поднимать заново.

Есть и практическое правило: install должен быть полным и идемпотентным. Background build может запускать его регулярно и поверх уже подготовленного диска. Команда, которая работает только один раз на чистой VM, рано или поздно превратит environment в лотерею.

Последний успешный Build создаёт known-good channel

Cursor клонирует repositories из default branch, выполняет install, сохраняет bootable snapshot и фиксирует точный commit SHA каждого repository. Успешная сборка становится active Build.

Если следующее обновление ломает Dockerfile или dependency installation, неуспешный Build не заменяет рабочий. Agents продолжают стартовать с последней успешной версии, пока команда разбирает failure:

Build 41  SUCCESS → ACTIVE
Build 42  FAILED  → REJECTED

new agents → Build 41

Это уже не обычный project setup, а deployment semantics для development environment: собрать, проверить, активировать. Хрупкая latest-версия не должна автоматически становиться компьютером всей agent fleet.

Feature branch при этом получает code своей ветки поверх active Build. Если в ней изменились dependencies, agent может повторно выполнить install. База остаётся быстрой, но branch не обязана притворяться, что её composer.lock совпадает с default branch.

Рабочее место тоже становится configuration as code

Cloud environment можно описать через .cursor/environment.json: указать snapshot или Dockerfile, install, start и terminals. Builds читают конфигурацию из default branch.

Это важнее конкретного формата файла. Версии PHP и Node, системные packages, способ установки dependencies и startup commands перестают жить в голове одного разработчика. Они проходят version control и меняются вместе с приложением.

В результате repository содержит три разных контракта:

Application code  → что делает система
AGENTS.md / Skill → как с ней работать
Environment      → где её запускать и проверять

В статье о Cloud Subagents отдельная VM давала execution isolation. Builds закрывают следующую проблему: изолированный компьютер становится не пустым, а заранее проверенным.

Фраза «tests passed» получает provenance

У каждого environment появился Builds tab со статусом, временем, logs и commit SHA. Agent run хранит ссылку на Build, из которого стартовал. Поэтому результат можно связать не только с prompt и final diff, но и с конкретной машиной:

Agent Run #581
├── repository commit abc123
├── environment version 18
├── Build #104
├── install logs
└── test evidence

Если на следующий день тот же test падает локально, появляется нормальная точка расследования: сравнить code SHA, environment configuration, dependencies и logs. Такой provenance давно привычен в CI. Теперь он нужен и AI-workload.

Это влияет на доверие сильнее пары минут старта. Разработчик получает не утверждение «код выглядит правильно», а evidence из известной среды. Чем длиннее и автономнее работа, тем важнее возможность воспроизвести не только diff, но и условия проверки.

Reusable environment остаётся security boundary

Готовая машина не должна превращаться в образ со всеми секретами компании. Cursor разделяет credentials по жизненному циклу: team и environment secrets доступны Build, если install требует private registry или artifact store. User secrets добавляются только при старте agent session и не попадают в общий snapshot.

Для enterprise PHP-проекта это позволяет дать worker доступ к internal Composer, development PostgreSQL, Redis и тестовым API, но не открывать production database или SSH. Environment одновременно расширяет возможности агента и задаёт пределы:

ALLOWED
private packages
test services
sanitized fixtures

NOT REQUIRED
production write access
production SSH
billing credentials

Та же причина делает полезными self-hosted Cloud Agents: сложной корпоративной codebase часто нужны внутренние сети, certificates и caches, но это не означает, что ей нужен бесконтрольный production access.

Как выглядит agent-ready repository

Одного Build мало, если workflow остаётся набором tribal knowledge. Агент не должен угадывать пять shell-команд, порядок очистки Redis и имя test database. Надёжнее дать короткие интерфейсы:

make setup
make test-api
make lint
make verify

# или эквивалентные composer scripts

Cursor описывает собственный environment именно как продукт для агентов: cloud должен быть похож на local development, common workflows — иметь простой interface, а core changes — проверяться end-to-end. Внутри своего monorepo компания свела сложные команды к единому CLI, чтобы модель не управляла каждым фоновым процессом самостоятельно.

Я бы проверял готовность repository четырьмя вопросами:

• совпадают ли ключевые версии runtime и services с локальной разработкой;
• можно ли поднять и проверить проект детерминированными командами;
• есть ли безопасные representative fixtures для сложных сценариев;
• может ли новый worker выполнить core workflow без неформальной подсказки коллеги.

Это полезный тест и для людей. Если environment приходится формализовать ради AI, onboarding следующего разработчика тоже становится короче.

Главный результат — не скорость, а предсказуемость

Самая заметная цифра релиза — трёхкратное сокращение time to first token. Но настоящая ценность Builds проявляется позже: меньше setup failures, одинаковая база для нескольких agents, понятный fallback и проверяемая связь между run и environment.

Автономный coding agent — это не только сильная модель:

Useful autonomy
= model
+ instructions
+ tools
+ reliable environment
+ verification evidence

Если последний компонент нестабилен, agent тратит время на собственный onboarding или приносит непроверенный patch. Если машина заранее собрана и известна, задача может начинаться с issue, а заканчиваться запущенным приложением и воспроизводимыми tests.

Именно поэтому Builds — не мелкая оптимизация вокруг composer install. Это переход от случайной VM к постоянной инфраструктуре виртуального разработчика: компьютер готовится заранее, обновляется вместе с repository и ждёт следующую инженерную задачу уже в рабочем состоянии.