Cursor выстраивает доверие к ИИ-агентам через несколько независимых контуров контроля: запуск кода в реальной среде, трейсинг действий, навыки для типовых операций, feature map кодовой базы, evals и обязательные CI-проверки. Агент получает возможность действовать самостоятельно, но его результат оценивают по наблюдаемым признакам, а не по уверенности в формулировках модели.
Такой подход меняет сам критерий надежности. Хороший агент не тот, кто быстро выдает большой diff, а тот, чьи действия можно воспроизвести, проверить и остановить до попадания ошибки в основную ветку. Именно поэтому текстовые инструкции дополняются исполняемыми проверками: тестами, линтерами, статическим анализом и ограничениями на операции с кодом.
Эта логика полезна и за пределами Cursor. Команда может начать с локального запуска кода и нескольких evals для критических навыков, а затем закрепить минимальные требования в CI. Такой процесс помогает перейти от разовых экспериментов к воспроизводимой работе с AI-агентами.
Почему доверие к ИИ-агентам - главная проблема
Типичный сценарий выглядит убедительно только в начале. Разработчик поручает агенту небольшую задачу, получает рабочий прототип за несколько минут и расширяет область доступа. Затем появляются скрытые издержки: неверные предположения о структуре проекта, дублирование логики, тесты для удачного сценария без обработки ошибок и изменения в файлах, которых агент не должен был касаться.
Скорость генерации кода не показывает стоимость последующего ревью. Если разработчик тратит 20 минут на написание функции и час на восстановление контекста, проверку зависимостей и исправление побочных эффектов, выигрыш оказывается сомнительным. Об этом подробнее говорится в разборе когнитивной ловушки при использовании AI-агентов.
Доверие строится на трех свойствах процесса:
- Наблюдаемость. Разработчик видит команды, измененные файлы, вывод тестов и причины повторных попыток.
- Проверяемость. Результат можно оценить автоматическим тестом или формальным правилом.
- Ограниченность полномочий. Агент получает ровно те инструменты и доступы, которые нужны для конкретной задачи.
В описываемом подходе Cursor эти свойства соединяются в один цикл: агент изучает контекст, вносит изменение, запускает проверку, анализирует результат и корректирует код. Человек контролирует границы задачи и принимает итоговый diff, а не подтверждает каждую строку вручную.
Локальная верификация: запуск кода в реальной среде
Первый контур доверия появляется в момент, когда агент получает обратную связь от исполняемой системы. Текстовый ответ модели может выглядеть логично и при этом не учитывать версию библиотеки, переменные окружения, схему базы данных или фактический формат ответа API. Запуск кода быстро превращает такие предположения в наблюдаемый результат.
Запуск кода как проверка на реальность
Локальная верификация означает, что агент работает с доступной ему средой разработки: запускает тесты, вызывает отдельную команду, проверяет сборку или воспроизводит конкретный сценарий. Безопасный вариант предполагает песочницу, ограниченные права, тестовые данные и запрет на случайную запись в production-системы.
Пример цикла выглядит так:
- Агент добавляет функцию валидации входных данных.
- Запускает юнит-тесты и получает ошибку на пустом значении.
- Проверяет трассу вызова и находит место, где исключение перехватывается слишком рано.
- Исправляет код и повторяет тесты.
Каждый шаг оставляет артефакт: diff, команду, вывод процесса или отчет о тестировании. Эти артефакты помогают отличить исправление причины от маскировки симптома. В практическом ревью кода AI-агента полезно проверять именно такой набор: план, diff, конфигурацию, тесты и runtime-сценарий. Полный алгоритм разобран в статье о проверке кода AI-агента.
Запуск не отменяет ручное ревью. Тесты могут не покрывать редкий сценарий, а агент способен написать тест, который подтверждает ошибочное поведение. Задача локальной проверки состоит в том, чтобы уменьшить число неизвестных до обсуждения архитектуры и мерджа.
Трейсинг для понимания решений агента
Трейсинг фиксирует последовательность действий агента: какой файл он открыл, какой инструмент вызвал, какой результат получил, почему выбрал следующий шаг и где повторил попытку. Для сложной задачи такой журнал полезнее финального сообщения с фразой «готово».
Минимальная запись трассы должна позволять ответить на четыре вопроса:
- какой запрос и ограничения получил агент;
- какие участки кодовой базы он использовал;
- какие команды и проверки выполнил;
- на каком основании изменил решение после ошибки.
Трейсинг помогает воспроизводить сбои. Если агент каждый раз выбирает разные файлы или по-разному обрабатывает одинаковый сценарий, команда видит вариативность поведения и может вынести операцию в отдельный навык с фиксированными входами и проверками.
Навыки для агентов и feature map: навигация по кодовой базе
Даже сильная модель теряет надежность, когда каждый раз заново угадывает правила проекта. Навыки и feature map снижают объем таких догадок. Первый механизм задает процедуру действия, второй помогает найти связанные файлы, зависимости и точки входа.
Что такое навыки и зачем они нужны
Навык, или skill, представляет собой переиспользуемую процедуру для типовой задачи. В ней можно описать допустимые входные данные, порядок действий, инструменты, ограничения и критерии успешного результата. Примеры: чтение большого файла, генерация шаблонного кода, работа с API, миграция схемы или добавление обработчика ошибок.
Навык уменьшает вариативность. Вместо свободного запроса «добавь endpoint» агент получает последовательность: найти существующий роутер, проверить схему DTO, добавить обработчик, написать тест на ошибочный ввод, запустить линтер и показать diff. Такой формат проще проверять и переносить между задачами.
В похожих системах делегации I/O-heavy операций применяют отдельные режимы для чтения больших файлов и генерации шаблонного кода. Скрипты вызываются с именованными аргументами, а обработка данных выполняется внутри них. Это надежнее, чем заставлять модель собирать длинный shell-пайплайн из текста: границы операции задает исполняемый интерфейс, а не свободная интерпретация инструкции.
Навык не должен превращаться в длинный промпт с десятками пожеланий. Если правило можно выразить тестом, схемой, типом или запретом команды, его лучше выразить техническим механизмом.
Feature map: как агент понимает структуру проекта
Feature map можно представить как индекс возможностей и связей внутри репозитория. Он связывает пользовательскую функцию с модулями, файлами, API, тестами, конфигурацией и зависимостями. Агент получает карту маршрутов по проекту и реже делает выводы на основе одного случайно найденного файла.
Для задачи «добавить экспорт отчета» feature map может показать:
- модуль, где формируется отчет;
- сервис, который отвечает за сериализацию;
- endpoint и схему ответа;
- фоновые задачи и права доступа;
- существующие тесты на формат и лимиты данных.
Карта не заменяет чтение исходников. Она сокращает поиск и помогает агенту увидеть границы изменения. Качество feature map зависит от актуальности индекса: если он не обновился после переименования модуля, агент начнет следовать устаревшим связям. Поэтому карту нужно обновлять вместе с изменениями кодовой базы и проверять отдельными сценариями.
Evals: постоянная проверка навыков после изменений
Evals, сокращение от evaluations, представляют собой набор задач для оценки поведения агента. В отличие от одного ручного эксперимента, evals позволяют повторять одинаковые сценарии после смены модели, обновления навыка, изменения feature map или перестройки репозитория.
Как устроены evals в Cursor
Практический eval состоит из входного запроса, подготовленного контекста, разрешенных инструментов, ожидаемого результата и критериев оценки. В простом случае проверяется факт прохождения тестов. Для сложных задач оцениваются измененные файлы, отсутствие запрещенных операций, качество обработки ошибок и соответствие архитектурным ограничениям.
Набор проверок может включать:
- юнит-тесты для сгенерированной функции;
- интеграционный сценарий с реальной связкой модулей;
- проверку типов и статический анализ;
- проверку формата diff и списка измененных файлов;
- ручную оценку небольшой выборки ответов по заранее заданной шкале.
Для каждого eval нужен порог. Например, критический навык может требовать прохождения всех обязательных тестов и отсутствия запрещенных изменений. Для исследовательской задачи допустим частичный результат, если агент корректно сообщает о недостающем контексте и не выдает догадку за факт.
Предотвращение деградации навыков
Навык способен ухудшиться после обновления модели, изменения формата инструментов или перестройки проекта. Внешне это часто выглядит как случайная нестабильность: вчера агент находил правильный сервис, сегодня меняет похожий, но устаревший модуль.
Evals превращают такую проблему в измеряемый сигнал. Команда хранит сценарии, запускает их регулярно и сравнивает результаты с базовой линией. Если навык раньше проходил 9 из 10 сценариев, а после изменения проходит 6, обновление нельзя считать нейтральным, даже если несколько удачных демонстраций выглядят впечатляюще.
Проверки полезно разделять по риску:
- smoke-evals быстро проверяют базовый вызов навыка;
- регрессионные сценарии покрывают уже найденные ошибки;
- контрактные проверки контролируют формат входов и выходов;
- нагрузочные сценарии показывают, не ломается ли навык на больших файлах или длинном контексте.
Такой набор снижает зависимость качества от единичного ответа модели. Он не доказывает абсолютную надежность, но показывает, где поведение изменилось и какой риск нужно разобрать.
Почему автоматические проверки лучше текстовых правил
Текстовая инструкция полезна для постановки задачи, но плохо подходит на роль единственного ограничителя. Модель может неверно истолковать формулировку, забыть ее после длинной цепочки действий или выбрать локально удобное решение, которое нарушает правило проекта.
Ограничения текстовых правил
Фраза «не меняй публичный API» оставляет несколько вопросов: что считать публичным, где хранится контракт, как проверить обратную совместимость и кто остановит агента при нарушении. Если правило не связано с исполняемой проверкой, его соблюдение зависит от внимания модели и человека.
Текстовые инструкции подходят для пояснения намерений, архитектурного контекста и приоритетов. Формальные ограничения лучше закреплять в коде и инструментах:
- проверку типов для совместимости интерфейсов;
- линтер для запрещенных конструкций;
- тесты для поведения API;
- политику доступа для опасных команд;
- проверку списка измененных файлов для контроля области задачи.
Так разработчик оценивает результат по фактам. Агент может написать убедительное объяснение, но не может заменить зеленый тест или пройти проверку типов словами.
Статический анализ и строгий CI как гарантия
Статический анализ проверяет код без запуска всей системы. Он выявляет ошибки типов, недостижимые ветки, подозрительные конструкции, нарушения стиля и некоторые уязвимости. Линтер и форматтер уменьшают шум в diff, поэтому ревьюеру проще сосредоточиться на логике.
Строгий CI связывает эти проверки с процессом мерджа. Типичная последовательность выглядит так:
- форматирование и проверка структуры файлов;
- линтинг и статический анализ;
- проверка типов;
- юнит-тесты;
- интеграционные тесты для затронутых компонентов;
- проверка политики безопасности и зависимостей.
Красный статус блокирует мердж, пока причина не устранена или явно не согласовано исключение. Это особенно полезно при работе с агентом: CI становится независимым арбитром, который оценивает каждый diff одинаковыми правилами.
Жесткие проверки не должны создавать ложное чувство безопасности. Тесты покрывают только известные сценарии, статический анализ видит ограниченный класс проблем, а CI не оценивает всю архитектурную целостность. Поэтому ручное ревью сохраняется для решений с большим blast radius, изменений схемы данных, прав доступа и публичных контрактов.
Риски: когда агенты ускоряют, но размывают качество
Главный риск возникает при измерении производительности числом сгенерированных строк. Агент может закрыть десять задач и увеличить объем кода, который команда не понимает, не тестирует и не хочет поддерживать.
Типовые симптомы видны в diff:
- одна и та же логика размножена в нескольких сервисах;
- простая операция обернута несколькими слоями абстракций;
- обработка ошибок возвращает разные форматы в соседних модулях;
- новый код обходится вокруг существующей архитектуры;
- тесты проверяют внутреннюю реализацию и мешают последующим изменениям.
Риск повышается, когда агент получает широкий доступ к репозиторию и может сам выбирать масштаб задачи. Без feature map он ищет локально подходящий файл. Без навыков повторяет одну и ту же процедуру по-разному. Без evals команда замечает деградацию только после нескольких неудачных задач.
Человеческий контроль тоже имеет предел. Если разработчик подтверждает каждое действие, поток работы превращается в очередь разрешений и появляется усталость от ревью. Если подтверждается только финальный результат, ошибки обнаруживаются поздно. Поэтому контроль нужно привязывать к риску: рутинные операции проходят автоматические гейты, опасные изменения требуют отдельного одобрения.
Граница авторства и ответственности остается у команды. Передача задачи агенту не переносит ответственность за безопасность, совместимость и поддержку кода. Разработчикам, которые воспринимают программирование как инженерную практику с личной ответственностью за результат, полезен отдельный разбор причин сопротивления передаче кода AI-агентам.
Как перейти от экспериментов к воспроизводимому процессу
Команде не требуется копировать весь подход Cursor за один этап. Надежнее выбрать один повторяемый сценарий с ограниченным риском и измерить его до расширения полномочий агента.
Стартовый набор практик
- Определите одну задачу, например добавление обработчика или написание тестов.
- Разрешите агенту работать в изолированной среде с тестовыми данными.
- Включите запись команд, вывода и измененных файлов.
- Оформите повторяемую процедуру как навык с четкими входами и выходами.
- Создайте 5-10 eval-сценариев, включая ошибочные входные данные и пустой контекст.
- Добавьте в CI форматтер, линтер, проверку типов и обязательные тесты.
- Задайте правила эскалации для изменений базы данных, прав доступа и публичных API.
Первый результат процесса должен быть измеримым. Например, команда фиксирует, сколько задач проходит eval с первой попытки, сколько ошибок обнаруживает CI и сколько времени занимает ручное ревью. Пороговые значения корректируют после накопления собственных данных, поскольку одинаковые цифры плохо подходят для библиотеки, внутреннего сервиса и критической платежной системы.
Метрики качества для агентов
Процент AI-кода мало говорит о надежности процесса. Полезнее смотреть на показатели, связанные с поведением агента и стоимостью исправлений.
| Метрика | Что показывает |
|---|---|
| Доля успешно пройденных evals | Стабильность навыка на заранее известных сценариях |
| Ошибки, найденные CI до мерджа | Насколько автоматические гейты ловят типовые дефекты |
| Повторные попытки агента | Сложность задачи и устойчивость поведения |
| Время ручного ревью | Реальную нагрузку на разработчика |
| Время исправления после мерджа | Стоимость пропущенных проблем |
| Доля изменений вне заявленной области | Насколько хорошо агент соблюдает границы задачи |
Полезно хранить не только успешные случаи, но и провалы: неправильный выбор файла, пропущенный тест, лишнюю команду, неверную обработку исключения. Каждый такой случай может стать новым eval или правилом CI.
Для процессов с несколькими ролями отдельные рекомендации по разграничению действий и человеческой проверке собраны в материале о корпоративных AI-агентах. А кейс с контекстной инфраструктурой показывает, почему полезность агента зависит от качества знаний о системе, а не только от выбранной модели: разбор агента для аналитиков.
Практическая формула выглядит так: локальный запуск дает обратную связь, трейсинг делает действия видимыми, навыки задают повторяемые процедуры, feature map сокращает ошибки навигации, evals ловят регрессии, а CI не пропускает дефекты в основную ветку. Сочетание этих механизмов превращает AI-агента в управляемый инженерный инструмент. Уровень доверия растет вместе с количеством проверяемых свидетельств, а не с объемом обещаний модели.