Статья - сокращенный вариант от оригинала рассылки The Human Loop.

AI уже вошёл в работу IT- команд. Доступы выдали, обучение провели, демо показали, и как будто активность в инструментах растёт. А Lead Time (время от взятия обязательств до прода), Throughput (сколько работы команда делает) меняются гораздо медленнее. Иногда не меняются вообще.

Сопротивление AI в такой ситуации полезно читать как диагностику системы. Оно показывает место, где команда ещё не договорилась: про цель, инструмент, ответственность, безопасность или поток работы.

Внедрение легко перепутать с активностью

Когда компания вкладывается в AI, руководству хочется увидеть эффект. Самый простой способ показать прогресс — считать доступы, обучение, входы в инструмент, задачи с пометкой «сделано с помощью AI» и демо.

Эти метрики нужны: они показывают, что люди “потрогали” с инструмент. Проблема начинается, когда их принимают за результат. Частота входов в ассистента сама по себе не говорит, стала ли быстрее доставка изменений до пользователя.

В большом инженерном контуре я несколько раз видел один и тот же сценарий: метрики внедрения растут, а Lead Time, Throughput, Code Review Time и количество дефектов почти не меняются.

Я предпочитаю использовать метрику внедрения - пользуются ли люди кодинг-агентами хотя бы половину дней в месяц + интенсивность обращения к LLM. И на верхнем уровне выглядит что внедрение AI активно идет. А вот внутри могут быть разные истории: кто-то встроил ассистента в обычный рабочий день, кто-то тихо пользуется личной подпиской, кто-то открывает инструмент перед демо, кто-то спорит о том, кто отвечает за изменение, если агент предложил решение, человек принял его в работу, релиз упал, а клиент пришёл злой.

Метрики внедрения могут расти быстрее, чем способность организации безопасно работать с AI.

«Команда сопротивляется» — слишком грубое объяснение

Фраза «сопротивление AI» часто звучит так, будто проблема в людях. Они якобы не хотят меняться, боятся нового или саботируют инициативу.

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

Разработчики часто ругаются что «AI пишет мусор»? 

Это может быть:

• недостаток навыка работы с инструментом. 

• слабый корпоративный ассистент, который работает хуже личной подписки.

На code review специалист говорит «Я не буду отвечать за код агента». 

Это нормальный инженерный вопрос. 

• Кто владеет результатом? 

• Какие проверки обязательны? 

• Что должно попасть в pull request? 

• Где человек принимает финальное решение?

Тимлид отмахивается: «У нас нет времени разбираться». 

• Часто команда уже перегружена, а AI добавляет ещё один слой работы: промпты, проверку результата, новые договорённости, обсуждение безопасности.

Ну и классика жанра: «Нас просто заставляют пользоваться AI». 

• Это может быть сигналом, что команда видит кампанию по внедрению, а не улучшение своей работы.

Если на все эти ситуации ответить одинаково — «проведём обучение» — проблема не решится. Обучение помогает, когда не хватает навыка и практики. Оно не чинит неэффективный инструмент, неясную ответственность и перегруженный процесс.

Сопротивление лучше читать как карту причин. Оно показывает, какая часть системы работы ещё не подготовлена для AI.

Скептик, ритуальный пользователь и саботажник — разные люди

Источник сопротивления и поведение человека — разные вещи.

Один и тот же источник, например отсутствие правил, у разных людей проявляется по-разному:

• Конструктивный скептик поднимает вопрос ответственности за качество. 

• Ритуальный пользователь формально открывает инструмент ради отчёта. 

• Сторонник AI может создавать риск, обходя правила безопасности из лучших побуждений.

Для диагностики полезно различать несколько позиций.

1. Сторонник - экспериментирует и помогает другим. Его энергия полезна, если ограничить эксперименты правилами безопасности.

2. Конструктивный скептик поднимает реальные риски: качество, безопасность, владение результатом, деградацию навыков. С ним нужно переводить риски в критерии ревью, чеклисты и проверочные эксперименты.

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

4. Ритуальный пользователь показывает активность без изменения работы. С ним разговор нужно переводить с факта использования AI на рабочий результат.

5. Саботажник срывает договорённости, скрывает информацию или недобросовестно дискредитирует изменение. Здесь нужны явные ожидания, границы и последствия.

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

Инженерный слой: кто владеет результатом

В разработке вопрос ответственности проявляется быстрее всего.

Ассистент помогает быстрее получить первый вариант решения и это транслируется в реальное локальное ускорение.

Потом изменение попадает на валидацию:

• Ревьюеру нужно понять diff, но часто автор изменений теперь не его коллега, привычки и характер которого он знает. Чтобы понять контекст diff’a - ревьюеру часто приходится восстанавливать, какой запрос получил агент, какие файлы он видел, какие ограничения ему задали, какие предположения он сделал и где человек действительно принял решение. И много итераций учить систему писать корректные PR, постепенно поднимая оценку в бенчмарке.

Если этого контекста нет, ревью превращается в расследование чужого диалога с ассистентом. Скорость генерации кода переезжает во время проверки.

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

1. какие типы задач можно делегировать AI

2. где человек обязан проверить результат и принять решение;

3. какие доказательства проверки должны быть в pull request;

4. кто отвечает за результат после релиза;

5. какие проверки обязательны перед слиянием;

6. какие данные и контексты нельзя отдавать инструменту.

Базовое правило простое: человек, который использовал AI и принял изменение в работу, владеет итоговым результатом. Агент может предложить код, тест или текст. Ответственность за результат остаётся у человека и команды.

Без этой договорённости AI ускоряет генерацию и одновременно увеличивает тревогу за качество результата.

Поток работы: локальная скорость упирается в систему

Даже если одна команда собрала правила работы с AI, локальное ускорение может не изменить общий путь задачи до результата.

У меня был показательный пример: маленькая сквозная команда из двух инженеров и бизнес-эксперта. Внутри этого контура работа действительно пошла быстрее. Команда выпускала больше изменений, а время от начала работы до готового изменения сократилось примерно в полтора раза.

Сквозная доставка не ускорилась пропорционально.

Соседние команды, проверки, релизные правила и бизнес-валидация продолжали жить в прежнем темпе. Команда быстрее делала свою часть, затем ждала, пока смежники проведут изменения у себя.

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

Перед масштабированием AI полезно ответить на вопрос: где в нашем сквозном процессе узкое место?

Если ответ — ревью, безопасность, релиз или смежные команды, интеграция yet another ассистента не сократит Time to Market. Сначала нужно менять маршрут задачи: правила передачи контекста, очередь ревью, автоматические проверки, релизный контур, зависимости между командами.

Что делать с сопротивлением

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

Я бы проверял шесть вещей.

• Цель и метрики. Команда понимает, какую рабочую проблему должен решить AI? Это про скорость написания кода, качество тестов, разбор легаси, документацию, снижение нагрузки на поддержку, стоимость операции, SLA?

• Страх за роль и рост. Люди понимают, как AI меняет ожидания от их роли? Есть ли безопасный путь обучения, где можно выглядеть новичком и не получить за это минус в репутацию?

• Умение и инструмент. Инструмент помогает на реальных задачах команды? Хватает ли ему контекста? Есть ли практика на рабочем бэклоге, а не только демо на игрушечном примере?

• Среда и правила. Официальный путь работы с AI проще и безопаснее обходных вариантов? Понятно ли, какие инструменты разрешены, какие данные нельзя отправлять, что логируется и кто принимает исключения?

• Ответственность. Понятно ли, кто отвечает за результат, если в работе участвовал агент? Есть ли правила ревью, владения результатом и финальной проверки?

• Поток. Локальное ускорение меняет весь путь задачи до результата? Где после AI появляется очередь: ревью, безопасность, релиз, смежные команды или бизнес-валидация?

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

Полная версия статьи с диагностикой, чеклистом и картой сопротивления AI: https://maratkee.com/ru/newsletter/why-teams-resist-ai/

Больше кейсов работы с эффективностью команд и внедрения AI в жизненный цикл разработки можно почитать в моем telegram-канале.