Почему ИИ замедляет вашу поставку ПО?

ИИ замедляет вашу поставку не потому, что модели плохи. Он замедляет её потому, что ускоряет локальную работу: производство кода, спецификаций и задач. При этом работа, которая на самом деле сдерживает поставку, то есть согласование между людьми и инструментами того, что истинно, по-прежнему идёт с человеческой скоростью или не происходит вовсе. Эффект измерим. В рандомизированном контролируемом исследовании METR (2025) опытные разработчики с ИИ выполняли реальные задачи на 19% дольше, считая при этом, что были примерно на 20% быстрее. Я видел это изнутри, в ИИ-инициативе одной компании.

Как трёхдневный ИИ-рефакторинг обернулся двумя неделями разгребания последствий в продакшене

Каждый шаг ИИ-катастрофы выглядит победой, пока она происходит. В начале 2026 года CEO компании, с которой я работаю, отправил сообщение, которое прозвучит знакомо: нам нужно ускорить разработку ПО с помощью ИИ. К концу января он повторил это каждому техническому лидеру, и за считанные недели появились изолированные инициативы. Каждая была локальной, и каждая сама по себе выглядела разумной.

Первой стало обновление Next.js на новую мажорную версию. Фронтенд-команда направила на задачу ИИ-агента для кода и дала ему работать почти три дня. В кодовой базе не было юнит-тестов. Сборка прошла, ручные тесты в контролируемой среде прошли, и команда оценила, что агент сэкономил минимум две недели работы.

Затем это попало в продакшен. По пути агент незаметно переписал интеграции и выдумал эндпоинты, которых никогда не существовало. Фичи перестали работать, не выдав ни одной ошибки. Стабилизация заняла две недели, и на это время остановилась запланированная работа остальных направлений. Часть фич оставалась сломанной два или три месяца, и поломка обнаружилась лишь тогда, когда до этих фич наконец добрался один-единственный пользователь.

Выдуманные эндпоинты нельзя списать на редкое невезение. Авторы исследования USENIX Security 2025 сгенерировали 576 000 образцов кода на 16 моделях и показали, что как минимум 5,2% ссылок на пакеты у коммерческих моделей и 21,7% у моделей с открытым кодом указывали на несуществующие пакеты. Уверенные ссылки на то, чего нет, представляют собой задокументированное и измеренное поведение моделей.

Старые основы, сломанные на машинной скорости

ИИ-агенты для кода не изобрели новый способ провалиться; они сделали дешёвым способ, которому десятки лет: big-bang-переписывание кодовой базы без тестов. Мартин Фаулер написал свод правил в книге Refactoring, впервые изданной в 1999 году: рефакторинг делается маленькими шагами, которые всегда оставляют код рабочим, и поверх самотестирующегося кода. Трёхдневное переписывание без тестов нарушает оба правила сразу. Агент просто удешевил нарушение.

Это паттерн всей индустрии, а не ошибка одной команды. GitClear проанализировала 211 миллионов изменённых строк кода с 2020 по 2024 год и показала, что доля изменений, которые рефакторят или переносят существующий код, упала с 25% в 2021 году до менее чем 10% в 2024 году, а доля скопированных строк выросла с 8,3% до 12,3% всех изменений. В том виде, в каком его используют сегодня, ИИ производит больше кода, а не больше переиспользования.

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

Когда каждая роль в компании получает собственный ИИ, противоречия возникают из суммы инструментов, а не из какого-то одного. После рефакторинга инициатива продолжилась: дизайнер начал генерировать макеты и дизайн-спецификации с ИИ, PM писала задачи в Asana с ИИ, продакты писали спецификации в Notion с ИИ, разработчики писали код с ИИ. Каждое направление произвело впечатляющий объём артефактов. А ещё оно породило самое простое противоречие из возможных: имена в определениях продукта перестали совпадать с именами в коде.

Эрик Эванс дал имя тому, что было потеряно. Domain-Driven Design (2003) называет это единым языком (ubiquitous language): один строгий словарь, общий для тех, кто определяет продукт, и кода, который его реализует. Этот язык был неформальным протоколом консенсуса команды и поддерживался сам собой, пока люди писали всё вручную и читали работу друг друга. ИИ-производство стёрло его за один квартал.

Баги, которые это порождает, беззвучны. Задача «работает», но с небольшими отличиями от спецификации, поэтому в первый день ничего громко не ломается. А поскольку целого больше не понимал ни один человек, каждая ошибка всплывала только тогда, когда кто-то строил поверх предположения и сталкивался с реальностью.

ИИ сместил узкое место с написания кода на решение, безопасно ли его мержить

Узким местом поставки ПО никогда не была скорость набора кода. Им было согласование. Джин Амдал формализовал общий закон в 1967 году: ускорьте одну часть системы, и общий выигрыш останется ограничен теми частями, которые вы не ускорили. ИИ ускорил производство. Он не ускорил последовательную часть поставки: ревью, QA, интеграцию и сверку. И это хуже, чем потолок, потому что ускоренное производство вливает больше работы именно в ту часть, которая не масштабировалась.

Телеметрия Faros AI по более чем 10 000 разработчиков в 1 255 командах показывает ровно эту картину: команды с высоким внедрением ИИ мержили на 98% больше пул-реквестов, при этом время ревью выросло на 91%. По тому же набору данных внедрение ИИ было связано с ростом размера PR на 154% и с увеличением числа багов на разработчика на 9%. На уровне компании Faros не нашла значимого улучшения ни по одной метрике, включая DORA. Узкое место сместилось с написания кода на решение, безопасно ли вливать его в основную ветку.

Ничто из этого не удивит тех, кто читал исследования DORA: работа маленькими партиями входит в число самых сильных предикторов эффективности поставки, и упор там делается на маленькие изменения с быстрой обратной связью, а не на объём производимого кода. Компания ускорила ровно то, что DORA никогда не называла ограничением.

Ваш ИИ-стек: распределённая система без протокола консенсуса

Компания, где ИИ работает внутри каждого инструмента, представляет собой распределённую систему, и почти никто не снабжает эту систему протоколом консенсуса. В распределённых вычислениях есть имя для того, что я видел: split-brain. Разделите кластер, и, если обе половины продолжают принимать записи, каждая строит собственную версию истины. Инструмент дизайна, трекер задач, спецификация и кодовая база принимали записи быстрее, чем любой человек успевал их читать. Ничто их не сверяло.

Мелвин Конвей ещё в 1968 году сформулировал закон, который лежит в основе этого явления: «Любая организация, проектирующая систему (в широком смысле), произведёт проект, структура которого копирует структуру коммуникаций этой организации». Дайте каждому отделу собственный ИИ, и вы не почините фрагментацию, вы её автоматизируете.

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

Провал, который никто не измеряет: локально верно, глобально неверно

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

Ни один стандартный бенчмарк этого не ловит. Бенчмарки вроде MMLU и HELM тестируют одну модель на одной задаче. Не существует оценки, которая проверяла бы, согласованы ли между собой ваши пять точек контакта с ИИ насчёт одной и той же фичи. Практики уже чувствуют разрыв: в опросе Stack Overflow 2025 года среди более чем 49 000 разработчиков 84% используют или планируют использовать ИИ, но при этом больше разработчиков не доверяет его точности (46%), чем доверяет (33%). Главным раздражителем, который назвали 66% опрошенных, стал код «почти правильный, но не совсем», а 45% говорят, что отладка сгенерированного ИИ кода отнимает больше времени. Почти правильное выглядит изнутри ровно как верное локально и несогласованное глобально.

Что чинит поставку, замедленную ИИ: сверка на машинной скорости

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

Это решение тоже измерено, но с оговоркой, которую стоит назвать сразу. В препринте 2026 года Диллон и Варанаси проверили кодинг-агента на 41 командном решении в одном репозитории и подняли соответствие с 46% до 95%. Оговорка: они сами разрабатывают тот инструмент контекста, который тестировали, а выигрыш дал целый пакет из задокументированных решений, сгенерированной спецификации и консультаций по ходу работы, так что ни один компонент по отдельности заслугу не забирает. То, что переживает эту оговорку, это один случай из их таблицы по решениям. В репозитории лежали две функции аудита, и правило SOC-2 делало обязательной при экспорте ровно одну из них. Само правило не было записано нигде, куда агент мог дотянуться. Когда ему велели проследить, чтобы действие залогировалось, он пошёл искать, нашёл функцию аудита и взял не ту, а это различие, по словам авторов, требует понимания, зачем нужная функция вообще существует. Обе функции он прочитать мог. Договорённость о том, какую из них выбрала команда, прочитать не мог. Поиск сам по себе эту дыру не закрывает, потому что поиск находит похожий текст, но не управляет истиной (на английском).

Что требовать от слоя контекста

Прежде чем покупать следующий ИИ-инструмент, задайте команде один вопрос: где все наши ИИ читают то, что истинно? Слой контекста заслуживает этой роли, только если делает четыре вещи. Сводит разные имена одной и той же реальной сущности воедино. Отслеживает происхождение, чтобы каждый факт вёл к источнику. Придерживает или помечает спорные факты вместо того, чтобы смешивать их в один уверенный ответ. И располагается под инструментами, которые вы уже используете, чтобы агенты читали его первым, через стандартный интерфейс вроде MCP.

Большинство продуктов этой категории работает по облачной подписке на чужой инфраструктуре. LoomSignal представляет собой наш ответ именно для цикла поставки: локальный слой контекста, общий для ваших ИИ-инструментов, работающий на ваших серверах и оплаченный один раз. Он очищает сырые сигналы через уровни Bronze, Silver и Gold, чтобы агент опирался только на контекст, прошедший шлюз governance.

Реальное ускорение получат не те компании, у которых самая умная модель, а те, чьи инструменты согласны в том, что истинно.