Почему интервью технического директора о провалившемся внедрении ИИ-ассистентов стало триггером для команд разработки?

Итоги интервью: ключевые тезисы и что они значат для рынка.

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

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Технический директор публично признал, что внедрение ИИ-ассистентов провалилось, и это интервью разошлось по командам быстрее, чем любой вендорский кейс об успехе.

Дальше начинается интересное. Формально в интервью нет ничего сенсационного: взрослая компания, продуктовый стек, купленные лицензии, пилот, отсутствие эффекта. Такие истории случаются каждый квартал. Но конкретно эта сработала как триггер, потому что её обсуждали не аналитики рынка, а инженерные руководители в закрытых чатах. Узнавание оказалось сильнее аргумента.

Сразу оговорка про первоисточник, иначе получится пересказ слухов. Речь о публичном интервью технического директора продуктовой компании (стек — типовой для SMB: несколько сервисов, CI, код-ревью, поддержка в том же контуре). Дословные формулировки смотрите в самом интервью. Ниже — тезисы, которые из него вынесли команды, с разбором: что за ними стоит и что с этим делать в своей компании. Цитаты даю как пересказ позиции, а не как дословную стенограмму.

Ключевое, что вынесли тимлиды: инструмент купили под обещание роста производительности, а измерять стали через ощущение. Никто не зафиксировал baseline до старта. Через несколько недель выяснилось, что часть разработчиков открывает ассистента раз в день из вежливости, а senior-ы тратят дополнительное время на ревью сгенерированного кода.

Что именно сказал CTO и почему это отозвалось в командах

Тезисы, которые разошлись по каналам, звучат примерно так (пересказ, не стенограмма):

• «Лицензии купили под ожидание, что скорость вырастет сама». Триггер: почти в каждой команде покупку оформляли до того, как определили сценарии использования.
• «Активность упала, но отчётность продолжала показывать внедрение». Триггер: метрику подменили фактом оплаты счёта, а не фактом работы в инструменте.
• «Разработчики говорили о проблемах внутри команды, но не наверх». Триггер: у тимлида нет канала, где негативный опыт не выглядит как саботаж.
• «Ревью сгенерированного кода никто не пересобирал». Триггер: пайплайн остался прежним, а входные объёмы кода выросли.
• «Решение откатывать принимали через несколько месяцев после того, как всё стало понятно». Триггер: отсутствие заранее назначенной точки решения.

Почему публичность перевесила содержание? Потому что интервью CTO описывает конкретную компанию с похожим размером команды, похожим стеком и похожим этапом зрелости. Отчёт аналитика говорит про рынок в среднем, и его легко отложить. Признание коллеги с сопоставимым контекстом отложить трудно.

Сработал эффект узнавания. Читатель не узнавал себя в абстрактной статистике. Он узнавал свой стендап.

Разрыв между ожиданиями менеджмента и реальностью команд

Как покупают ИИ-ассистента в SMB на 10–200 разработчиков? По демо и по обещаниям вендора. Редко по сценариям. Почти никогда — по заранее описанному способу проверки гипотезы.

На входе команда получает лицензию. Не процесс, не правила ревью, не список задач, где инструмент уместен, и не метрику, по которой её будут оценивать. Дальше каждый разработчик решает сам, как этим пользоваться. Одни генерируют тесты, другие пробуют архитектурные куски, третьи не открывают вообще.

Теперь неприятный вопрос. Почему команда молчит, когда инструмент не работает?

Потому что сказать «купленная вами штука бесполезна» означает поставить под сомнение решение руководителя. Плюс риск: если я единственный, у кого не получилось, проблема во мне. Разработчики редко пишут такое в общий канал. Они просто перестают пользоваться. По факту это тихий отказ, который в отчётности выглядит как «внедрено».

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

И третий слой, самый дорогой. Senior-разработчик на ревью сгенерированного кода тратит время, которое раньше уходило на задачи, где его опыт давал максимум. Это скрытая статья расходов, её нет в счёте от вендора.

Метрики, которые показывают реальную картину внедрения

Есть ориентир, который стоит держать в голове: доля активных пользователей ИИ-ассистента среди купивших лицензии падает до 30–40% через 8 недель после старта пилота. Падение само по себе не приговор. Приговор — отсутствие объяснения, почему это произошло.

Что сравнивать корректно? Только сопоставимые вещи. Если пилот шёл на greenfield-задачах, а через 6 недель мерили всю команду вместе с поддержкой инцидентов, вы получили не результат, а среднюю температуру по отделу. Сравнивайте группу задач с группой задач.

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

Сценарии, где ИИ-ассистент работает и где ломается

Ориентир из практики: 20–30% задач в команде реально выигрывают от ассистента после разделения сценариев. Не 80. Это не малость, это нормальная доля. Проблема начинается, когда эту долю пытаются растянуть на весь бэклог.

Работает

• Тесты. Цена ошибки низкая, критерий приёмки однозначный: тест зелёный или красный.
• Документация и описания API. Проверяемо глазами, откат дешёвый.
• Типовые миграции и boilerplate. Шаблонная работа с понятным результатом.
• Разбор незнакомого кода перед задачей. Ускоряет вход, не создаёт артефактов в проде.

Ломается

• Архитектурные решения. Ассистент выдаёт правдоподобный вариант, но не несёт ответственности за связность системы.
• Платежи и биллинг. Ошибка стоит денег клиента и репутации, проверка дороже, чем написать самому.
• Безопасность и доступы. Сгенерированный код здесь требует отдельного threat-моделирования, а не обычного ревью.
• Легаси без тестов. Ассистент усиливает хаос: он уверенно дописывает код в систему, где никто не знает, что считается правильным поведением. Сначала тесты, потом генерация.

Практический вывод простой. Разделите сценарии до пилота, а не после. Иначе вы получите смешанный результат, из которого нельзя извлечь ни одного решения.

Как перестроить внедрение после провала

Порядок действий, который выдерживает контакт с реальностью. Никакой магии, только последовательность.

1. Аудит использования за 4–8 недель. Сначала смотрите на активных пользователей и на то, какие задачи они закрывают ассистентом. Не на количество выданных лицензий.
2. Разделение сценариев на группы. Greenfield, легаси-рефакторинг, поддержка и инциденты. Для каждой группы — свой набор ожиданий.
3. Baseline по DORA до старта. Если baseline не зафиксирован, первое, что вы делаете, — фиксируете текущее состояние и стартуете заново на одной команде.
4. Правило ревью. Ассистент не заменяет ревью. Сгенерированный код проходит тот же пайплайн, что и написанный человеком: те же проверки, те же ревьюеры, та же категоризация причин отказа.
5. Обратная связь раз в две недели. Три вопроса: где помогло, где добавило работы, что убрать. Анонимно, иначе получите вежливость вместо данных.
6. Точка решения через 8–12 недель. Масштабировать, менять сценарии или откатывать. Назначьте её заранее, до старта, и зафиксируйте, кто принимает решение.

Отдельно про пересмотр KPI с руководством. Пока KPI звучит как «внедрить ассистента», команда будет имитировать использование. Пока KPI звучит как «сократить время на ревью и не уронить долю неуспешных изменений», появляется содержательная работа.

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

Когда это не сработает

Подход не сработает, если в компании нет культуры измерений. Тогда любой замер превращается в политический инструмент, а данные подгоняются под уже озвученное решение.

Второй случай: разработчики не готовы давать обратную связь. Причины разные — от недоверия к руководству до банальной усталости от опрос