Почему команды сопротивляются AI

Каждый месяц — один вопрос про AI в командах. Как меняются роли, где ломаются процессы и что с этим делать. Это The Human Loop.

Первый выпуск: почему команды сопротивляются AI — и что с этим делать. Карта из шести источников сопротивления, пять позиций людей, кейс E2E-команды, диагностика, чеклист внедрения и рабочий шаблон.

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

Отсюда главный вопрос: почему одна команда превращает его в привычку, другая — в теневую практику, третья — в отчётный ритуал, четвёртая — в конфликт про ответственность?

За тем, что выглядит как сопротивление на поверхности, могут быть размытая цель, страх за роль, слабый инструмент, неявная ответственность или перегруженный поток (здесь и далее, имеется в виду поток задач, которые команда решает в процессе работы над продуктом). И обучение эти проблемы не решит.

За последний год я видел этот сценарий на нескольких десятках инженерных команд. Сначала компания выдаёт доступы, проводит обучение и начинает считать простые сигналы внедрения: кто зашёл в инструмент, кто прошёл курс, кто отметил задачу как сделанную с помощью AI. В отчётах активность растёт. Но метрики доставки (delivery metrics) — Lead Time (время от принятия обязательств до выкатки на прода), Throughput (количество реализованных задач), и более глобальный - Time to Market (время от идеи до прода) — меняются гораздо медленнее (а чаще не меняются вовсе).

Снаружи всё это выглядит как внедрение AI. Внутри я вижу четыре разных сценария:

1. Привычка: ассистент стал частью обычного дня: набросать код, написать тесты, разобраться в легаси.
2. Обходной путь: люди по-тихому пользуются персональными подписками (вместо использования корпоративных ресурсов и моделей), потому что инструменты на работе медленные и “менее умные”.
3. Ритуалы для отчетов: AI-инструментами “фиктивно пользуются” перед демо, чтобы уже отстали со своими отчетами по использованию инструментов
4. Конфликты про роли и ответственность: бесконечные споры: кто отвечает за изменение, если агент предложил → человек принял → релиз упал → а клиент пришёл злой.

Людям, внедряющим AI важно понимать, что происходит с самой работой: где AI становится привычкой, а где — вскрывает старые споры про качество, ответственность и поток. Это видно и в свежих исследованиях BCG (AI at Work — 2026), Microsoft (Work Trend Index — 2026) и LexisNexis (Future of Work Report — 2026).

Прогресс по внедрению AI важно измерять. Но это не самоцель

Когда компания вкладывается в AI, руководству нужно увидеть эффект. Логика понятна: закуплено железо и выстроена инфраструктура, оплачены подписки, сформирован бюджет на обучение — хочется видеть результат и хоть какую-то окупаемость (на самом деле, окупаемости пока нет нигде - и об этом будет отдельный выпуск the human loop).

Самый простой способ увидеть прогресс во внедрении — показать цифры по тому:

• кто получил доступ;
• кто прошёл обучение;
• кто открывал инструмент;
• кто отметил задачу как выполненную с помощью AI;
• кто показал демо.

Prosci предлагает полезное различие: одно дело — активность вокруг инструмента, другое — изменение работы. Доступы, подписки, обучение и частота использования показывают, что люди соприкоснулись с AI. Но внедрение начинается только там, где меняется поведение: инструмент встроился в процесс, люди доверяют результату, понимают правила и видят связь с эффектом для бизнеса.

Когда частота использования становится целью, система быстро учится показывать активность — срабатывает закон Гудхарта: любая метрика, ставшая целью, перестаёт быть хорошей метрикой.

Люди открывают инструмент чаще, ставят в задачах пометку «сделано с помощью AI», показывают пару удачных сценариев на демо — и статистика внедрения AI выглядит всё лучше.

В большом финтехе, где я работаю, это видно на инженерном контуре примерно в 1000 человек (поровну IT и линейного персонала).

• Относительно простые сигналы о формировании привычки растут как положено: больше входов в инструменты, больше участников обучения, больше демо на встречах.
• Метрики доставки (Lead Time, Throughput) либо не сдвигались, либо изменения были несущественны.

При этом с ростом регулярности использования AI растет скрытая работа: по данным Coderabbit - в 1.7 раз чаще обнаруживаются ошибки в PR от агентов, откатов становится больше, доступность сервисов снижается. Платформа инженерной эффективности Harness (в исследовании State of Engineering Excellence — 2026) делится инсайтами: AI ускоряет часть разработки, но увеличиваются очереди и время на проверку, растет скрытая работа. А еще инженеры отмечают повышенную когнитивную нагрузку и страх, что данные про то, насколько активно они используют AI-инструменты попадут в оценку эффективности.

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

Поэтому полезно смотреть на несколько слоёв метрик:

1. Прогресс внедрения AI-инструментов как в привычку людей
2. Прогресс проникновения агентов в SDLC (жизненный цикл разработки ПО),
3. Изменения (в нужную вам сторону) метрик потока,
4. Качество (балансирующие метрики, чтобы вы не только стали быстрее, но и не роняли прод)
5. Затраты на AI.

По моему опыту, в метриках привычки использования AI важны как минимум две метрики: ежемесячная активность (Monthly Active Users), но и доля людей, которые используют AI больше половины рабочих дней (Monthly Active Users 10+ - 10 и более дней в месяц). В потоке — Lead Time (за сколько делаем), Throughput (сколько делаем работы) и Defect Rate (не ломаем ли по пути). В проникновении AI в SDLC — сколько тикетов агенты ведут end-to-end и на скольких задачах участвуют хотя бы на одном этапе. Привычка работать с AI без изменения метрик потока — имитация внедрения.

«Сопротивление AI» — это фасад

«Сопротивление внедрению AI» — это фасад, за которым скрываются разные причины. Prosci (Why Your AI Rollout Stalled — 2026) в своём отчёте перечисляет основные:

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

Я формулирую это чуть проще: люди сопротивляются AI, когда не понимают, зачем это лично им, боятся выглядеть некомпетентными, не знают, как встроить инструмент в реальную задачу, или чувствуют, что решение приняли без них.

63% сложностей AI-внедрения связаны с человеческими факторами, а не с техническими ограничениями. Самый крупный блок сложностей связан с уверенным владением инструментом: тут и недостаток знаний, и непонимание зачем этими инструментами пользоваться (ценность) и недостаточная практика (интеграция в решение рабочих задач).

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

Обучение помогает, когда не хватает навыка и практики. Если проблема в плохом инструменте, нечеткой ответственности или слишком большой количестве работы на проверку (например, Code Review / ADR / ..) — тренинг не починит ни одну из этих причин. Prosci (Why Your AI Rollout Stalled — 2026) и Harness (State of Engineering Excellence — 2026) сходятся в одном: AI-внедрение часто ломается на уровне системы работы вокруг инструмента.

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

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

Инструмент: Карта сопротивления AI / AI Resistance Map

Карта сопротивления AI / AI Resistance Map — рабочий шаблон для команды или нескольких команд. В этом выпуске она помогает перестать спорить с симптомом и увидеть, на что он указывает в системе работы.

Логика простая:

1. определить источник сопротивления;
2. понять позицию человека или группы;
3. выбрать действие, которое чинит реальную причину.

Один и тот же симптом может указывать на разные проблемы

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

В полном шаблоне источники такие:

• цель и метрики,
• страх за роль и рост,
• умение и инструмент,
• среда и правила,
• ответственность,
• поток.

Нам важно увидеть проблему, которая прячется за симптомом (типичными фразами людей):

• “AI пишет мусор” — это сигнал проверить проблемы, связанные с: качеством инструмента, контекстом, навыком постановки задачи или правилами проверки результата.
• “Я не буду отвечать за код агента” — сигнал к проблемам в ответственности: кто владеет результатом, какие доказательства проверки нужны, где человек принимает финальное решение.
• “У нас нет времени разбираться” — сигнал проверить поток работы у команды: есть ли время и ресурсы для первого опыта, не добавляет ли AI ещё один слой работы в уже перегруженную систему.
• “Нас просто заставляют” — сигнал к проблематике смысла и вовлеченности: люди видят кампанию по внедрению, а не улучшение своей работы.

Так карта возвращает нас к четырём историям из начала: первая команда — рабочая привычка, вторая — качество инструмента и среда, третья — метрики и ритуальное использование, четвёртая — ответственность и продуктивный скепсис.

Важно различать скептика, ритуального пользователя и саботажника

Источник сопротивления и поведение человека — разные вещи. Один и тот же источник требует разных действий в зависимости от позиции человека.

Один и тот же источник сопротивления — например, отсутствие правил — у разных людей проявляется по-разному. Скептик поднимает вопрос ответственности за качество. “Ритуальный” пользователь формально открывает инструмент ради отчёта. Сторонник AI может создавать риск, обходя правила безопасности из лучших побуждений.

Для карты сопротивления полезно различать пять позиций:

• сторонник (supporter) — экспериментирует и помогает другим;
• продуктивный скептик (productive skeptic) — поднимает реальные риски и проверяемые вопросы;
• избегающий участник (avoider) — тихо избегает использования и возвращается к старому процессу;
• ритуальный пользователь (ritual adopter) — формально использует AI, чтобы выглядеть соответствующим требованиям;
• активный блокер или саботажник — срывает договорённости, скрывает информацию, блокирует эксперименты или недобросовестно дискредитирует изменение.

Самая важная граница здесь — между продуктивным скепсисом и саботажем.

Скептик может защищать качество, безопасность, владение результатом (ownership) и развитие команды. Когда человек просит прояснить правила проверки, критерии качества и границы ответственности, он часто защищает систему от случайного ущерба. Сейчас начали появляться первые исследования, это подтверждающие: BCG (When Everyone Uses AI — 2026) пишет о риске того, что массовое использование AI в погоне за метриками внедрения ослабляет критические навыки и снижает стабильность поддерживаемых систем. А California Management Review (Upskilling to Accountability — 2026) утверждает, что для стабильной работы систем и корректного внедрения AI-инструментов в работу нужна система ответственности (engineered accountability): критичный взгляд на все результаты работы агентов, а также как минимум два согласования перед отправкой в прод.

То есть скепсис сопротивляющихся нужно переводить в критерии, правила и эксперименты.

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

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

На карте это зона ответственности: кто владеет результатом и кто отвечает за последствия. В разработке AI этот вопрос проявляется быстрее всего.

С AI-ассистентами рутина действительно становится легче: можно быстрее выполнять свой кусочек работы, контролируя агента.

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

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

Qodo (AI Coding Paradox Report — 2026) фиксирует рост инцидентов, вызванных AI-сгенерированным кодом, незаметных багов и провалов в механизмах защиты. Harness (State of Engineering Excellence — 2026) добавляет к картине рост нагрузки на ревью и времени валидации. Поэтому, если разработчики говорят “я лучше сам нормально напишу, вместо того чтобы отдавать это агенту” — это зачастую не страх перед новым инструментом или упрямство.

Часто это запрос на рабочую договорённость:

• какие типы задач можно делегировать AI;
• где человек обязательно проверяет и принимает решение;
• какие доказательства проверки должны быть в pull request;
• кто отвечает за результат после релиза;
• какие проверки обязательны перед merge;
• какие данные и контексты нельзя отдавать инструменту.

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

Даже когда одна команда собрала систему правил работы с AI, проблемы ниже или выше по потоку перечеркивают все локальные достижения. И тут мы отдаляем камеру от локальной работы одной команды ко всей end-2-end цепочке доставки ценности.

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

Проблема в потоке — слой, который почти не виден в цифрах внедрения.

AI может ускорить локальный участок работы, но общий Time to Market останется почти прежним.

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

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

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

Для меня этот пример важен именно тем, что AI внутри контура сработал. Команда стала быстрее. Ограничение оказалось не внутри команды, а на следующем витке цикла разработки: смежные команды, проверки, релизные правила и бизнес-валидация продолжали жить в старом темпе.

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

AI и агентная разработка (agentic engineering) могут радикально ускорить генерацию, тесты и подготовку изменений. Дальше задача проходит через ревью, архитектуру, безопасность, юридическую проверку, релиз, поддержку, бизнес-валидацию, обучение пользователей и управленческие решения.

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

BCG (AI at Work — 2026) формулирует это прямо: стратегия важнее инструментов. Ценность появляется там, где компании перестраивают работу вокруг AI, а не просто раздают доступы. Microsoft (Work Trend Index — 2026) описывает похожий сдвиг: работа пересобирается вокруг людей и агентов, меняются роли Author / Editor / Director / Orchestrator; в блоке Transformation Paradox они отдельно показывают, как давление текущих целей конкурирует с пересборкой работы.

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

Когда таких команд становится не одна, сопротивление перестаёт быть вопросом личной привычки и становится вопросом операционной модели.

Организационный слой

На организационном уровне всё сложнее. Одна команда может договориться. Когда команд несколько — появляется всё сразу: политика, безопасность, бюджеты, страх потери работы и конфликт KPI.

В организациях побольше нужны условия для внедрения AI в работу:

• понятная цель и связь с результатом работы;
• обучение под конкретные роли на реальных задачах;
• бэклог платформы и разработческого опыта (DevEx / platform backlog): убрать барьеры в инструментах;
• правила работы с данными, секретами, политиками безопасности и логированием;
• критерии оценки инструмента, чтобы слабый инструмент не становился стандартом;
• командные договорённости по работе с AI (AI Working Agreement);
• правила ревью и владения результатом;
• метрики эффекта, а не активности: Lead Time, время ревью, стоимость дефектов, нагрузка на поддержку, время до уверенного использования, бизнес-результат.

LexisNexis (Future of Work Report — 2026) фиксирует проблему в правилах работы: использование AI растёт быстрее, чем внутренние политики, обучение и понимание процессов с участием агентов. Отсюда риск: теневое использование AI появляется там, где нет доступных инструментов, понятных правил и собранного контура управления.

Люди чаще обходят процесс не из вредности, а из-за неудобного официального пути.

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

Мы, как управленцы, должны задать себе вопрос: какой кусок комфортной и безопасной среды мы ещё не собрали, раз людям выгоднее идти в обход?

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

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

В диагностике каждый вопрос привязан к одному из шести источников сопротивления. Если команда часто выбирает «Часто» или «Это наша норма», это сигнал для разбора на карте.

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

В докладе по AI на People Sense я пришёл к простой рабочей связке: за каждой формой сопротивления стоит свой тип недостающей поддержки.

• Нет «зачем» → показать личную рабочую пользу. Не общую стратегию компании, а конкретный выигрыш в работе человека: быстрее разобрать легаси, собрать тест-кейсы, подготовить черновик документа или снять рутину с повторяющейся задачи. Пока человек не видит личный смысл, он слушает про трансформацию как про чужой проект.
• Страшно выглядеть некомпетентным → начать с малой безопасной группы. Большие вебинары плохо работают для первого опыта: люди кивают, смотрят демо, а потом остаются одни перед терминалом и не знают, с чего начать.
• Не знают как → дать реальную задачу и эксперта рядом. Лучше сработал формат на 1,5 часа: настройка окружения, задача из рабочего бэклога, участник за рулём, эксперт рядом как штурман. В логике ADKAR это соединяет Knowledge и Ability: человек не только понял инструмент, он впервые применил его в своих условиях.
• «Нас не спросили» → дать людям участвовать в проектировании практики. QA, аналитики, разработчики и DevOps по-разному используют AI и по-разному проверяют качество. Когда роль участвует в создании воркшопа, появляются артефакты, которые можно переиспользовать: шаблоны, правила безопасного использования, примеры задач, критерии проверки, подсказки для агентов.

Короче: сопротивление часто снижается не после убеждения, а после первого безопасного опыта на своей задаче.

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

На практике первый ход должен быть максимально близок к работе. В моих командах лучше всего сработали маленькие рабочие форматы: мини-группы, реальные задачи, эксперт рядом, техлид, который первым показывает пример и регулярный обмен опытом каждый спринт. Так сопротивление превращается из абстрактного «люди не хотят» в конкретный вопрос: какой кусок системы нужно собрать.

А что не работает во внедрении?

Из опыта последнего года я бы вынес то, что выглядит логично, но слабо меняет поведение:

• рассылки и большие вебинары дают осведомлённость, но редко создают привычку;
• реестр инструментов сам по себе не приводит людей к использованию;
• демо «смотрите, как агент круто двигает тикет и пушит в git» вызывает интерес, но не снимает проблему чистого листа;
• требование «используйте AI» быстро превращает внедрение в отчётный ритуал;
• обучение без лидеров не закрепляется в командной норме.

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

Позиция человека меняет способ разговора и роль в изменении.

Логику пересечений я вынес в Карту сопротивления AI: там видно, как источник сопротивления и позиция человека меняют следующий рабочий ход.

Практический артефакт

В практическом формате Карта сопротивления AI превращает диагностику в командные договорённости по работе с AI (AI Working Agreement). Карта работает как вход в эти договорённости: сначала команда видит повторяющиеся проблемы в системе работы, затем переводит их в правила и эксперименты. В минимальной версии шаблон состоит из групп проблематики. На воркшопе команда выбирает 2–3 повторяющихся проблематики и собирает черновик правил:

• что можно делегировать AI;
• где человек обязан оставаться в контуре;
• как работает ревью;
• кто владеет результатом;
• какие данные и контексты разрешены;
• какие проверки нужны перед продакшеном;
• какие метрики показывают эффект в доставке, а не театр использования.

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

Финал

AI быстро проявляет суть того, как в команде устроена работа.

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

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

Практический первый шаг на следующий спринт:

1. Выберите одну повторяющуюся проблему в работе с AI: цель, навык, инструмент, правила, ответственность или поток работы.
2. Опишите, где он проявляется в реальной задаче: что тормозит работу, какой риск создаёт, кому мешает.
3. Превратите проблему в одну проверяемую договорённость или эксперимент.
4. Проведите мини-воркшоп на реальной задаче: участник за рулём, эксперт рядом.
5. Через пару недель-месяц проверьте четыре слоя: появилась ли привычка, изменились ли метрики доставки, не стало ли хуже с точки зрения качества, есть ли связь с результатом.

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