AWS добавила в CloudWatch аналитику ИИ-агентов для кода
20 июля 2026 года AWS представила CloudWatch Coding Agent Insights — набор готовых панелей для наблюдения за использованием ИИ-инструментов разработки. В фокусе не качество отдельного ответа модели, а телеметрия: токены, задержки, вызовы инструментов, запросы к API, подтверждения действий и распределение затрат между командами.
Это не счётчик «сколько кода написал ИИ». AWS предлагает связать сигналы от кодовых агентов с обычными операционными данными CloudWatch, чтобы инженерная команда могла увидеть картину применения, а не только общий счёт от поставщика модели.
Какие данные попадают в панели
Сервис принимает метрики OpenTelemetry. В документации AWS перечислены Claude Code, OpenAI Codex и GitHub Copilot. После того как агент начинает передавать события в ожидаемом формате, в CloudWatch появляются готовые дашборды — создавать их вручную или импортировать шаблоны не требуется.
Показатели можно разрезать по организации, отделу, команде, центру затрат и пользователю. Это пригодится, когда один общий месячный бюджет ничего не объясняет: платформа разработки, команда сопровождения и команда продукта могут использовать агента совершенно по-разному. В исходных метриках есть и расходы, и рабочие сигналы: потребление токенов, время хода, обращения к инструментам, запросы к API и действия, для которых требовалось подтверждение.
У этого подхода есть важная граница. Телеметрия показывает поведение инструмента, а не автоматически доказывает, что релиз стал лучше. Большое число вызовов может означать полезную автоматизацию, а может — запутанный промпт, ошибку интеграции или работу агента над задачей, которую проще было сделать вручную.
Какую проблему пытается решить AWS
Когда ИИ-кодингом пользуются два разработчика, достаточно видеть личный расход и внимательно читать изменения. На десятках или сотнях аккаунтов возникают другие вопросы: кому действительно нужен расширенный доступ, где заканчивается лимит, почему одна команда тратит в несколько раз больше токенов и что происходит с очередью pull request.
Раньше эти данные часто жили в разных местах: расходы — у провайдера модели, скорость поставки — в системе контроля версий, сбои — в мониторинге, а сведения об использовании агента — нигде. Coding Agent Insights не обещает создать единую метрику эффективности, но даёт точку, к которой можно привязать проверяемый эксперимент.
Например, команда может зафиксировать базовый период в две недели: число завершённых задач, среднее время ревью, долю откатов и среднюю стоимость. Затем дать доступ только к одному повторяющемуся сценарию — подготовке тестов или разбору логов. Через тот же срок сравнивают не впечатления, а изменения в этих величинах и число правок после ревью.
Как не превратить панель в рейтинг сотрудников
Самая плохая интерпретация такого дашборда — использовать токены как KPI человека. Разработчик может тратить больше контекста, потому что разбирает старый сервис, проводит расследование инцидента или тщательно проверяет небезопасное изменение. Дешёвый запрос тоже не равен хорошему решению.
Полезнее смотреть на командный уровень и на конкретный сценарий. Для каждого пилота заранее ответьте на четыре вопроса:
- Что именно ускоряем: подготовку теста, миграцию, поиск причины сбоя или рутинную документацию?
- Какая ручная проверка остаётся обязательной?
- Что будет сигналом остановки: рост дефектов, превышение бюджета, утечка данных или увеличение времени ревью?
- Кто имеет право менять лимиты и видеть детальную телеметрию?
Так цифры помогают улучшить процесс, а не создают видимость точного контроля там, где его нет. О том, как выбрать критерии для такого пилота, мы подробно писали в гайде по оценке пользы ИИ-кодинга.
Что важно настроить до сбора событий
Сначала проверьте, не уедут ли в телеметрию чувствительные данные. Логи промптов, названия веток, пути к файлам или параметры команд могут раскрывать внутреннее устройство продукта. OpenTelemetry — это транспорт наблюдаемости, а не разрешение отправлять в него всё подряд. Нужны правила маскирования, срок хранения, доступ по ролям и отдельный владелец набора метрик.
Второй шаг — бюджет. AWS указывает, что стандартная тарификация CloudWatch применяется к приёму метрик OpenTelemetry. Значит, в расчёте пилота нужно учитывать не только стоимость модели, но и объём телеметрии, хранение и запросы к ней. Слишком детальная запись каждого события может сделать наблюдение дороже пользы от него.
Третий — техническая совместимость. В анонсе функция заявлена для коммерческих регионов AWS, кроме Ближнего Востока (ОАЭ), Бахрейна и Израиля (Тель-Авив). Перед включением стоит проверить актуальный регион, способ аутентификации конкретного агента и политику организации: в документации варианты для личного токена и корпоративного SSO различаются.
Что посмотреть в первые семь дней
Не начинайте с большого отчёта руководству. В первую неделю достаточно трёх проверок: дошли ли метрики, не попали ли в них лишние данные и совпадают ли команды с реальной структурой расходов. Затем выберите два-три сигнала, которые помогают принять решение. Это могут быть скачок токенов после изменения промпта, частые отмены действий агента или рост времени ответа на конкретном инструменте.
Если задача — выбрать модель для пилота, полезен наш подборщик моделей, но финальную проверку всё равно проводит команда на собственных репозиториях и тестах. Модель не должна получать безграничные права только потому, что её телеметрия уже отображается в CloudWatch.
Как связать телеметрию с качеством кода
У панели есть слепая зона: она видит события агента, но не знает, сколько дефектов обнаружит ревью. Поэтому к каждому пилоту привяжите небольшой набор независимых сигналов из репозитория. Для задач на тесты это доля принятых pull request без повторного прогона, количество исправлений после ревью и время от первого коммита до зелёного CI. Для расследования сбоя — время до найденной причины, число откатов и повторяемость результата на обезличенной копии лога.
Снимите базовую линию до включения дашборда. Достаточно десяти–пятнадцати похожих задач за обычный период, иначе одна сложная миграция исказит сравнение. Не смешивайте в одной диаграмме разные типы работ: генерация теста и переписывание архитектуры имеют разную цену ошибки. В отчёте рядом с расходом токенов укажите объём задачи и обязательные проверки. Тогда рост затрат можно объяснить сложностью работы, а не объявлять перерасходом без контекста.
Проверяйте причинность осторожно. Если после запуска агента среднее время уменьшилось, это ещё не доказывает эффект CloudWatch или самой модели: команда могла параллельно обновить CI, сократить очередь ревью или выбрать более простые задачи. Используйте чередование сценариев или контрольную группу, а вывод формулируйте узко: «на задачах этого типа при таком режиме снизилось время до первого рабочего теста». Так дашборд остаётся инструментом наблюдения, а не машиной для красивых, но неподтверждённых KPI.
Вывод редакции
Coding Agent Insights решает практичную задачу: делает использование ИИ-агентов наблюдаемой частью инженерной инфраструктуры. Это полезно для лимитов, диагностики и понимания масштаба применения. Но панель не измеряет ценность изменения в репозитории и не заменяет code review, тесты или ответственность автора.
Хороший первый результат — не красивый график, а маленький пилот с понятным бюджетом, ограниченным доступом и заранее записанным критерием успеха. Тогда телеметрия помогает обсуждать инструмент на языке фактов, а не на языке обещаний.