Как ускориться с ИИ, если компания начинает поздно
У компании, которая начинает с ИИ в 2026 году, есть преимущество, о котором никто не пишет в рекламе: четыре года ошибок индустрии, уже совершённых, измеренных и опубликованных, которые ей не нужно повторять. Чтобы реализовать это преимущество, нужна конкретная последовательность: сначала наведите порядок в данных, процессах и коммуникации, затем постройте культуру, которая умеет работать с ИИ, и лишь потом внедряйте ИИ-инструменты, выбирая те, что усиливают друг друга, а не те, что изолируются. Большинство поздних стартеров проходит эту последовательность задом наперёд. Они начинают с подписок, и результат уже записан в данных: в глобальном опросе McKinsey за март 2025 года более 80% респондентов сказали, что их организации не видят ощутимого влияния генеративного ИИ на EBIT компании. Последние месяцы я изнутри наблюдал, как одна компания проживает версию задом наперёд.
Как ИИ-мандат середины 2026 года превратился в повтор ошибок индустрии образца 2023-го
Самый дорогой способ поздно начать с ИИ состоит в том, чтобы начать в исходном порядке. Компания, за которой я наблюдал, держалась в стороне от ИИ по причинам, которые в своё время были обоснованными: проверенный финансовый продукт, управляющий десятками миллионов для своих пользователей, бизнес-модель, которой ИИ для работы не требовался, и инженерная команда, открыто скептичная к ИИ даже как к инструменту для кода. Затем, в середине 2026 года, совет инвесторов попросил задействовать ИИ внутри компании, и началась игра в догонялки.
То, что появилось в следующие месяцы, не было стратегией. Это была хронология, поставленная на повтор. Одна ИИ-подписка для транскрибации звонков. Другая для вопросов к базе данных на естественном языке. Пилоты автоматизации, собранные в визуальном no-code инструменте. Каждая инициатива по отдельности выглядела разумной, и каждая была точным воспроизведением этапа, который остальная индустрия уже прошла, усвоила и оставила позади. Вместо того чтобы догонять передний край, компания заново разыгрывала пройденный путь, этап за этапом.
Хочу быть точным насчёт своей роли: я консультировал там по другому направлению, ИИ-стратегия не входила в мою зону ответственности, и власти что-либо из этого решать у меня не было. У меня была вся картина перед глазами. И картина показывала компанию, платящую полную цену, временем и доверием, за уроки, которые индустрия уже опубликовала бесплатно.
Поздний старт с ИИ даёт преимущество только тому, кто пропускает этапы
Компания, начинающая с ИИ в 2026 году, наследует четыре года опубликованных ошибок, которые можно пропустить. Повтор означает, что поздний стартер заново проигрывает ошибки внедрения ИИ в их исходном порядке вместо входа на текущем переднем крае, и начинается он в тот момент, когда компания отказывается от этого наследства. У экономистов развития есть имя для его принятия: leapfrogging, то есть скачок через этапы, изучаемый со времён статьи Люка Суте 1985 года в World Development и определённый UNCTAD (2018) как обход «промежуточных этапов технологии» в процессе развития. Канонический пример: телефония. По данным ITU за 2024 год, в Африке 98 мобильных подключений на 100 жителей против единственной фиксированной линии на те же 100. Страны, подключившиеся последними, так и не протянули медь. Они вошли на переднем крае.
Компании, поздно внедряющие ИИ, занимают ту же позицию, и большинство её растрачивает. Пока компания из моей истории размышляла, мир двигался: в глобальном опросе McKinsey, опубликованном в ноябре 2025 года, 88% респондентов сообщили о регулярном использовании ИИ хотя бы в одной бизнес-функции своих организаций, годом ранее таких было 78%. Передний край продолжал уходить вперёд, опубликованная летопись того, что сработало и что провалилось, продолжала расти, и ничто из этой летописи не переносится само. UNCTAD назвал свой обзор про leapfrogging «Look before you leap», то есть «посмотри, прежде чем прыгать», по причине, к которой я ещё вернусь: у пропуска этапов есть предусловие, и это не заявка на закупку.
Изолированные ИИ-подписки дают точечное ускорение, а не быструю поставку
Точечный ИИ означает любой инструмент, внедрённый для ускорения одной задачи в изоляции, в отрыве от общего контекста, из которого работает остальная организация. Точечный ИИ покупает локальное облегчение, и его выигрыши не складываются. Бот-транскрибатор экономит час тому, кто ведёт протокол. Чат с базой данных экономит аналитику один запрос. Каждый выигрыш реален, каждый локален, и каждый оставляет после себя ещё один остров контекста, который больше ничто не умеет читать. Это паттерн, за которым я наблюдал, и паттерн, который индустрия уже измерила вдоль и поперёк.
Отчёт McKinsey об агентном ИИ за июнь 2025 года описывает возникающий парадокс: почти восемь компаний из десяти сообщают об использовании генеративного ИИ, и столько же сообщают об отсутствии значимого влияния на финансовый результат. Объяснение отчёта совпадает с тем, что предсказывает точечный ИИ: горизонтальные копилоты и чат-боты масштабировались быстро, но дают размытую, трудноизмеримую пользу, тогда как трансформирующие сценарии, привязанные к конкретным бизнес-функциям, «около 90 процентов которых по-прежнему застряли в пилотном режиме», так и не складываются на уровне бизнеса. У софтверных компаний в частности дела не лучше: Technology Report 2025 от Bain обнаружил, что «две из трёх софтверных компаний развернули инструменты генеративного ИИ, но внедрение среди их разработчиков остаётся низким». Развёрнутый инструмент, которого разработчики избегают, не сдвигает ни одну метрику поставки.
Противоположностью точечному ИИ является ИИ с накопительным эффектом: каждый новый инструмент читает один и тот же управляемый контекст и пишет в него, поэтому второй инструмент делает первый ценнее, а не противоречивее. Накопление является свойством связей между инструментами, и именно поэтому его нельзя купить по одной подписке за раз.
Данные самой индустрии показывают ту же картину: локально быстрее, глобально на месте
ИИ в инженерной организации видно повсюду, кроме статистики поставки. Экономист Роберт Солоу написал исходную версию в New York Times Book Review в 1987 году: «Компьютерную эпоху видно повсюду, кроме статистики производительности». Почти четыре десятилетия спустя внедрение ИИ воспроизводит его парадокс на ускоренной перемотке, и сверка чисел, которые все цитируют, показывает, как именно.
Bain (2025) сообщает, что «команды, использующие ИИ-ассистентов, видят рост производительности от 10 до 15%, но сэкономленное время часто не перенаправляется на более ценную работу», тогда как некоторые компании сообщают о выигрыше от 25 до 30 процентов, соединяя генеративный ИИ со сквозной перестройкой процессов. Те же модели, те же поставщики, вдвое больший результат: разница в организации, а не в инструменте. Рандомизированное исследование METR 2025 года показало, что 16 опытных open-source разработчиков, выполняя 246 реальных задач, с ИИ работали на 19% медленнее, считая при этом, что были примерно на 20% быстрее, так что самооценка ускорения не является измерением. А опрос Atlassian 2025 года об опыте разработчиков среди 3500 разработчиков и менеджеров обнаружил, что 68% разработчиков экономят с ИИ больше десяти часов в неделю, тогда как половина сообщает о потере десяти и более часов в неделю на организационное трение, и на первом месте в списке стоит поиск информации. Дивиденд реален, и он утекает в щели между инструментами и между командами.
Я называю эту форму так: локально быстрее, глобально на месте. Каждая задача ускоряется, а поставка стоит на месте. Это родственник, на стадии внедрения, того провала, который я задокументировал внутри конвейера поставки: локально верно, глобально неверно. Парадокс Солоу в итоге разрешился. Олинер и Сичел (2000) заключили, что за скачком производительности конца 1990-х «по большей части стоят именно информационные технологии», а сравнение компьютера с электрической динамо-машиной, сделанное Полом Дэвидом в 1990 году, объяснило задержку: электричество преобразило производительность фабрик спустя десятилетия после появления моторов, когда фабрики были перестроены вокруг них. Выигрыши следуют за реорганизацией, а не за изобретением. Повтор откладывает ровно эту часть.
Передний край 2026 года: операционная модель, то есть спецификации поверх управляемого контекста
Передний край, на котором позднему стартеру стоит входить, представляет собой операционную модель, а не инструмент. К середине 2026 года еженедельное использование ИИ стало просто тем, что делают софтверные команды: опрос Pragmatic Engineer среди 906 читателей (самоотбор, в основном инженеры и инженерные руководители, проведён в начале 2026 года) обнаружил, что 95% используют ИИ-инструменты как минимум еженедельно и 55% регулярно работают с ИИ-агентами, причём Claude Code используют 71% этих пользователей агентов. Телеметрия Faros AI за 2026 год по 22 000 разработчиков её клиентской базы рассказывает ту же историю со стороны труб: 60% разработчиков пользуются ИИ-инструментом еженедельно, а ИИ-агенты прошли путь от нуля процентов ревью пул-реквестов в датасете Faros 2025 года до 25% в датасете 2026-го. Тот же отчёт честен насчёт цены всей этой скорости без управления: багов на разработчика стало на 54% больше, и на 31% больше пул-реквестов вливается вовсе без ревью.
На переднем крае изменилось то, откуда начинается работа. GitHub выпустил Spec Kit в сентябре 2025 года вокруг идеи, что спецификация «становится источником истины, который ваши инструменты и ИИ-агенты используют, чтобы генерировать, тестировать и валидировать код». Technology Radar компании Thoughtworks поместил spec-driven development, то есть разработку от спецификации, в кольцо Assess в ноябре 2025 года, как формирующуюся практику, которую стоит изучать, а не решённый вопрос, и апрельский выпуск 2026 года по-прежнему держит перечисленные им инструменты этого подхода, GitHub Spec Kit и OpenSpec, в Assess, при этом переместив Claude Code из Trial в Adopt за пять месяцев, потому что команды «пользуются им изо дня в день в продакшен-поставке ПО». В командах, с которыми я работаю, тот же сдвиг поглотил внутреннюю автоматизацию: то, что в 2023 году было бы визуальным no-code процессом, теперь является маленьким инструментом, который агент пишет по спецификации и который версионируется рядом с кодом, которому служит. Мне не известен ни один опубликованный датасет, отслеживающий эту миграцию, так что считайте это выборкой одного консультанта, но приведённая выше летопись инструментов указывает в ту же сторону.
Исследование DORA 2025 года, построенное на ответах почти 5000 технологических специалистов, даёт переднему краю его однострочный закон: «Главная роль ИИ в разработке ПО заключается в усилении. Он умножает сильные стороны высокоэффективных организаций и дисфункции буксующих». Из семи способностей, которые DORA определила как усиливающие положительный эффект ИИ, две касаются только контекста: здоровые экосистемы данных и внутренние данные, доступные ИИ. Условия ускорения организационные, и это ровно те этапы, которые повтор пропускает.
Первые 90 дней позднего старта: фундамент, культура и только ИИ с накопительным эффектом
У leapfrogging есть предусловие, которое вендорские презентации опускают: поглощающая способность. Никто не перепрыгивает этапы с земли. Экономика развития здесь прямолинейна. Стайнмюллер (2001) писал, что «усилия по наращиванию поглощающей способности представляют собой особую стратегию экономического развития и предусловие технологического скачка», а Кын Ли (2019) предупреждал, что отстающим «не следует пытаться совершить преждевременный скачок, а следует сначала нарастить некоторую поглощающую способность», сравнивая скачок с полётом на воздушном шаре после того, как лестницу убрали: без способности вы падаете. В применении к софтверной компании поглощающая способность не является озером данных. Она определяется тем, способна ли ваша организация усвоить инструмент, который оперирует её знаниями.
В компании, за которой я наблюдал, у меня не было права решать. Если бы я мог отмотать к месяцу мандата, держа это право в руках, вот как выглядели бы мои первые 90 дней.
Недели с 1 по 4: фундамент раньше инструментов. Наведите порядок в данных, процессах и коммуникации, от которых будет зависеть любой ИИ. Составьте карту того, где живёт истина: какие решения лежат в спецификациях, какие в задачах, какие только в коде, какие только у кого-то в голове. Сверьте имена, закройте дыры в процессах, которые люди сейчас прикрывают вручную, и сделайте этот контекст читаемым для машин. Ничто на этой фазе не требует покупок, и всё последующее зависит от неё.
Недели с 5 по 8: культура раньше развёртывания. Постройте общее понимание того, как ИИ работает, где он ошибается и как с ним работать, и делайте это вместе со скептиками, а не в обход них. Bain (2025) обнаружил, что «три компании из четырёх говорят, что труднее всего заставить людей изменить то, как они работают». Относитесь к неприятию инженерной команды как к калибровочным данным от людей, которые поймают то, что ИИ делает почти правильно, а не как к препятствию, которым нужно управлять. Снижайте неприятие работающими примерами на реальных задачах команды, а не приказами и квотами использования.
Недели с 9 по 12: только ИИ с накопительным эффектом. Теперь внедряйте инструменты, с одним правилом допуска: каждый ИИ-инструмент обязан читать один и тот же управляемый контекст и писать в него, иначе он не входит. Инструмент, создающий собственный остров, работает системе в минус, даже когда выигрывает свою локальную задачу. Здесь фундамент окупается: общий контекст, который вы привели в порядок, становится слоем контекста (на английском), единственным местом, где каждый агент перед действием сверяет, что сейчас истинно. Файлы правил и серверы MCP представляют собой правильные трубы и неправильное управление; интерфейс к контексту не является решением об истине. Для профиля компании, стартующей поздно, регулируемой, осторожной, не переносящей отправку своей внутренней кухни облачному вендору, это к тому же шаг, который обязан работать на её собственных серверах. Это ограничение объясняет, почему LoomSignal, наш слой контекста для цикла поставки, размещается у клиента и покупается один раз.
Поздний стартер, который проходит эту последовательность, входит на переднем крае за один квартал, держа единственный актив, который ранним последователям пришлось зарабатывать четырьмя годами опубликованных провалов: знание, какие именно этапы были ошибками.
Компания из моей истории туда пока не дошла. Спустя месяцы после мандата поставка не сдвинулась, давление совета инвесторов только выросло, а бюджетный разговор развернулся, против направления всего рынка, которого она дожидалась, обратно к найму людей. В этом состоит настоящая цена повтора: не выброшенные на подписки деньги, а вывод, который организация делает в его конце, что ИИ не работает, хотя не работал только порядок. Опоздание с ИИ остаётся проблемой календаря. Повторение пути индустрии по порядку становится проблемой стратегии. Исправить сегодня можно только одну из двух.
Частые вопросы
Нет. Компания, начинающая с ИИ в 2026 году, наследует четыре года опубликованных исследований и задокументированных ошибок, которые можно пропустить. Поезд уходит по-настоящему лишь тогда, когда поздний стартер повторяет эти ошибки в исходном порядке вместо того, чтобы войти на текущем переднем крае: управляемый контекст, рабочие процессы на основе спецификаций и ИИ-инструменты, усиливающие друг друга.
Покажите последовательность, а не список инструментов: сначала наведите порядок в данных, процессах и коммуникации, от которых будет зависеть ИИ, затем постройте культуру работы с ИИ и лишь потом внедряйте ИИ-инструменты, которые разделяют один управляемый контекст. Советы директоров быстро переходят от вопроса про стратегию к вопросам, сколько это стоило и что вернуло, поэтому с первого дня договоритесь о метриках поставки. В опросе сообщества LeadDev 2025 года среди 883 инженерных руководителей и практиков 60% организаций назвали отсутствие метрик влияния ИИ ключевой проблемой.
Начните с фундамента, а не с подписок: составьте карту того, где в компании живёт истина (спецификации, задачи, код, дизайн), закройте дыры в именах и процессах, которые люди сейчас прикрывают вручную, и сделайте этот внутренний контекст читаемым для машин. Исследование DORA 2025 года показало, что отдача от ИИ зависит от таких способностей, как здоровые экосистемы данных и внутренние данные, доступные ИИ, а они существуют до покупки какого-либо ИИ-инструмента.
ИИ-транскрибация встреч и инструменты для разговора с базой данных представляют собой хорошие инструменты и плохую стратегию. Каждый из них ускоряет одну задачу в изоляции и оставляет после себя ещё один остров контекста. Точечный ИИ приносит локальное облегчение; скорость поставки приходит от ИИ с накопительным эффектом, то есть каждый новый инструмент читает один и тот же управляемый контекст и пишет в него, поэтому каждое добавление делает предыдущие ценнее.
Обязаловка поднимает метрики использования, а не поставку. Скепсис инженеров является данными: в опросе Stack Overflow 2025 года точности ИИ-инструментов не доверяет больше разработчиков (46%), чем доверяет (33%). Относитесь к скептикам как к рецензентам внедрения, снижайте неприятие работающими примерами на реальных задачах команды и измеряйте результаты поставки, а не квоты использования.
Файлы AGENTS.md и серверы MCP представляют собой место, откуда начинает большинство команд, и место, на котором поздний стартер не может останавливаться. Файлы правил предписывают поведение и устаревают в тот момент, когда код уходит дальше без них; MCP является интерфейсом доступа к контексту, а не решением о том, что сейчас истинно. Кто останавливается на этом, тот заново строит острова ИИ, только с трубами получше. Управляемое, сверенное состояние, то есть слой контекста, позволяет каждому новому ИИ-инструменту делать предыдущие ценнее.