Agent Experience — новый DX

Developer Experience (DX) отвечает на вопрос, насколько удобно людям пользоваться вашими инструментами. Agent Experience задает тот же вопрос применительно к машинам.

Эта страница посвящена ИИ-агентам для написания кода: таким инструментам, как Claude Code, Cursor, и индивидуальным агентным workflow, которые пишут, запускают и итеративно дорабатывают код при разном уровне контроля со стороны человека. Те же принципы применимы везде, где модель взаимодействует с программным обеспечением или инфраструктурой от чьего-либо имени.

Agent Experience — это дисциплина проектирования, а не категория продукта. Она проявляется в API, инструментах командной строки, документации, правах доступа, окружениях, сообщениях об ошибках, логах и системах обратной связи. Большинство этих интерфейсов изначально создавались для людей.

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

Агенты взаимодействуют с теми же системами иначе. Панель управления, спроектированная для визуального сканирования, может предоставлять машине крайне мало пригодной для использования информации. Подробное сообщение об ошибке может помочь разработчику понять контекст, но вынуждает агента тратить токены на то, чтобы отделить сигнал от шума. Интерактивный запрос в командной строке может сделать CLI удобнее для человека, но полностью останавливает автоматизированный workflow.

Проектирование для обеих аудиторий

Agent Experience не заменяет DX. Программные системы все чаще обслуживают обе аудитории.

Разработчик может просматривать pull request в визуальном интерфейсе, пока агент получает то же изменение через API. Разработчик может изучать полный лог сборки, пока агент запрашивает только неудачный шаг и связанную с ним ошибку. Человек может предпочесть управляемый процесс настройки, а агенту нужна неинтерактивная команда с предсказуемым выводом.

Хорошие инструменты предоставляют одни и те же базовые возможности в форме, подходящей для каждой аудитории.

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

Агенты меняют это допущение. Системы контроля версий, инфраструктура сборки, реестры пакетов, облачные платформы, внутренние API и инструменты разработчиков все чаще получают запросы от программ, действующих от чьего-либо имени.

Агенты становятся пользователями программного обеспечения

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

Они читают документацию, вызывают API, выполняют команды, изменяют репозитории, изучают логи, опрашивают инфраструктуру и запускают workflow. Каждый интерфейс на этом пути влияет на то, сможет ли агент надежно выполнить задачу.

Слабый AX превращается в работу для людей

Агенту, которому выдали стену неструктурированного вывода, приходится тратить время и токены на то, чтобы понять, что важно. Неоднозначный ответ API может привести к ненужной повторной попытке или неверному следующему действию. Интерактивный запрос может остановить автоматизированную задачу и вернуть ее человеку.

Проблемы накапливаются на протяжении всего workflow. Небольшая доля неоднозначности на каждом шаге может превратить автономную задачу в череду уточнений, проверок и доработок.

Более совершенные модели не отменяют важность проектирования интерфейсов

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

Более совершенные модели способны эффективнее рассуждать о слабых интерфейсах, но более сильные интерфейсы с самого начала снижают объем рассуждений, который вообще требуется.

Платформенные команды уже проделывают похожую работу для разработчиков, создавая проторенные пути (paved paths) через общую инфраструктуру. Agentic-разработка добавляет еще одного пользователя, для которого нужно проектировать.

Agent Experience — это свойство каждого интерфейса, который агент использует для выполнения задачи.

Для агента, пишущего код, одно-единственное изменение может потребовать чтения документации, обращения к репозиторию, выполнения команд, изменения файлов, вызова внешних инструментов, интерпретации результатов тестов, проверки статуса CI и обновления pull request.

Получение нужного контекста

Агентам нужен доступ к информации в форме, которую они могут предсказуемо получать и интерпретировать.

API выигрывают от стабильных схем и структурированных ответов. Документация выигрывает от точных примеров, четкого версионирования и канонических инструкций. Инструменты CLI выигрывают от машиночитаемых режимов вывода. Описания инструментов выигрывают от точных названий, входных и выходных данных и четких границ.

Такие протоколы, как MCP, делают дизайн интерфейса особенно заметным. Описание инструмента влияет на то, когда агент выбирает этот инструмент и как формирует запрос.

Больший объем доступного контекста не создает более качественный AX автоматически. Это делает релевантный контекст.

Безопасное выполнение действий

Агентам нужны предсказуемые способы изменения системы.

Инструменты командной строки должны поддерживать неинтерактивное выполнение, содержательные коды завершения и операции с четко определенными результатами. Там, где это практически возможно, повторные команды должны быть безопасны или явно показывать дублирующиеся действия.

Права доступа определяют, сколько автономии может получить агент, не увеличивая при этом цену ошибки. Узкие области действия, границы утверждения, изолированные среды и применение политик позволяют агентам выполнять полезную работу, ограничивая непреднамеренные последствия.

Понимание произошедшего

Агенту нужно знать, завершилось ли действие успехом, неудачей или привело к неожиданному состоянию.

Машиночитаемый статус, конкретные ошибки, структурированные логи и явное состояние облегчают определение следующего шага. Полезная ошибка сообщает агенту, что именно не удалось, где произошел сбой и что ожидала система.

Полные детали должны оставаться доступными при необходимости. Но они не обязаны быть ответом по умолчанию.

Поиск состояния и истории

Агентам часто нужна информация, которую разработчик обычно получает, открыв другой интерфейс.

Какой деплой сейчас выполняется? Какой pipeline завершился неудачей? Что изменилось после предыдущей попытки? Завершился ли вызов API? Уже открыт pull request?

Программный доступ к операционному состоянию позволяет агенту отвечать на эти вопросы, не полагаясь на человека, который переводит информацию с дашборда.

Улучшение Agent Experience редко требует перестройки всей платформы вокруг ИИ. Многие из самых ценных изменений всего лишь делают существующие интерфейсы более явными, структурированными и предсказуемыми.

1. Возвращайте структурированную информацию

Предоставляйте машиночитаемый вывод для workflow, которые агент будет использовать многократно.

Для CLI это может означать вывод в формате JSON по задокументированной схеме. Для API — стабильные типы ответов и явные состояния ошибок. Для документации — примеры, которые агент может выполнить, не восстанавливая недостающие предположения самостоятельно.

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

2. Отбирайте контекст на уровне источника

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

Если не прошли три теста, укажите именно эти три сбоя и приведите релевантные детали, вместо того чтобы выводить тысячи строк не относящегося к делу вывода. Если операция завершилась ошибкой из-за недопустимого параметра, прямо укажите этот параметр и ожидаемое значение.

Фильтрация на уровне источника снижает расход токенов и сужает число правдоподобных интерпретаций, которые приходится рассматривать агенту.

3. Делайте действия предсказуемыми и повторяемыми

Агентные workflow часто повторяют операции, разветвляются на альтернативные подходы и возвращаются к предыдущим шагам.

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

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

4. Относитесь к задержке как к части интерфейса

Обратная связь наиболее полезна, пока агент всё ещё работает над задачей, которая её породила.

Допустимая задержка зависит от workflow. Локальная проверка синтаксиса может требовать почти мгновенного ответа. Полный интеграционный тест может занимать больше времени. Развёртывание может по своей природе требовать нескольких минут.

Важный вопрос — соответствует ли эта задержка тому решению, которое агенту предстоит принять дальше.

5. Измеряйте результаты работы агента

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

Полезные сигналы AX могут включать:

• Как часто первая попытка завершается успешно
• Сколько повторов или вызовов инструментов требует задача
• Сколько времени или бюджета на вывод модели требуется для получения решения
• Как часто требуется вмешательство человека
• Какие инструменты или интерфейсы чаще всего предшествуют неудачным попыткам

Когда повторяющийся сбой указывает на проблему интерфейса, устраните её и сохраните этот случай как регрессионный eval. Запускайте такие evals в CI вместе с тестами для контрактов, ориентированных на агентов: схем API, определений инструментов, структурированного вывода, кодов выхода и границ прав доступа.

Базовый уровень позволяет отличить реальное улучшение AX от изменения, которое просто выглядит аккуратнее для человека-рецензента.

Начните с повторяющихся сбоев

Выберите задачу, которую ваши агенты выполняют часто, и изучите неудачные попытки от начала до конца.

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

Самые полезные улучшения AX часто начинаются со знакомого программного интерфейса, а не внутри самой модели. Устранив повторяющийся сбой, добавьте его в свой набор evals, чтобы позже отслеживать регрессии.

ИИ-агенты недетерминированы. Две попытки решить одну и ту же задачу могут привести к разным цепочкам рассуждений, последовательностям вызова инструментов и решениям.

Дизайн интерфейса может как увеличивать, так и уменьшать степень вариативности, которую порождают эти различия.

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

Второй вариант интерфейса не делает модель детерминированной. Он лишь снижает ненужную неоднозначность.

Точные описания инструментов сужают выбор инструмента. Стабильные схемы уменьшают простор для интерпретаций. Явное состояние снижает количество догадок. Чётко определённые границы прав доступа ограничивают доступные действия.

Хороший AX проектирует окружающую систему так, чтобы у вариативности модели оставалось меньше пространства превратиться в неправильное или дорогостоящее поведение.

Описанные выше принципы применимы ко всему программному стеку. CircleCI фокусируется на одной конкретной части Agent Experience: на том, как агенты получают полезную обратную связь по валидации в процессе разработки ПО, и на том, как команды независимо проверяют изменения, созданные агентами, прежде чем эти изменения попадут в продакшн.

Генерация кода становится быстрее и дешевле. При этом каждое дополнительное изменение по-прежнему требует подтверждения того, что оно соответствует стандартам, необходимым для слияния и развёртывания.

Подход CircleCI связывает быструю обратную связь внутри рабочего цикла агента с независимой проверкой в CI.

Агент для написания кода может быстро создать правдоподобное изменение. Оценка этого изменения может потребовать значительно больше усилий.

Пройденный тест даёт полезное свидетельство, но говорит лишь о том, что выполненные проверки прошли успешно. Изменение может удовлетворять одному тесту и при этом вносить регрессию в другом месте, решать не ту задачу или не соответствовать другому требованию, которое не покрывает текущий набор тестов.

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

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

CI даёт независимое место для сбора и применения этих доказательств.

Агентная разработка программного обеспечения охватывает два цикла обратной связи.

Внутренний цикл

Внутренний цикл — это то, что происходит, пока агент активно работает над изменением:

написание → запуск → проверка → исправление → повтор

У агента всё ещё есть в активном контексте проблема, реализация и результаты последних запусков инструментов. Быстрая проверка на этом этапе помогает выявить проблемы до push или pull request.

Внешний цикл

Внешний цикл начинается, когда изменение попадает в общую инфраструктуру доставки.

Он может включать CI/CD-конвейер, интеграционные и системные тесты, проверки безопасности, ревью, развёртывание и верификацию после развёртывания.

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

Объединение циклов

Сильный Agent Experience обеспечивает постоянный поток полезной обратной связи между циклами.

Сбой, обнаруженный во внутреннем цикле, часто можно исправить сразу, пока у агента ещё есть весь рабочий контекст. Сбой, найденный CI, должен возвращаться к агенту с достаточным объёмом структурированной информации, чтобы продолжить задачу, не разбираясь заново во всей проблеме.

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

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

1. Проверка уровня CI во внутреннем цикле

Chunk sidecars выполняют целевую проверку затронутого кода в изолированной среде до push.

Агент может проверять изменения в рабочей директории, пока реализация ещё в контексте, не дожидаясь полного цикла CI. Sidecars спроектированы так, чтобы возвращать обратную связь уровня CI менее чем за минуту для проверок, которые относятся к внутреннему циклу.

Быстрая проверка во внутреннем цикле выявляет простые проблемы ближе к месту их появления и оставляет внешнему циклу возможность сосредоточиться на более глубоких общих проверках.

2. Более точная проверка во внешнем цикле

Smarter Testing использует анализ влияния тестов, чтобы запускать только тесты, затронутые изменением, интеллектуально распределяет выполнение тестов по доступным вычислительным ресурсам и может повторно запускать сбойные тесты, чтобы выявить нестабильные (flaky) тесты.

Агентная разработка может увеличивать число изменений и циклов проверки, проходящих через CI. Быстрый запуск наиболее релевантных тестов помогает сохранять полезность обратной связи по мере роста объёма.

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

3. Возвращение сбоев внешнего цикла обратно в контекст

Сбой CI наиболее полезен агенту, когда соответствующая информация может вернуться прямо в его рабочую среду.

CircleCI CLI поддерживает флаг --failure-report, который сводит сбойную задачу к информации, необходимой агенту для диагностики, без предварительного разбора полного лога.

CircleCI также поддерживает Fix with Claude Code — функцию, которая отправляет структурированную сводку о сбое из неудачного запуска CircleCI обратно в Claude Code в терминале.

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

4. Прямой доступ агентов к CircleCI

CircleCI CLI предоставляет машинно-ориентированный интерфейс к CircleCI со структурированным JSON-выводом, отчётами о сбоях, операциями с пайплайнами и инструментами развёртывания.

CircleCI MCP-сервер напрямую предоставляет инструменты CircleCI агентам, совместимым с MCP. Агенты могут получать статус пайплайна, изучать сбои и результаты тестов, перезапускать workflow, запускать пайплайны и выполнять другие поддерживаемые операции без необходимости, чтобы разработчик вручную передавал информацию между системами.

Для новых проектов circleci onboard может проанализировать репозиторий, сгенерировать стартовый конфиг CircleCI и подключить проект к CircleCI.

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

Хороший Agent Experience начинается с того, что вы относитесь к агентам как к пользователям своего продукта. Дайте им релевантный контекст, предсказуемые способы действовать, явное состояние системы и обратную связь, которая делает понятным следующее решение.

Начните с одного часто используемого workflow и сделайте его полностью пригодным для агента, от начала до конца. Многократно тестируйте типичные задачи и превращайте повторяющиеся сбои в конкретные улучшения интерфейса. Оценки поведения агентов и контрактные тесты могут стать частью вашего цикла обратной связи CI, помогая выявлять регрессии AX по мере изменения продукта.

С CircleCI AX может распространяться и на сам рабочий процесс доставки. Агенты для написания кода могут получать доступ к структурированному выводу CLI и инструментам MCP, проверять изменения во внутреннем цикле и получать более точную обратную связь от CI во внешнем цикле, чтобы продолжать работу без необходимости, чтобы разработчик интерпретировал результаты за них.

Встройте AX в свой продукт, а затем постоянно тестируйте и улучшайте его.