Личные AI-практики почти не масштабируются на команду. Отдельный человек разгоняется, а команда вокруг него остаётся на прежней скорости. У нас в компании мы продвинулись чуть дальше, но по-прежнему в стадии адаптации. Собрал наблюдения в одном месте: почему так происходит и что с этим делают те, у кого получается.
Основные причины торможения на уровне команды
Сопротивление команды: корень проблемы
Внедрение ИИ в коллективе почти всегда наталкивается на сопротивление. Причины повторяются: страх замены, скептицизм из-за прошлого негативного опыта с инструментами, перегрузка текущей работой. Сотрудники боятся, что ИИ сделает их навыки ненужными или, что хуже, обнажит их некомпетентность. В компаниях от 300 человек это выражено сильнее всего.
Масштаб хорошо виден в цифрах. В опросе Writer и Workplace Intelligence (1600 человек, из них 800 руководителей) 31% сотрудников прямо признались, что саботируют AI-стратегию своей компании: отказываются пользоваться инструментами, намеренно выдают слабый результат, подкручивают метрики. Это не пассивное «не разобрался», это активное противодействие. В обновлённом опросе весной 2026 цифра почти не сдвинулась.
Но за словом «сопротивление» часто прячется не то, что кажется. Типичный сюжет, который описывают многие тимлиды: самый громкий скептик в команде оказывается активным пользователем инструментов. Публичный скепсис работает как позиция в переговорах, а не как техническая оценка.
И основания у такого скепсиса обычно рациональные.
Первое - про качество. Растёт доля кода, который автор не может объяснить. Не «плохой код», а именно необъяснимый: работает, тесты проходят, а на вопрос «что здесь происходит» отвечают пожатием плеч. Претензия опытных инженеров направлена не на использование ИИ, а на то, что вместе с ускорением уходит привычка думать над результатом.
Второе основание - про нагрузку, и к нему я вернусь ниже.
Отдельная беда, о которой говорят реже: ревью превращается в узкое место, а нагрузка на тех, кто за него отвечает, растёт быстрее всех. Генерация кода дешевеет, проверка кода не дешевеет вообще. Тимлиды и старшие инженеры первыми упираются в потолок, потому что через них проходит всё, что команда успела нагенерировать. Скептицизм человека, который вручную вычитывает этот поток, стоит воспринимать как данные, а не как саботаж.
Ещё одна вещь, которую стоит признать честно: обучение почти всегда идёт в личное время сотрудника. Вечерние созвоны, выходные, «посмотри на досуге». Если это не проговорить вслух, получается тихое принуждение, которое потом возвращается сопротивлением.
Неравномерная готовность и разница в глубине
В любой команде разный уровень «нативности» к новым инструментам. Одни готовы пробовать и не сдаются после неудач, другие сопротивляются. Попытка поднять всех разом распыляет усилия и не даёт результата.
Готовность при этом расходится не только по людям, но и по функциям, причём не всегда предсказуемо. Нередко первыми заводятся не разработчики, а тестировщики или аналитики. Триггер у них чаще экономический, а не технологический: людей в функции стало меньше, объём работы вырос, и автоматизация рутины становится вопросом выживания, а не любопытства.
Ещё одно наблюдение, уже из личного опыта, проверенное не на одном человеке: раздача ссылок не работает. Я не раз делился с людьми качественно подобранными списками - каналы, видео, курсы, где реально можно научиться. Такие подборки потребляются как лента и забываются. Посмотрел, получил дозу новой информации, успокоился.
Дело не в качестве материалов. Люди просто не знают, как работать с этим системно, и сопротивляются потоку, к которому не готовы. Человек заглядывает в подборку, понимает, что нырять с этим головой пока не готов, и на этом успокаивается. Между «узнал» и «применил» лежит работа, которую никто за человека не сделает, и одной ссылкой её не запустить.
Отдельно про громкость. Первыми и самыми заметными «экспертами» по AI в команде становятся не те, кто глубже разобрался. Люди, которые действительно понимают ограничения инструментов, обычно разбираются медленнее и говорят тише. Это снижает качество внутренней экспертизы и подрывает доверие к самой теме: команда видит уверенные заявления, потом видит их последствия и делает вывод про технологию, а не про говорящего.
При этом у громких есть своя правда, и её стоит признать. Раньше, чтобы получить нужный инструмент или фичу, надо было пройти долгий официальный путь: сформулировать требования, завести задачу, положить её в бэклог и ждать, пока у разработчиков дойдут руки. На это уходят недели, а часто задача так и остаётся внизу списка. Инструменты сломали эту очередь: человек берёт и собирает себе прототип сам, за вечер, никого не дожидаясь.
И вот здесь громкие правы по существу. Если человек сделал то, что по официальному каналу не получил бы никогда, его инициатива оправдана - даже если технологию он выбрал неудачно и потом это придётся переделывать. Претензия «он выбрал не тот инструмент» справедлива, но она не отменяет главного: старый путь через бэклог для него просто не работал.
Проблема перехода от личного к общему
Дилемма заключённого в AI-adoption
Отдельному инженеру часто невыгодно раскрывать свой полный потенциал. Став x10-инженером, он рискует получить x10 нагрузки и в итоге поспособствовать сокращению коллег. Возникает коллективно деструктивное равновесие: каждый рационально занижает демонстрируемую продуктивность.
Логика простая и считается за минуту. Покажешь удвоенную скорость - получишь удвоенный план на следующий квартал. Проявишь инициативу - её подхватят, понесут наверх, и отвечать за неё будешь ты. Промолчишь - останешься при своём, а выигрыш от инструментов оставишь себе в виде свободного времени.
Это не наблюдение одной команды. Anthropic опросила своим исследовательским инструментом 1250 профессионалов: 69% так или иначе говорили про стигму вокруг использования AI на работе, 55% тревожатся за то, что будет с их карьерой дальше. Люди скрывают не потому, что стесняются технологии. Они считывают, чем обернётся признание.
Фон для этого расчёта тоже вполне реальный. В феврале 2026 Block объявил о сокращении более 4000 сотрудников из примерно десяти тысяч, прямо назвав причиной то, что меньшая команда с новыми инструментами делает больше. Акции выросли на двадцать с лишним процентов. Инженер, который читает такие новости, делает ровно тот вывод, который описан выше.
Отсюда неочевидный практический вывод: обучение стоит оформлять как личное развитие человека, а не как инвестицию компании в производительность. Разница в рамке решает больше, чем кажется. Как только звучит «компания вложилась, теперь верните ускорением», включается ровно та дилемма, из-за которой люди перестают показывать реальные результаты.
Индивидуальный разрыв и искажение метрик
Главная нерешённая проблема - разрыв между индивидуальной выгодой от AI и отсутствием пользы для организации. Разработчик ускоряется, бизнес-метрики не двигаются. Пол Эверитт (Paul Everitt) в докладе про переход к agentic engineering формулирует это прямо: индивидуальную выгоду мы видим, организационную пока нет.
У него же есть цифра, которая отрезвляет. Компания DX 16 месяцев наблюдала за 400+ инженерных организаций: использование AI-инструментов выросло в среднем на 65%, а медианный прирост пропускной способности по пулл-реквестам составил около 8%. Формулировка Эверитта звучит так: это не десять раз, это примерно десять процентов. В продолжении того же исследования есть вещь ещё неприятнее: даже эти скромные приросты нестабильны, и две трети разработчиков, вышедших на пик экономии времени, в следующих кварталах откатываются назад.
Похожая история у макроэкономистов. Дарон Аджемоглу в работе про простую макроэкономику ИИ даёт верхнюю оценку прироста совокупной факторной производительности меньше 0,7% за десять лет. Не за год.
На уровне организаций картина в 2026 такая же. В январском выпуске Accenture Pulse of Change (3650 руководителей и 3350 сотрудников, 20 стран) только 32% руководителей говорят, что добились устойчивого эффекта от AI в масштабе всей компании. Со стороны сотрудников симметрично: лишь 27% уверенно подтверждают, что им комфортно делегировать задачи AI-агентам. Инвестиции идут, а устойчивый эффект есть у трети.
Ещё один срез я приведу с оговоркой, потому что это опрос вендора AI-платформы, а не независимое исследование. Writer вместе с Workplace Intelligence в апреле опросили 1200 руководителей и 1200 сотрудников. Проблемы с внедрением у 79% организаций, а значимый возврат от генеративного AI видят только 29%. При этом 92% руководителей целенаправленно растят внутреннюю «AI-элиту», и 60% планируют увольнять тех, кто не адаптируется. Отдельно отмечу: заявленная пятикратная продуктивность этой «элиты» - не измерение, а мнение 87% опрошенных руководителей.
И вот здесь два блока цифр стыкуются в одну неприятную картину. Отдачи на уровне компании почти нет, но увольнять за неадаптацию собираются уже сейчас. Инженер получает подтверждение своему расчёту с обеих сторон: показывать рост продуктивности рискованно, и не показывать тоже рискованно. Это не иррациональный страх, это чтение обстановки.
Почему же личное ускорение не превращается в организационное? Потому что скорость всей цепочки определяет не самый быстрый её этап, а самый медленный. Ускорив написание кода, вы разгоняете один участок, но общий срок задаёт тот, что остался медленным. И как только вы расшиваете один затор, очередь тут же собирается на следующем этапе - в планировании, в ревью, в тестировании. Место, которое тормозит весь поток, не исчезает, оно переезжает. Причём переезжает быстрее, чем это успевают заметить: команда радуется, что кодить стало вдвое быстрее, а релизы почему-то выходят с прежней частотой.
Первое: значительная часть выигрыша уходит в подготовку. Чем сильнее вы полагаетесь на агента, тем больше времени тратится на постановку задачи, сбор контекста и проверку плана. Работа не исчезает, она меняет форму, и в отчётах это выглядит как «кодинг стал быстрее, а релиз почему-то нет».
Второе: проверка не масштабируется вместе с генерацией. Код можно писать в разы быстрее, а тестировать и ревьюить - почти нет. Если функцию проверки не перестроить заранее, ускорение разработки просто создаёт очередь перед QA и выжигает людей на этом участке.
Теперь про метрики, и это самая абсурдная часть истории.
Классический антипаттерн выглядит так. Внутри команды все понимают, что story points давно потеряли смысл: при работе с агентами задача на три и на восемь поинтов реализуется примерно одинаково. Но наверх нужно показать рост, и метрику начинают конструировать. Например, оценивать новые задачи по старому справочнику сложности - тогда velocity гарантированно вырастет, потому что вчерашняя двухнедельная задача сегодня закрывается за пару дней с той же ценой в поинтах.
Дальше эта логика доходит до предела: расстановку оценок поручают самой модели. Получается замкнутый круг, где ИИ генерирует метрику, которая должна доказать эффект от внедрения ИИ. Дыра видна сразу: рост измеряется в единицах, которые в новой реальности уже ничего не измеряют.
Здесь же стоит аккуратнее обращаться с известной цифрой MIT про 95% пилотов GenAI без измеримого влияния на P&L. Цифра настоящая, отчёт реальный. Но у большинства пилотов просто не было замера до внедрения. «Нет измеримого эффекта» в такой ситуации - это результат по умолчанию, а не доказанный провал. Что возвращает к тому же: сначала договоритесь, что и чем вы меряете, иначе любая цифра на выходе будет говорить больше о вашей системе учёта, чем о вашем внедрении.
Если мерить отдельных людей, поведение искажается: кто-то рисует активность, кто-то тормозит изменения, чтобы не портить личные показатели. Хороший пример замены встречается в разных командах: лидерборд по количеству потраченных токенов не сработал, и его заменили на лидерборд улучшений процесса - баллы за сделанный общий инструмент, за найденный баг в общих правилах и агентах. Мерить активность - получишь нарисованную активность. Мерить вклад в общий инструмент - получишь общий инструмент.
И важная поправка к самому тезису. Метрики искажают не только снизу и не только из шкурного интереса. Часто цифру аккуратно конструирует само руководство команды - как щит от давления сверху, чтобы выиграть время и не подставить людей. Это меняет рецепт: бороться нужно не с теми, кто химичит с цифрами, а с требованием предъявить рост там, где рост пока нечем измерить.
Отсутствие синхронизации и стандартов
Когда каждый использует свой ИИ со своими настройками и контекстом, результаты расходятся: разный тон, разные предположения, разное качество. Проблема усугубляется, когда такие результаты подпитывают работу друг друга. Пока у команды нет общего слоя для агентов - единых правил и инструкций, справочников, гайдрейлов, переиспользуемых скиллов, описанных процессов и договорённостей о том, как все работают с моделью, - ИИ усиливает разнобой, а не гасит его. Каждый настраивает агента под себя, и на выходе получается пять разных стилей вместо одного командного.
Суть проблемы формулируется одним вопросом: если у пятерых разработчиков нет одинакового контекста, какой окажется разбежка в качестве и в оформлении результата?
Первое решение, которое приходит в голову, обычно не работает. Завести общий репозиторий, куда все скидывают свои наработки, - это не стандартизация. Довольно быстро получается свалка, где каждый заливает то, что сработало лично у него, а разобраться в этом сложнее, чем написать заново. Тот же разнобой, только централизованный.
Что работает лучше - описанный общий контекст: архитектура, конвенции, модель данных, правила работы с внешними зависимостями, антипаттерны, требования безопасности. Отдельно контекст для тестирования: шаблоны тест-кейсов, баг-репортов, стандарты автотестов. Плюс назначенный владелец, который отвечает за актуальность этого контекста и просматривает изменения в общих инструментах. Роль лучше делать срочной, например на квартал, и обязательно давать человеку место, куда списывать это время. Роль поверх основной загрузки не живёт.
Ещё один эффект виден только когда команда начинает разбирать инструменты друг друга: люди дублируют общие справочники внутри личных наработок. Справочник ролей, список статусов, правила именования лежат внутри одного инструмента, и когда завтра добавится новая сущность, править придётся в нескольких местах сразу. Отсюда полезное разделение на инфраструктурные вещи, которые делает и поддерживает один человек, а подключают все, и на личные, где каждый волен делать как хочет.
И честная оговорка против самого себя. Стандартизация - не бесспорное добро, и сопротивление ей бывает обоснованным. Аргумент «дайте каждому свободу собрать под себя и посмотрим, что получится» имеет смысл на ранней стадии, когда ещё непонятно, какие практики вообще стоит закреплять. Закономерность тут такая: стандарт заходит, когда его предлагает технически компетентный человек, который сам этим пользуется. Тот же стандарт, спущенный административно, читается как контроль, и сопротивление будет политическим, а не техническим.
Разрыв в навыках и смена требований
Сопротивление традиционным практикам
Переход от соло-работы к команде - критический момент. Инстинктивное желание навести привычный порядок через feature branches, code review и scrum резко снижает скорость. Это главная проблема командного AI-кодинга.
Дальше начинаются решения, которые ещё недавно выглядели бы как деградация процесса.
Спринты начинают мешать. Команда мыслит горизонтом в две недели и фиксированным набором задач на выходе, и у неё пропадает причина закрывать задачу за день. Детальный груминг тоже теряет смысл: разбирать вручную то, что всё равно будет декомпозировано вместе с моделью, - трата времени.
Самое контр-интуитивное происходит с тестированием. Дробить фичу на мелкие проверяемые куски - каноническая практика, но при быстрой генерации она даёт двойную работу: тестируешь по частям, а потом всё равно перепроверяешь собранное целиком. Многие команды в итоге откатываются к тому, чтобы дождаться готовой функциональности и протестировать один раз. Формально это шаг назад к waterfall. Причём начинается всё с тестирования, потому что именно туда упирается ускоренная генерация, но следом подтягивается и разработка: планирование укрупняется, задачи перестают резать на мелкие итерации.
И ещё одна находка, до которой доходят не сразу: WIP-лимиты на этапах проверки работают как защита от давления. Когда на входе стало быстрее, а на выходе физически не успевают, лимит даёт понятную формулировку для бизнеса. Процессный артефакт превращается в аргумент, чтобы ускорение не выжгло людей в конце конвейера.
Новые требования к членам команды
Чисто технические навыки дешевеют по сравнению с пониманием бизнес-домена. Инженерам нужны деловая хватка и эмпатия к пользователю. Менталитет «моя работа - писать код» становится тормозом.
Заметнее всего это по смене формата постановки задач. Раньше до разработчика доезжали разобранные user story, то есть основную работу по декомпозиции делал кто-то другой. Теперь всё чаще на вход приходит PRD - документ, не доведённый до уровня отдельных задач, и детальное планирование инженер делает сам вместе с моделью. Для него это ощутимо тяжелее: больше вопросов, больше неопределённости, всё нужно исследовать и уточнять. Зато бизнес-контекст оказывается в голове у того, кто пишет решение, а не пересказывается через третьи руки.
Но здесь стоит оспорить популярный тезис. Мысль, что инженеры сами прячутся от общения с бизнесом, верна далеко не всегда. Сплошь и рядом бывает наоборот: технических специалистов системно не зовут на встречи с заказчиком и на обсуждения, где принимаются решения, а чтобы получить их время, нужно договариваться через несколько уровней. Барьер между инженером и бизнесом чаще организационный, а не ментальный. Прежде чем чинить мышление людей, стоит проверить, пускают ли их в комнату.
Экосистемные барьеры и практические нормы
Tacit knowledge и блокировка IT-отделами
Главное узкое место внедрения в больших организациях - неявное знание, которое крайне сложно извлечь. Людям оно кажется очевидным, поэтому не проговаривается и не документируется. На фоне форсированного внедрения и разговоров про сокращения появляется активное сопротивление, которое блокирует процесс дополнительно.
Здесь есть страх, который звучит параноидально, но имеет основания: компании будут оцифровывать своих сотрудников. Дадут людям интерфейс, а внутреннее устройство оставят себе. Люди работают с инструментом, попутно обучая внутреннего агента, и однажды оказываются лишними.
Реальность при этом выглядит скучнее и оттого интереснее. Чаще это не злой умысел, а обычная организация работы: заказчик собирает всю обвязку у себя, а подрядчикам выдаёт доступ к готовому. Подрядчики делают работу, но не видят, как устроен инструмент, и не могут его менять. Ловушку никто не строил. Просто владение контекстом естественным образом остаётся у того, кто его собрал, а не у того, кто им пользуется. Это структурная асимметрия, а не заговор, и защищаться от неё нужно иначе.
Стоит признать и обратную сторону: извлечь неявное знание сложно даже при полном желании поделиться. Часто делиться просто нечем, потому что опыт ещё не отстоялся до состояния, которое можно передать словами. Добавьте языковой барьер в распределённых командах, и половина контекста не доезжает до тех, кому он нужен.
Проблема персональных AI-инструментов
IT-отделы часто блокируют персональные AI-инструменты из соображений безопасности, не осознавая цену. Сотрудник с персонально настроенным AI работает эффективнее, чем с чистым корпоративным развёртыванием той же модели. Причина простая: персональный контур накапливает контекст под конкретного человека и его задачи, а корпоративный выдаётся всем одинаковым.
Здесь важно не преувеличивать. Мне попадалась оценка, что блокировка личных инструментов стоит компании кратной потери производительности, но под этой цифрой я не нашёл ни одного исследования, поэтому приводить её не буду. Что действительно измерено: в опросе Gartner (12 тысяч респондентов, 40 стран) сотрудники, совмещающие корпоративный и личный стек, в 1,7 раза чаще сообщают о значимой экономии времени, чем те, кто пользуется только разрешёнными корпоративными инструментами.
И главное - запрет не убирает использование личных инструментов. Он убирает его видимость. Когда корпоративные лимиты заканчиваются в середине дня, люди переключаются на личные подписки и продолжают работать. Реакция на такое обычно не «давайте пересмотрим лимиты», а «не рассказывайте об этом остальным». Проблема никуда не девается, она просто уходит из поля зрения тех, кто мог бы её решить.
Добавьте к этому разницу в условиях. У корпоративного тарифа обычно прописано, что провайдер может и чего не может делать с рабочими данными. У личной подписки правила свои, и часто менее строгие. Понять, куда в итоге уходят данные и насколько это безопасно, по факту приходится самому сотруднику. А у него на такой разбор нет ни времени, ни полномочий - это работа службы безопасности, а не разработчика.
Ещё одна причина, о которой забывают: часто дело вообще не в психологии, а в простой инфраструктуре. Человек не может завести аккаунт, потому что сервис не принимает номер телефона его страны. Доступ закрыт по региону. Корпоративная сеть режет нужный трафик. Лицензий не хватает на всех желающих. Пока не решены эти базовые вещи, до разговоров про мотивацию и страхи дело просто не доходит - человек упирается в стену ещё на входе.
Отсюда понятная рыночная ниша: продукт, который умеет разделять профессиональный и личный контекст, оставаясь внутри периметра безопасности.
Как с этим работать
Дальше - то, что действительно даёт результат.
Прямая работа со страхами. Если не адресовать напрямую страх замены, страх обнажить некомпетентность и перегрузку, внедрение провалится. Это не мягкая надстройка к процессу, а условие входа.
Когорта одного уровня вместо «поднять всех». Небольшая группа проходит обучение вместе и выходит с общим пониманием и общим словарём. Дальше она развивается как группа и становится источником практик для остальных. Попытка охватить сразу всех даёт ровно противоположный эффект: сильным скучно, слабым непонятно, а времени уходит больше.
Рамка «сначала ты, потом компания». Сначала личное развитие человека, и только вторым пунктом польза для продукта. Эта формулировка снимает и страх, и дилемму заключённого лучше любых уговоров, потому что честно отвечает на вопрос «а мне-то это зачем».
Регулярный синк вместо разового мероприятия. Раз в неделю команда собирается и обменивается опытом: кто что попробовал, что сработало, что нет, какими находками и скиллами готов поделиться. Формат обмена важнее формата лекции. Разовое обучение так не работает: оно не оставляет людям времени уложить знания и попробовать самим, а без собственной попытки ничего не закрепляется.
Публичный разбор чужой работы. Один человек показывает свой инструмент на реальной задаче, команда разбирает его устройство. Это даёт сразу три вещи: наработка становится лучше, остальные видят её изнутри, а общие куски выносятся туда, где ими смогут пользоваться все.
И самое интересное про сопротивление. Скептики часто оказываются лучшими критиками на таких разборах: они внимательнее всех и задают вопросы, которые энтузиасты пропускают. Сопротивление конвертируется не уговорами и не демонстрацией чужих успехов. Оно конвертируется, когда скептику дают роль эксперта в чужой работе, а не роль объекта убеждения.
Измеримый бытовой выигрыш как аргумент. Не абстрактная продуктивность, а конкретная рутина, которая раньше занимала часы, а теперь занимает минуты. Такой пример убеждает сильнее любой презентации, потому что его можно повторить завтра.
Обещание бизнесу «не x10, а качество». Продавать наверх стоит не рост объёма, а высвободившееся время на рефакторинг, техдолг и автоматизацию проверок. Это единственная формулировка, которая не запускает дилемму заключённого.
Фокус на командном результате. Вместо индивидуальной скорости - общий результат: time-to-market, доля релизов с откатом, количество багов после релиза. И общие правила как способ стандартизации.
Отдельно про то, чего делать не стоит. Мне довелось быть ментором на хакатоне по AI в одной крупной компании: сильные преподаватели и менторы, компания вложилась серьёзно. И всё равно разово это не прижилось - по одной причине. Людей не освободили от основной работы. Часть команд просто не дошла до хакатона из-за загрузки, а начатые проекты не довели до конца, и все вернулись в рутину. Деньги дали, времени не дали. Это и есть главный вывод: если вы не готовы забрать у человека часть текущей нагрузки, любое внедрение - хакатон, курс, синк - останется его личным вечерним хобби.
Что в итоге
Личные практики не становятся общими не потому, что люди ленивы или не разобрались. Они не становятся общими, потому что человеку невыгодно их отдавать, команде нечем измерить эффект, а организация просит рост там, где узкое место уже переехало в другое место.
Сначала снимите с людей рутину и страх. Потом договоритесь, что именно вы измеряете. И только потом занимайтесь инструментами.
Источники
- Paul Everitt: The Shift to Agentic Engineering - разрыв между индивидуальной выгодой от AI и отсутствием организационного эффекта.
- AI productivity gains: More modest than expected - DX, 16 месяцев и 400+ инженерных организаций: прирост около 8-11%, а не в разы.
- The AI efficiency plateau - DX о том, почему индивидуальные приросты откатываются назад.
- Introducing Anthropic Interviewer - 1250 интервью: стигма вокруг использования AI на работе и тревога за карьеру.
- 31% of employees are ‘sabotaging’ your gen AI strategy - формы активного сопротивления внедрению.
- Enterprise AI adoption in 2026 - Writer и Workplace Intelligence, апрель 2026: проблемы внедрения, ROI, «AI-элита». Опрос вендора, читать с поправкой на это.
- Accenture Pulse of Change - выпуск от 15 января 2026, 3650 руководителей и 3350 сотрудников: устойчивый эффект AI есть у 32% компаний.
- The GenAI Divide: State of AI in Business 2025 - первоисточник цифры про 95% пилотов без измеримого эффекта.
- The Simple Macroeconomics of AI - Дарон Аджемоглу, оценки эффекта AI на производительность.
- Block сокращает 4000 из 10000 сотрудников, ссылаясь на AI - кейс, который читают инженеры.
- Скрам не нужен: как ИИ-кодинг меняет представление об эффективной команде - почему традиционные практики ломаются и что приходит на их место.
- Константин Доронин: фреймворк внедрения AI-кодинга в команду - начинать с задач поддержки, ограничивать размер пулл-реквестов.
- Чат канала LLM под капотом: поэтапная стратегия внедрения - пилот, полное покрытие одной команды, питч метрик, роллаут.