Cursor Cloud Agents получили Computer Use: почему написать код AI уже недостаточно
Как превратить Definition of Done в verification plan и доказать результат через приложение, браузер и logs.

Что Cursor выпустил 24 февраля

24 февраля 2026 года Cursor добавил Computer Use в Cloud Agents. После подключения к codebase каждый агент работает в отдельной изолированной VM с полноценным development environment. Он может запустить сервер, открыть созданное приложение, управлять браузером мышью и клавиатурой, пройти UI flow и проверить изменение до отправки pull request.

Вместе с PR агент возвращает artifacts: screenshots, videos и ссылки на logs. Разработчик может посмотреть демонстрацию результата, а при необходимости перехватить remote desktop и самостоятельно проверить приложение в той же VM, не выкачивая branch локально.

В описании собственного опыта Cursor сообщает, что больше 30% внутренних merged PR на тот момент создавали автономные агенты в cloud sandboxes. Это метрика одной компании, а не универсальный benchmark. Гораздо интереснее другой тезис релиза: агент больше не обязан передавать человеку первую версию diff — он получает возможность запустить её, обнаружить проблему и сделать следующую итерацию сам.

Зелёный код ещё не означает работающую функцию

Представим задачу для Laravel 13: добавить создание клиента в Filament. Агент создаёт model, migration, Resource, form schema, validation и feature-тесты. PHPUnit проходит, Pint ничего не меняет, PHPStan молчит.

После открытия /admin/customers/create выясняется, что кнопка сохранения уехала ниже viewport, validation очищает уже заполненные поля или action падает из-за JavaScript-ошибки. Backend-проверки честно подтвердили заложенные в них условия. Пользовательский сценарий в эти условия просто не попал.

code written      ✓
tests passed      ✓
user completed flow?
                  unknown

Web-приложение нельзя свести к цепочке Controller → Service → Database. Для пользователя это Browser → Page → Form → Request → Updated UI. Если агент наблюдает только terminal output, половина системы остаётся за пределами feedback loop.

Code verification и product verification отвечают на разные вопросы

Unit tests, integration tests, static analysis, type checks и lint проверяют технический контракт реализации. Они нужны всегда, но отвечают на вопрос: «выполняет ли код описанные машинные условия?»

Browser flow, runtime state, visual result и console logs проверяют другое: «может ли пользователь получить ожидаемый результат?» Для full-stack feature нужны оба уровня.

CODE VERIFICATION
PHPUnit + PHPStan + lint
        │
        ▼
PRODUCT VERIFICATION
run app + user flow + UI + logs

Я не заменяю тесты ручным кликаньем агента. Computer Use закрывает промежуток между зелёным suite и реальным поведением приложения, а не отменяет regression-защиту.

Computer Use замыкает feedback loop

Обычный агентный цикл уже умеет реагировать на terminal:

WRITE → TEST → FAILURE → FIX → TEST

Computer Use расширяет наблюдение. Теперь failure может прийти не из PHPUnit, а из disabled-кнопки, неправильного redirect, пустого Turbo Frame, browser console или application log.

IMPLEMENT
   ↓
RUN APPLICATION
   ↓
USE FEATURE
   ↓
OBSERVE UI + CONSOLE + LOGS
   ↓
COMPARE WITH REQUIREMENT
   ↓
FIX AND VERIFY AGAIN

Это переход от open-loop автономности, где человек первым запускает результат, к closed-loop: агент сам получает обратную связь от продукта. Чем дольше он работает без наблюдения, тем ценнее такой цикл.

Definition of Done превращается в verification plan

Фраза «добавить форму создания клиента» плохо подходит автономному агенту. Даже рабочая форма может потерять данные после validation error или показать success до записи в database.

Сначала я бы зафиксировал наблюдаемое поведение:

DONE WHEN
- форма открывается
- обязательные поля валидируются
- ошибки отображаются рядом с полями
- введённые данные сохраняются после ошибки
- клиент создаётся и появляется в списке
- повторная отправка не создаёт дубль
- browser console и application log чистые

Из этого агент может построить план проверки до реализации: создать клиента с валидными данными, повторить сценарий с пустым email, проверить сохранение state, обновить список и просмотреть logs. Definition of Done описывает ожидаемый outcome, verification plan — способ его доказать.

Как выглядит проверка Filament-ресурса

Для задачи «добавить управление категориями» техническая часть предсказуема: Category, migration, Filament Resource, form, table, validation и tests. Browser verification проверяет то, чего не видно из структуры классов.

1. Start application
2. Open /admin and log in
3. Navigate to Categories
4. Create a category
5. Verify it appears in the table
6. Edit name and active state
7. Check validation with duplicate slug
8. Delete the record
9. Check console and Laravel log
10. Capture the success and error states

Это минимальный acceptance test, а не исследование каждого цвета и отступа. Для UI-задачи я отдельно добавил бы mobile viewport, keyboard flow и длинный текст. Агент не догадается о важных состояниях только потому, что получил браузер.

Artifacts превращают PR в проверяемый отчёт

Фраза агента «Successfully implemented» ничего не доказывает. Video с полным flow, screenshots двух состояний и logs дают reviewer возможность увидеть, что именно запускалось и какой результат наблюдал агент.

PULL REQUEST
├── What changed
├── Automated checks
├── Verification scenario
├── Screenshots / video
├── Relevant logs
├── Known risks
└── Out of scope

Для визуального изменения review можно начать с outcome: как фильтр ведёт себя в браузере, как выглядит validation error, сохраняется ли state при pagination. После этого reviewer читает diff и оценивает архитектуру.

Artifacts — evidence, но не сертификат корректности. Screenshot успешной формы не подтверждает authorization, accessibility или отсутствие N+1. Видео доказывает лишь пройденный сценарий. Поэтому хороший отчёт должен явно перечислять, что не проверялось.

Особенно полезна проверка вне собственных тестов агента

Агент способен одинаково ошибиться в implementation и в написанном им test. Если requirement говорит «не больше пяти активных токенов», модель может посчитать все токены, закрепить это поведение тестом и получить зелёный suite.

wrong interpretation
        ↓
wrong implementation
        +
matching test
        ↓
green, but wrong

Browser или реальный HTTP-сценарий, построенный непосредственно из acceptance criteria, добавляет другой путь проверки. Ещё сильнее независимый verifier: второй агент получает task, критерии и запущенное приложение, но не reasoning автора. Он пытается выполнить сценарий заново и возвращает конкретный failure.

Computer Use не заменяет Playwright

Playwright выполняет заранее написанный детерминированный сценарий и защищает его при каждом запуске CI. Computer Use позволяет агенту самому решить, как исследовать новую feature прямо сейчас. Это разные горизонты.

Computer Use
explore → verify current task → collect evidence

Playwright
encode stable scenario → run repeatedly in CI

Лучший маршрут соединяет оба подхода. Агент проходит новый flow, находит устойчивые шаги и превращает критичный сценарий в E2E test. После merge regression ловит уже Playwright, а не надежда, что следующий агент снова кликнет по тем же кнопкам.

У разных задач разное доказательство результата

Браузер не нужен каждому diff. Verification должен соответствовать внешнему интерфейсу изменения:

• backend — PHPUnit, PHPStan и реальный HTTP request;
• database — migration up/down, schema check и запрос на реальных test fixtures;
• API — functional tests, HTTP-сценарий, OpenAPI validation и logs;
• UI — frontend tests, browser flow, console, mobile/desktop screenshots;
• full-stack — backend suite, запущенное приложение и end-to-end acceptance flow.

Computer Use особенно заметен в UI, но полезен и backend-разработчику. Изменение стоимости доставки можно дополнительно проверить в checkout; permissions — зайти под двумя ролями и сравнить доступ; новую queue job — инициировать из интерфейса и увидеть итоговое состояние.

Агент видит только то, что ему поручили проверить

У browser verification есть собственные failure modes. Агент может пройти happy path и пропустить empty state, mobile layout, клавиатуру, медленную сеть или повторный submit. Он может принять визуально похожий результат за бизнес-корректный.

Поэтому Computer Use усиливает требования к task engineering:

• acceptance criteria должны быть наблюдаемыми;
• test data и роли — известными заранее;
• проверяемые viewport и error states — перечисленными;
• доступ к secrets, network и production — ограниченным;
• остановка обязательна, если окружение не позволяет воспроизвести сценарий.

Если приложение не стартовало, агент должен вернуть blocked report с setup logs, а не приложить screenshot ошибки и объявить feature готовой.

Как должен выглядеть финальный отчёт агента

Для изменения email в Symfony-профиле я ожидал бы не «Done», а компактный evidence report:

IMPLEMENTATION
- UpdateEmail DTO and validator
- application service
- profile action

AUTOMATED CHECKS
- 6 functional tests
- PHPUnit: pass
- PHPStan: pass

PRODUCT VERIFICATION
- changed email through UI
- reload confirmed persisted value
- invalid email kept form state and showed error
- console and application log: no new errors

ARTIFACTS
- success-state screenshot
- validation-state screenshot
- user-flow video

NOT VERIFIED
- email confirmation delivery
- mobile viewport

Так reviewer оценивает не уверенность формулировки, а полноту проверки. Если важен mobile, он сразу видит пробел и возвращает задачу до чтения большого diff.

Следующая единица работы — доказанный outcome

Computer Use важен не наличием виртуальной мыши. Он добавляет Cloud Agent источник обратной связи, который раньше почти всегда предоставлял человек: запустить приложение, пройти сценарий, заметить несоответствие и повторить попытку.

Cursor показал это на собственных задачах: агент проверял ссылки в UI, воспроизводил vulnerability через локальную страницу и 45 минут проходил функции documentation site. Во всех трёх случаях ценность была не в количестве написанных строк, а в возможности продемонстрировать поведение.

Для меня зрелый coding agent заканчивает работу только после четырёх состояний: implemented, tested, verified, reviewed. Computer Use помогает самостоятельно перейти от второго к третьему. Человеческий review остаётся последней границей — проверяет архитектуру, бизнес-смысл, риск и достаточность evidence.

Единицей делегирования постепенно становится не diff, а доказанный outcome: функция работает в оговорённом сценарии, ограничения перечислены, а результат можно проверить без доверия к фразе «task completed».