Кнопка запуска задач в облаке (Cloud Agents) выглядит привлекательно: нажал, закрыл крышку ноутбука, а через полчаса забрал готовый Pull Request. На практике большинство разработчиков после первых двух попыток плюются: агент сжигает кучу кредитов, не видит половину локального окружения и присылает кривой PR с закомментированными тестами.
Чтобы этот инструмент приносил пользу, а не дыру в бюджете, нужно понимать, как среда выполнения устроена физически и чем облачная изоляция отличается от работы локального Composer в редакторе.
Где физически крутится код: локальный редактор против песочницы
Когда вы работаете в локальном Agent Mode, модель правит файлы прямо на вашем SSD. У нее под боком все ваше рабочее окружение: локальный .env со всеми ключами, запущенный в докере PostgreSQL, Redis, локальный dev-сервер на localhost:8000 и ваши незакоммиченные файлы в соседних вкладках. Вы видите каждый шаг, а главное — можете остановить процесс в ту же секунду, когда модель понесло не в ту степь.
С Cloud Agents логика другая. Нажатие на кнопку отправки задачи не переносит вашу рабочую папку в облако. Происходит следующее:
- На удаленном сервере (в микро-VM вроде Firecracker или контейнере E2B) поднимается чистый инстанс Linux.
- Агент клонирует указанную ветку вашего репозитория напрямую с GitHub или GitLab. Вашего локального диска для него не существует.
- Если у вас в проекте нет файла
.cursor/Dockerfile, сборка окружения идет в стандартном базовом контейнере. Если для запуска тестов нужны системные либы или расширения PHP, которых там нет — они просто не запустятся. - Агент в цикле ищет файлы, правит их, пытается выполнить ваши проверочные команды, коммитит изменения в новую ветку и пушит PR в репозиторий.
Почему облачные агенты часто лажают
Главный источник разочарования — попытка скормить облаку обычную задачу из середины спринта. Почти всегда это упирается в три проблемы:
1. Отсутствие локального состояния и секретов
Если проект завязан на базу данных или локальные моки, облачный агент на первом же запуске pest или phpunit ловит ошибку подключения к базе. Вместо того чтобы остановиться, он пытается «починить» окружение: начинает переписывать .env.example, менять порты в конфигах или, что хуже, просто глушить упавшие ассерты в тестах.
2. Автономность без надзора и наценка MAX Mode
В облаке нет человека, который нажмет Esc. Задачи принудительно запускаются в режиме MAX Mode (это добавляет 20% к стоимости кредитов за запрос, так как используются топовые модели без возможности переключиться на экономный вариант).
Если задача сформулирована широко, агент легко накручивает 40–60 шагов. Он читает десятки файлов, контекст раздувается до 100k токенов, и один прогон обходится в несколько долларов. На тарифе Pro за $20 месячный лимит fast-запросов можно сжечь буквально за 4–5 таких запусков.
3. Синдром ложного успеха (Premature completion)
Агент запрограммирован доводить задачу до конца. Если он не может победить сложный баг в логике, велик соблазн объявить задачу выполненной, написав в описании PR красивый отчет, хотя половина краевых кейсов осталась сломанной.
Где от Cloud Agents есть реальный выхлоп
Облачные агенты бесполезны для написания сложной бизнес-логики с нуля, но отлично окупаются на рутинных изолированных задачах, которые разработчику лень делать руками:
- Массовые миграции вызовов API: Замена старого HTTP-клиента на новый интерфейс в 30 сервисах, обновление сигнатур методов после мажорного апа библиотеки. Это чисто механическая работа по шаблону.
- Покрытие чистыми unit-тестами: Написать тесты для хелперов, DTO, парсеров и сервисов валидации, которым не нужна база данных и внешние API. Агент гоняет тесты в цикле песочницы до зеленых галочек.
- Рутина статического анализа: Поднять уровень PHPStan с 6 до 8, расставить строгие типы аргументов и PHPDoc-аннотации по всей директории контроллеров.
- Параллельная работа: Пока вы локально проектируете ядро фичи, можно запустить двух облачных агентов — одного на написание документации к эндпоинтам, второго на рефакторинг старых миграций.
Как правильно ставить задачу облачному воркеру
Чтобы не получить мусор в PR, промпт для облачного агента должен выглядеть не как пожелание, а как жесткий bash-скрипт с критериями приемки:
Контекст:
Обновление сигнатур сервиса App\Services\OrderCalculator.
Что сделать:
1. Заменить все нетипизированные аргументы в методах OrderCalculator на строгие типы (int, float, Money).
2. Затронуть ТОЛЬКО файлы в app/Services/OrderCalculator.php и тесты в tests/Unit/OrderCalculatorTest.php.
3. Не менять публичные интерфейсы, на которые завязаны контроллеры.
Команда проверки:
vendor/bin/pest tests/Unit/OrderCalculatorTest.php
Критерий сдачи:
Не создавать PR и не завершать задачу, если pest возвращает код ошибки отличный от 0.
Файлы конфигурации и окружения не трогать.
Если задавать жесткие границы файлов и команду автоматической проверки, облачный запуск начинает экономить часы рутины. Если ставить абстрактные задачи вроде «оптимизируй работу корзины» — облако просто сожжет подписку впустую.