Команда подключила AI‑инструменты. Ими пользуются 70% разработчиков, количество созданного кода выросло, задачи в редакторе выполняются быстрее. Но это ещё не означает, что бизнес начал быстрее получать работающий результат. Объём кода — слабая метрика. Его можно увеличить одновременно с количеством ревью, переделок и инцидентов. Число пользователей AI тоже показывает внедрение инструмента, но не его пользу. Я бы смотрел на весь путь изменения — от постановки задачи до стабильной работы в production: • сократился ли lead time; • сколько результата возвращается после ревью; • сколько раз человеку приходится вмешиваться в работу агента; • выросла ли доля откатов и аварийных исправлений; • сколько стоит успешно завершённая задача с учётом моделей и человеческой проверки; • не стало ли больше дефектов, обнаруженных уже пользователями. Отдельно важно разделять сценарии. Генерация тестов, миграция типового кода и изменение критичного платёжного процесса несут совершенно разный риск. Одна средняя цифра эффективности скроет редкие, но дорогие ошибки. Поэтому новый AI‑инструмент полезно вводить как любое инженерное изменение: выбрать типовые задачи, зафиксировать исходные показатели, сравнить результат и только затем расширять применение. AI adoption — это не количество сгенерированного кода. Это способность команды быстрее выпускать полезные изменения без роста стоимости ошибок. А какую метрику вы бы выбрали главной для оценки AI‑инструментов в разработке?