Рост активаций лицензий на ИИ-сервисы и счета за токены еще не означает, что команда действительно перестроила разработку. Как пишет The New Stack, именно здесь сейчас и проходит главный разрыв: внедрение ИИ в отчетах выглядит бодро, а в ежедневной работе инженеров эффект нередко куда скромнее. Для русскоязычной IT-аудитории это не спор о терминах, а вопрос бюджета, скорости релизов и того, за что компания вообще платит.
Автор материала Harshal Shah описывает очень узнаваемую для engineering-руководителей картину. Почти у каждой организации, с которой он общался, есть свой красивый график: активированных мест становится больше, потребление токенов растет, пилот считается удачным уже потому, что люди вошли в систему и что-то спросили у модели. Это дашборд, который приятно показывать наверх. На уровне C-level это выглядит как зрелость программы, на уровне команды часто лишь как аванс на будущее. Проблема в том, что такой график почти ничего не говорит тимлиду: доступ можно раздать за неделю, лимиты снять за день, а вот превратить ИИ в рабочий инструмент для ревью, тестов, документации, поиска причин инцидента и рутинного рефакторинга заметно сложнее.
Разница между adoption и usage кажется словесной эквилибристикой только до первого бюджета. На практике это разница между закупкой и привычкой. Формальное подключение легко измеряется: сколько лицензий выдали, сколько сотрудников авторизовались, сколько токенов сгорело за месяц. Реальное использование ИИ требует уже неприятных вопросов: какие задачи инженеры закрывают с его помощью регулярно, возвращаются ли к инструменту после первой недели новизны, попадает ли сгенерированный результат в прод, сокращается ли время на рутину, снижается ли нагрузка на ревью и уменьшается ли число повторяющихся ошибок. Считаются ли успехом только запросы к модели или еще и merged pull request, закрытые тикеты и реальные часы, снятые с рутины. Именно на этом этапе красивый rollout обычно перестает быть таким уж красивым.
Логика рынка здесь понятна. На первой волне всем было важнее не отстать, чем аккуратно мерить эффект. Компаниям нужно было быстро выдать доступ, показать команде, что эксперимент разрешен, и не выглядеть последними скептиками на фоне конкурентов. Такая тактика работала, пока ИИ воспринимался как полевая разведка: пусть люди пробуют, а дальше разберемся. Пока стоимость казалась размазанной по экспериментам, разницу между любопытством и устойчивой практикой можно было не замечать. Но когда расходы становятся заметной строкой, а от пилотов начинают ждать влияния на delivery, прежняя модель ломается. Эксперимент без дисциплины удобно запускать, но трудно масштабировать и еще труднее защищать перед финансистами.
Отсюда и нервозность, которую сейчас можно увидеть почти в любой крупной engineering-организации. Руководству удобно смотреть на расход и активации: метрика простая, график идет вверх, можно показать совету директоров, что компания не проспала волну. Командам на местах этого мало. Для них важнее, стало ли быстрее собирать контекст по задаче, писать шаблонный код, разбирать наследие, готовить документацию и доводить изменения до merge без лишних кругов. Поэтому внедрение ИИ уже начинает напоминать старую SaaS-историю: подписка куплена на всех, по-настоящему работает с ней меньшинство, а вопрос о возврате инвестиций возникает позже и обычно в самый неудобный момент.
Для разработчиков вывод довольно приземленный. Один и тот же инструмент может быть ускорителем в руках сильного инженера и дорогим автокомплитом в команде, которая не договорилась, где его вообще можно применять и как проверять результат. Без внятных сценариев, ограничений и критериев качества использование ИИ быстро распадается на три режима: энтузиасты делают через модель почти все, скептики игнорируют ее полностью, остальные открывают сервис от случая к случаю. В такой среде сложно сравнивать результат, еще сложнее учить новичков, и почти невозможно честно ответить бизнесу, почему счет за токены растет быстрее, чем предсказуемость поставки.
Из этого напрашивается более полезный набор метрик, чем голая активация. Считать имеет смысл не только расход, но и повторяемость поведения: в каких ролях и сценариях инструмент используется каждую неделю, сколько времени экономит на типовых операциях, влияет ли на качество итогового артефакта и сохраняется ли польза через месяц, когда проходит эффект новизны. Нужны метрики, которые связывают ИИ не с фактом входа в сервис, а с результатом в процессе. Иначе компания получает идеальную парадную метрику: система открывается часто, а производственный контур меняется едва заметно. Для русскоязычных команд внедрение ИИ без такого слоя измерения особенно рискованно: лишний бюджет сейчас редко лежит без дела, а объяснять его одной только модной терминологией получается лишь до первого квартального разбора.
Главный вопрос для engineering-руководителей теперь звучит не так: сколько сотрудников получили доступ к очередному ИИ-сервису. Важнее другое: какие куски разработки модель действительно взяла на себя, где она ускорила цикл, а где просто разогнала счетчик токенов. Чем раньше отрасль перестанет путать внедрение ИИ с его полезным и регулярным использованием, тем меньше будет дорогих пилотов, которыми потом неловко хвастаться даже на внутреннем собрании.