Кейс Cursor: 800+ PR в месяц. Как выстроить доверие к ИИ-агентам в разработке

# Кейс Cursor: 800+ PR в месяц. Как выстроить доверие к ИИ-агентам

*«Доверие к агентам — это не вопрос веры, а вопрос инфраструктуры»*, — отмечает Лорен Тан.

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

Проблема доверия и микроменеджмента

Главное препятствие в работе с автономными агентами — психологический барьер доверия. Лорен проводит прямую параллель с управлением командой людей: если менеджер не доверяет сотрудникам, он начинает микроменеджировать каждый коммит, что убивает продуктивность. То же самое происходит с ИИ. Когда разработчик не верит агенту, он вынужден сидеть рядом с терминалом, читать каждый вывод модели, поправлять промпты и ждать результата от нескольких параллельных задач.

Лорен пришла в Cursor недавно, и её путь был непростым. В первый месяц она не могла масштабировать работу агентов из-за отсутствия понимания кодовой базы. Однако, как только она начала выстраивать систему верификации, её личная производительность резко выросла. За последний месяц она объединила тысячу пул-реквестов. Только за первые 12 дней текущего месяца количество составило почти 800 правок. Длина этих изменений варьируется от 50 до 1000 строк кода.

Этот результат кажется невероятным, но он достигается не за счёт слепого доверия, а благодаря способности агента самостоятельно проверять свою работу.

Верификация как основа цикличности

Центральным элементом системы Cursor является верификация (AI Evals). Это способность агента самостоятельно запускать код, снимать трассировки использования CPU, использовать симуляторы мобильных платформ (например, iOS) или иным образом проверять корректность изменений в реальной среде, прежде чем код будет принят в основную ветку.

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

Раньше процесс был узким горлышком: разработчик запускал сборку, видел ошибку, передавал её агенту, ждал правки и снова проверял. Лорен решила изменить этот процесс, создав специальный навык управления. Агент получил возможность самостоятельно подключаться к Chrome DevTools Protocol, анализировать флейм-графы (визуализацию производительности) и искать решения проблем без участия человека.

Функциональные карты и специализированные навыки

Однако даже продвинутые инструменты не могут знать всё обо всём. В качестве примера Лорен приводит задачу с компонентом окна агента (Glass). Агент не понимал, как взаимодействовать со сложным интерфейсом, особенно если получал расплывчатые описания вроде «левая панель тормозит» или «скриншот с вопросительными знаками».

Решением стала реализация так называемой «карты функций» (feature map). Это документ, описывающий все основные элементы интерфейса приложения, пути к ним, сочетания клавиш и атрибуты DOM. Агент использует эту карту для навигации по интерфейсу.

Плагин Pstack, созданный Лорен для Cursor, анализирует код и строит начальную карту функций. Это позволяет агенту работать даже с нечёткими запросами, точно понимая, где находится та или иная функция и как воспроизвести действие пользователя. В основе надёжности этих навыков лежит библиотека Pretext, обеспечивающая стабильность верификационных процедур.

Дополнительным инструментом стал навык HAL (Halt Before Guessing). Он предписывает агенту не предполагать причины ошибок на основе интуиции модели, а всегда читать соответствующий участок кода и использовать субагентов для поиска. Лорен сравнивает это с обучением нового инженера: если дать качественные инструкции и заставить следовать им, модель начнёт выдавать более разумные результаты.

Evals: модульные тесты для агентов

Система не работает вечно: продукты меняются, навыки устаревают. Для поддержания актуальности Лорен использует evals — по сути, модульные тесты для самого агента.

Внутри компании существует «игровой набор» (playbook) оценки. Главный агент-координатор создаёт сценарий того, что должен делать конкретный навык. Затем запускаются множественные субагенты в изолированных директориях. Названия этих директорий подобраны так, чтобы агент не понял, что его тестируют, иначе он может изменить своё поведение под давлением проверки.

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

Тем не менее, даже автоматизация не отменяет необходимости человеческого фактора. Лорен советует быть активным водителем, а не пассивным наблюдателем. Необходимо читать блоки размышлений агента (Chain of Thought), искать места, где он спотыкается, и сразу превращать эти «спотыкания» в новые правила или навыки.

Облачные агенты и архитектурные ограничения

Когда локальная верификация отлажена, можно переходить к работе с облачными агентами. В Cursor таким агентом является Benny. Он автоматически обрабатывает все входящие отчёты об ошибках. Benny запускается в облаке, открывает свой собственный экземпляр Cursor, использует те же навыки верификации и пытается воспроизвести проблему. Если баг уже исправлен в основной ветке, Benny подтверждает это, и остаётся только выпустить новую сборку.

Особое внимание Лорен уделяет проблемам рефакторинга и переписывания кода. Она отмечает, что проекты, созданные с нуля с помощью «вайбкодинга» (когда пишется код без чётких планов, по настроению), особенно опасны. Без ограничений агенты выбирают кратчайший путь решения, который со временем превращается в хаос, непонятный даже самим инженерам.

Чтобы избежать этого, Cursor строит жёсткие фреймворки. Для нового продукта Grokbot была создана архитектура Dune, основанная на принципе: делать самый короткий путь одновременно и самым правильным. Каждая функция помещается в отдельную директорию, и агенты знают, что для её изменения нужно работать только там. CI/CD процесс включает строгие проверки на уровне графа зависимостей, запрещает опасные паттерны (например, неправильное использование useEffect в React) и бессмысленные комментарии в коде.

Система выстроена по уровням: статический анализ и CI блокируют грубые нарушения, линтеры и диагностика компилятора следуют за ними, а правила и навыки агентов работают на самом верхнем уровне абстракции.

Стоимость и ROI

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

Кроме того, появление более умных моделей (например, Grok 4.6) при той же стоимости токенов ещё больше улучшает соотношение цены и качества.

Выводы

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

*«Наблюдение и чуйка остаются критически важными. Превращайте каждое место, где агент спотыкается, в новый навык».*

---

Технические пояснения:

* AI Evals: Методология оценки и валидации работы ИИ-моделей, подразумевающая запуск проверок в среде, имитирующей реальное применение кода, а не просто проверку синтаксиса. * DevTools Protocol: Интерфейс взаимодействия разработчика с инструментами отладки браузера (Chrome DevTools), позволяющий программам получать данные о производительности и работе страницы. * Feature Map: Структурированный документ или база данных, описывающая структуру интерфейса приложения для навигации агентов. * ROI (Return on Investment): Показатель эффективности инвестиций, в данном случае — экономический эффект от использования ИИ по сравнению с затратами на его развитие и токены.