ИИ-инструменты не ускорили разработку — потому что код никогда не был узким местом

Индустрия потратила миллиарды на ИИ-инструменты для разработчиков. GitHub Copilot, Cursor, Codeium, десятки других ассистентов пишут код за секунды. Но поставки программного обеспечения быстрее не стали. Время от коммита до продакшена в крупных компаниях по-прежнему измеряется неделями и месяцами. Николь Форсгрен, автор книги Accelerate и создатель метрик DORA, объясняет почему: код никогда и не был узким местом.

В своём докладе на QCon San Francisco в марте 2026 года Форсгрен представила концепцию "AI Productivity Paradox" — парадокса ИИ-продуктивности. Суть проста: если узкое место было не в написании кода, то ускорение написания кода ничего не даст. А если и даст — то лишь создаст ещё большее давление на те части процесса, которые и без того задыхались.

ИИ-ассистенты для программирования — это инструменты, которые используют большие языковые модели для автодополнения кода, генерации функций по описанию на естественном языке, рефакторинга и объяснения кода. Самые известные — GitHub Copilot, Cursor, Codeium и Claude Code. Их общее обещание — кратный рост продуктивности разработчиков. По данным маркетинговых материалов, разработчики пишут код "на 55% быстрее" или "в 2 раза продуктивнее". Но что именно считается продуктивностью?

Ключевые выводы

— ИИ-ассистенты ускоряют написание кода, но не ускоряют доставку программного обеспечения — потому что написание кода занимает лишь малую часть от времени полного цикла разработки
— Настоящие узкие места — CI/CD-пайплайны, код-ревью, ручные согласования, тестирование и деплой — не затрагиваются ИИ-ассистентами
— По метрикам DORA, высокопроизводительные команды деплоят несколько раз в день с lead time менее суток — и это результат системной работы с процессами, а не с инструментами генерации кода
— Фреймворк DevEx (feedback loops, flow state, cognitive load) помогает найти настоящие точки трения
— Вместо покупки нового ИИ-инструмента стоит провести аудит процесса доставки: где теряется время, почему, и как это устранить

Парадокс ИИ-продуктивности

"Мы можем генерировать код за минуты, за секунды, — говорит Форсгрен. — Люди из любых подразделений могут "вайб-кодить" приложение и запушить его. Но деплой по-прежнему занимает дни. Я написала тут "дни" — это я была оптимисткой. Обычно это месяцы".

Парадокс в том, что ИИ не просто не решает проблему доставки — он делает её более заметной и болезненной. Когда код генерируется быстрее, очереди на код-ревью растут. CI-пайплайны захлёбываются. Тестовые наборы не справляются с нагрузкой. Форсгрен формулирует это так: "ИИ усиливает те же проблемы, которые существовали и раньше. Только теперь — быстрее".

Она приводит два показательных примера. В 2012 году в Knight Capital инженер выполнил рутинный деплой. Скрипт развёртывания реактивировал старый feature flag. Деплой был ручным. Автоматических тестов не было. За 45 минут компания потеряла 460 миллионов долларов. А в начале 2026 года разработчик по имени Джейсон использовал ИИ-ассистент Replit для работы с базой данных. Он явно указал: "никаких изменений в live-данных". Установил code freeze. Результат? "Новые инструменты — те же старые проблемы. Только теперь быстрее".

Почему код — не узкое место

Форсгрен разделяет процесс разработки на "внутренний цикл" (inner loop) и "внешний цикл" (outer loop). Внутренний цикл — это то, что происходит на машине разработчика: написание кода, локальная отладка, запуск тестов. Внешний цикл — всё остальное: CI/CD-пайплайны, код-ревью, тестирование, согласования, деплой.

ИИ-инструменты ускоряют внутренний цикл. Но внешний цикл — где на самом деле теряется время — они не затрагивают.

"Написание кода больше не является узким местом, — подчёркивает Форсгрен. — Мы можем генерировать сколько угодно кода. Но это делает остальные точки трения ещё дороже и заставляет их торчать ещё сильнее. Справляются ли наши тестовые наборы с такой нагрузкой? Справляются ли наши CI-пайплайны? Могу ли я ревьюить достаточно пулл-реквестов для всего того шлака, который валится в систему? Не всегда".

Вот из чего складывается "невидимое" время доставки, которое ИИ не трогает:

• Код-ревью — пулл-реквесты висят днями, потому что назначены не тому человеку, застряли в очереди или ревьюер в отпуске
• CI/CD-пайплайны — сборка падает, flaky-тесты, зависимости между сервисами
• Ручные согласования — деплой требует координации нескольких команд, инструментов, групповых решений о рисках
• Тестирование — автоматических тестов недостаточно, а ручное тестирование не масштабируется
• Онбординг — новый сотрудник на третьей неделе всё ещё ждёт доступ к базе данных
• "Не моя зона ответственности" — задачи буксуют на стыках между командами, процессами и системами

Что говорят данные

DORA (DevOps Research and Assessment) — это фреймворк из четырёх метрик, который Форсгрен разработала для измерения эффективности доставки ПО. Две метрики отвечают за скорость, две — за стабильность:

• Deployment frequency — как часто команда деплоит в продакшен
• Lead time for changes — сколько времени проходит от коммита до запуска в продакшене
• Change failure rate — какой процент изменений требует отката или вмешательства
• Mean time to restore (MTTR) — как быстро команда восстанавливает сервис после сбоя

У высокопроизводительных команд показатели выглядят так: деплой несколько раз в день (или по потребности бизнеса, а не из-за технических ограничений), lead time менее суток, change failure rate около 5%, восстановление после сбоя — менее часа.

"Эти команды не просто везучие, — говорит Форсгрен. — Они системно устранили трение". И она отмечает важный нюанс: это работает в компаниях любого размера и любой отрасли. Крупные компании говорят: "Это только для стартапов — у них нет нашего регулирования". Стартапы говорят: "Это только для крупных — у них ресурсы". Данные показывают, что и те, и другие неправы.

При этом ИИ-инструменты усиливают давление на внешний цикл. Форсгрен отмечает, что многие команды удваивают инвестиции во внутренний цикл (ещё больше ИИ-инструментов, ещё быстрее генерация), игнорируя тот факт, что внешний цикл "по-прежнему так же медленный, а может, и ещё медленнее".

Отдельно Форсгрен обращает внимание на метрику "строки кода" (lines of code): "Это всегда была бесполезная метрика. ИИ наконец-то сделал это очевидным для всех, потому что теперь кода генерируется слишком много. Он чрезмерно многословный, полон избыточных комментариев. Иногда лучшее, что можно сделать — это удалить код".

Где реально теряется время

Форсгрен приводит конкретные цифры стоимости трения. По данным McKinsey, 40% бюджетов на разработку уходят на устранимый "rework" — переделки, которых можно было избежать. Другое исследование показало, что разработчики ощущают свою продуктивность на уровне 68,5% — а недостающие 31,5% обходятся мировой экономике в 300 миллиардов долларов потерянного ВВП. Ещё одна оценка: 1,52 триллиона долларов теряется ежегодно из-за технического долга.

Форсгрен предлагает простую "расчётку на салфетке": 20 разработчиков, каждый теряет по 30 минут в день на одну точку трения. Это 10 часов в день, 2600 часов в год. При стоимости 100 долларов в час — 260 000 долларов в год. "Мы уже тратим это время, — говорит она. — Просто тратим его на борьбу с трением, а не на его устранение".

Типичные точки потери времени, которые ИИ-инструменты не затрагивают:

1. Медленная сборка — двухчасовой билд означает двухчасовое ожидание обратной связи. Разработчик переключает контекст, начинает параллельную задачу, теряет фокус
2. Процесс код-ревью — отсутствие чётких владельцев, ручное назначение, неравномерная нагрузка между ревьюерами
3. Ручные деплои — координация между командами, согласование рисков, ручные чек-листы
4. Flaky-тесты — нестабильные тесты подрывают доверие к CI-пайплайну и замедляют обратную связь
5. Процессные задержки — согласование с юристами, безопасниками, product-менеджерами, которое "всегда занимает столько времени"

Фреймворк DevEx — как найти настоящие проблемы

Вместо абстрактной "продуктивности" Форсгрен предлагает работать с Developer Experience (DevEx) — опытом разработчика. Фреймворк DevEx состоит из трёх измерений:

• Feedback loops (петли обратной связи) — сколько времени проходит от действия до результата? Сколько ждать, пока сборка завершится? Пока ревьюер ответит? Пока CI/CD-пайплайн отработает?
• Flow state (состояние потока) — может ли разработчик сосредоточиться на сложных задачах? Или его постоянно отвлекают переключения контекста, совещания, ожидание ответов?
• Cognitive load (когнитивная нагрузка) — сколько ментальной ёмкости уходит на "обслуживание" процесса? Исследования Глории Марк показывают, что максимум глубокой работы в день — около 4 часов. На что разработчик тратит эти 4 часа?

Эти три измерения взаимосвязаны. Быстрая обратная связь сохраняет flow state и снижает когнитивную нагрузку. Низкая когнитивная нагрузка позволяет сосредоточиться и принимать решения быстрее. Защищённый flow state ускоряет обучение и накапливает результаты со временем.

ИИ меняет динамику flow state (состояния потока), отмечает Форсгрен: "Раньше мы могли заблокировать часы для глубокой работы над кодом. Теперь мы не просто пишем код — мы промптим, тут же получаем обратную связь, принимаем код, ревьюим, переписываем. Это как Stack Overflow на стероидах".

Как начать: 7 шагов

Форсгрен и Аби Нода (CEO компании DX) выделили семь шагов, которые проходят сотни компаний при улучшении DevEx:

1. Поговорите с людьми — прежде чем собирать метрики, просто спросите разработчиков: "Что вас бесит каждый день?"
2. Начните с малого — выберите одну видимую, достижимую проблему, которую можно решить за недели, а не за кварталы
3. Соберите данные — системная телеметрия, опросы, метрики результатов
4. Приоритизируйте через RICE — Reach (охват) x Impact (влияние) x Confidence (уверенность) / Effort (усилия)
5. Продайте стратегию — переведите технические проблемы на язык долларов и бизнес-результатов
6. Внедряйте изменения — от локальных экспериментов в одной команде до масштабирования на всю организацию
7. Оцените и покажите ценность — документируйте результаты и делитесь ими

Форсгрен подчёркивает: начинать можно с любого шага в зависимости от зрелости организации. Но на любом этапе стоит "просто поговорить с несколькими людьми" — это самый быстрый и дешёвый способ получить достоверные данные.

RICE: как приоритизировать улучшения

Форсгрен рекомендует фреймворк RICE для выбора, какие проблемы решать первыми:

• Reach — сколько людей затронет улучшение?
• Impact — насколько сильно оно улучшит их работу?
• Confidence — насколько мы уверены, что это выполнимо?
• Effort — сколько усилий потребуется? (чем меньше, тем лучше)

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

FAQ

ИИ-ассистенты для кода совсем бесполезны?

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

Какие метрики использовать вместо "строк кода"?

Форсгрен рекомендует фреймворк SPACE: Satisfaction (удовлетворённость инструментами и процессами), Performance (качество результатов: pass rate тестов, частота сбоев), Activity (количественные метрики: PR, деплои — но не строки кода), Communication and Collaboration (взаимодействие: ревью, API-вызовы, совещания), Efficiency and Flow (время от действия до результата). Дополнительно — четыре метрики DORA для end-to-end доставки.

Как убедить руководство инвестировать в DevEx, а не в новые ИИ-инструменты?

Форсгрен приводит три стратегии. Первая — видимость и подотчётность: пример Дэйва Андерсона из Amazon, который создал ежемесячный отчёт для топ-менеджмента с рейтингом команд по ошибкам. "Через неделю директора бежали к нему в офис, чтобы убрать свою команду из списка". Вторая — простые данные с чёткими действиями: пример LinkedIn, где "Developer Insights Hub" не просто показывал метрики, а позволял детализацию до конкретной причины проблемы. Третья — перевод трения в доллары: пример Block, где посчитали стоимость каждой точки трения и сэкономили миллионы за 12 месяцев.

Что делать прямо сейчас — одно конкретное действие?

Для рядового разработчика — записывать в течение недели все моменты, когда теряется 30+ минут на "ерунду, которой не должно быть". Для тимлида — провести 30-минутную ретроспективу: "Что на этой неделе замедлило нас, но не было собственно работой?". Для руководителя — поговорить минимум с тремя людьми и посчитать стоимость трения "на салфетке".

Выводы

Главный тезис Форсгрен провокативен, но подкреплён данными: ИИ-инструменты для написания кода не ускорили доставку программного обеспечения, потому что написание кода никогда не было настоящим узким местом. Настоящие узкие места — это процессы, согласования, пайплайны, код-ревью и инфраструктура деплоя.

Организации, которые выигрывают в эпоху ИИ, не просто выдали всем Copilot или Cursor. Они системно устраняют трение, чтобы разработчики могли доставить код до клиента, провести эксперимент, получить обратную связь. "Все крупные компании, с которыми я работаю, — говорит Форсгрен, — сейчас активно ищут способы убрать это трение".

Вместо того чтобы покупать очередной ИИ-инструмент, стоит задать себе три вопроса: Что на самом деле замедляет доставку? Где разработчики теряют время на борьбу с процессом, а не на решение задач? И какое самое маленькое изменение может убрать самую большую точку трения?

Источник: From Friction to Flow: How Great DevEx Makes Everything Awesome — доклад Николь Форсгрен на QCon San Francisco, март 2026.