ИИ пишет код в пять раз быстрее. Почему бизнес почти ничего не замечает?

Кодовые ИИ‑агенты уже способны за минуты выполнять часть работы, на которую раньше уходили часы. Но быстро написанный код — ещё не выпущенный продукт и тем более не полученная прибыль.

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

Разработчик получает задачу утром.

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

Но затем задача два дня ожидает код‑ревью. Ещё неделю — решения службы безопасности. После этого она попадает в следующее релизное окно.

На рабочем месте разработчика произошло почти чудо. На уровне компании — почти ничего.

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

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

Главный вопрос теперь должен звучать не так:

Насколько быстрее ИИ пишет код?

Гораздо важнее спросить:

Насколько быстрее организация превращает идею в проверенное, безопасное и полезное изменение?

В пять раз быстрее — но что именно ускорилось?

Фраза «производительность выросла в пять раз» кажется точной, хотя на самом деле почти ничего не сообщает без определения объекта измерения.

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

Это разные уровни. Между ними нет автоматического перехода.

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

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

Для продукта важна не готовность запроса на слияние — pull request, — а появление работающей возможности у пользователя. Для бизнеса результатом становятся выручка, экономия, снижение риска, увеличение числа проверенных гипотез или запуск проектов, которые прежде не окупались.

ИИ способен дать десятикратное ускорение отдельной операции и почти не изменить экономический результат.

Это не парадокс, а нормальное поведение сложной производственной системы.

Что показывают исследования

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

GitHub Copilot: 55,8% на одной стандартизированной задаче

В контролируемом эксперименте разработчикам предложили как можно быстрее реализовать HTTP‑сервер на JavaScript. Участники, получившие доступ к GitHub Copilot, завершили эту конкретную задачу на 55,8% быстрее контрольной группы.

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

Корректный вывод: в контролируемом эксперименте GitHub Copilot заметно ускорил выполнение конкретной стандартизированной задачи.

Некорректно превращать этот результат в утверждение, что все разработчики с Copilot становятся на 55,8% продуктивнее.

Первоисточник: The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.

Google: около 21% на сложной корпоративной задаче

В рандомизированном контролируемом эксперименте участвовали 96 штатных инженеров Google. Они выполняли сложную корпоративную задачу с внутренними ИИ‑инструментами или без них.

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

Корректный вывод: в эксперименте с 96 инженерами Google внутренние ИИ‑инструменты сократили время выполнения конкретной корпоративной задачи примерно на 21%.

Это не означает, что вся разработка в Google или любой другой компании автоматически ускоряется на 21%.

Первоисточник: How much does AI impact development speed? An enterprise‑based randomized controlled trial.

METR 2025: опытные разработчики работали на 19% дольше

В исследовании METR приняли участие 16 опытных разработчиков открытого программного обеспечения. Они выполнили 246 реальных задач в зрелых репозиториях, с которыми были хорошо знакомы.

В этих конкретных условиях разрешение использовать ИИ увеличило время выполнения задач в среднем на 19%. До эксперимента участники ожидали ускорения на 24%, а после него полагали, что ускорились примерно на 20%, хотя измерения показали обратное.

Этот результат нельзя обобщать на всю профессию. Исследование охватывало опытных разработчиков, зрелые open‑source‑проекты, знакомые кодовые базы, задачи средней продолжительностью около двух часов и инструменты уровня февраля‑июня 2025 года.

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

Корректный вывод: в эксперименте METR опытные разработчики, работавшие в знакомых зрелых open‑source‑проектах с инструментами начала 2025 года, выполняли выбранные задачи с ИИ на 19% дольше.

Формулировка «ИИ замедляет программистов на 19%» была бы некорректной.

Первоисточники: исследование METR и научная версия на arXiv.

METR 2026: оценки изменились, но результат остаётся неопределённым

В продолжении исследования, начатом во второй половине 2025 года, METR получила другие точечные оценки:

• около 18% ускорения для части участников первоначального эксперимента;

• около 4% ускорения для новых участников.

Однако доверительные интервалы обеих оценок пересекали ноль. Собранные данные совместимы и с ускорением, и с отсутствием эффекта, и с небольшим замедлением.

Кроме того, исследователи обнаружили серьёзные методологические проблемы. Разработчики, особенно высоко оценивающие пользу ИИ, чаще не хотели участвовать в задачах, где использование агентов могло быть запрещено. Участники исключали некоторые особенно подходящие для ИИ задачи, параллельная работа с несколькими агентами затрудняла учёт времени, а изменение ставки оплаты могло повлиять на состав выборки.

Корректный вывод: точечные оценки указывали примерно на 4% и 18% ускорения для разных групп, но результат оказался статистически неопределённым и существенно искажён самоотбором участников и задач.

Эти цифры нельзя использовать как доказательство того, что современные агенты гарантированно ускоряют разработчиков на 4–18%.

Первоисточник: METR — We are Changing our Developer Productivity Experiment Design.

Метаанализ 2026 года: умеренный эффект и огромная неоднородность

В мае 2026 года на arXiv был опубликован научный препринт, объединивший 23 исследования и 27 рассчитанных размеров эффекта.

Авторы обнаружили статистически значимый, но умеренный положительный эффект ИИ‑помощников на производительность программирования: Hedges“ g = 0,33. Одновременно неоднородность результатов между исследованиями оказалась крайне высокой.

В контролируемых лабораторных экспериментах эффект был значительно выше, чем в корпоративной и open‑source‑разработке. В корпоративной и open‑source‑среде оценки были существенно меньше и статистически не отличались от нуля.

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

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

Первоисточник: A meta‑analysis of the effect of generative AI on productivity and learning in programming.

Что можно заключить из исследований

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

• ограниченная стандартизированная задача может ускориться значительно;

• сложная корпоративная задача — умеренно;

• опытный разработчик в знакомой зрелой системе может не получить выигрыша;

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

• лабораторные результаты обычно выше, чем результаты в реальной организационной среде.

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

Куда исчезает локальное ускорение

Рассмотрим упрощённый пример.

До внедрения ИИ задача проходила четыре этапа:

Теперь предположим, что программирование и значительная часть технической проверки ускорились в пять раз:

Два технических этапа ускорились в пять раз. Но полный цикл сократился только с 60 до 36 часов — приблизительно в 1,67 раза, а не в пять.

Причину можно объяснить логикой закона Амдала: максимальный выигрыш всей системы ограничивается долей процесса, которую удалось ускорить. Сам закон был сформулирован для вычислительных систем; здесь он используется как аналитическая аналогия, а не как отдельное эмпирическое доказательство поведения компаний.

После изменений анализ, согласования и внедрение занимают 30 из 36 часов — более 83% полного цикла. Даже если программирование и техническое тестирование сделать мгновенными, задача всё равно будет занимать 30 часов.

ИИ почти убрал производство кода из критического пути. Но организационная часть процесса осталась прежней.

Первоисточник по закону Амдала: Gene M. Amdahl — Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities.

ИИ не устраняет узкое место — он передвигает его

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

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

Агент хорошо работает с тем, что можно выразить через формальные правила:

• запустить тесты и проверить типы;

• найти известную уязвимость;

• оценить покрытие и выявить регрессию;

• сравнить результат со спецификацией;

• проверить стиль и проанализировать изменения.

Гораздо труднее автоматизировать вопросы другого порядка:

• правильно ли понята бизнес‑задача;

• решает ли функция реальную проблему пользователя;

• соответствует ли решение стратегии продукта;

• допустим ли риск;

• можно ли доверять результату в критической системе;

• стоит ли вообще выпускать функцию;

• кто примет ответственность за последствия.

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

Плохая задача, выполненная в пять раз быстрее, не превращается в хороший продукт. Она лишь быстрее создаёт неправильное решение.

ИИ усиливает существующую производственную систему

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

Эти выводы нельзя представлять как строгое доказательство причинности. DORA — крупное отраслевое исследование, использующее в том числе опросные и наблюдательные данные. Выявленные связи показывают, какие характеристики встречаются вместе, но сами по себе не доказывают, что именно использование ИИ вызвало конкретное изменение производительности.

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

Представим две компании, купившие одинаковые кодовые агенты.

В первой компании ускорение проходит через весь поток. Во второй оно заканчивается у входа в очередь.

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

Источники: DORA State of AI‑assisted Software Development 2025 и официальная страница отчёта Google Cloud.

Agent‑native компания и ИИ, добавленный в старый процесс

Противопоставление agent‑native организации и традиционной компании используется здесь как аналитическая концепция. Это не общепринятая научная классификация, а способ наглядно показать, как устройство производственного процесса влияет на результат внедрения агентов.

В традиционной компании цепочка может выглядеть так:

задача → подготовка технического задания → согласование → постановка в спринт → программирование → код‑ревью → тестирование → безопасность → согласование релиза → релизное окно

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

В agent‑native модели процесс изначально проектируется с учётом машинных исполнителей:

формулирование проверяемой задачи → предоставление контекста → параллельная работа агентов → автоматические проверки → ответственное человеческое решение → небольшой безопасный релиз → обратная связь

Это не означает отказ от контроля. Наоборот, проверки могут быть жёстче. Но они встроены в поток, стандартизированы и по возможности автоматизированы, а не добавлены в конце в форме новой очереди.

Системный эффект возникает не в момент покупки лицензий. Он появляется после изменения способа производства программного обеспечения.

Где эффект заметен уже сейчас

Первый результат ИИ редко выглядит как пятикратный рост выручки. Обычно он проявляется раньше и тише.

Быстрее появляется первый рабочий вариант

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

Снижается стоимость проверки гипотезы

Если идею можно проверить дешевле, компания раньше узнаёт, что она не работает. Экономический эффект заключается не только в ускорении успешных проектов, но и в более раннем отказе от неудачных.

Начинают окупаться маленькие задачи

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

Ускоряется работа с незнакомым кодом

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

Высвобождённое время направляется на качество

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

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

Возникает больше параллельных экспериментов

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

Быстрее устраняются инциденты

Анализ логов, поиск связанного изменения и подготовка гипотезы исправления занимают меньше времени. Эффект проявляется не в новых функциях, а в сокращении простоя.

Появляются проекты, которых раньше не существовало

Компания не просто делает старые задачи дешевле. Она начинает создавать узкоспециализированные решения, которые раньше вообще не проходили порог экономической целесообразности.

Почему эффект может долго оставаться невидимым

Выигранное время не направили на новый результат

Разработчик закончил задачу раньше, но следующая ещё не согласована. Локальная экономия времени возникла, а пропускная способность системы не изменилась.

Ускорилась реализация, но не принятие решений

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

Объём изменений вырос быстрее способности их проверять

Один разработчик теперь способен создавать больше кода, тестов и вариантов. Если финальное человеческое ревью не масштабируется, очередь может стать длиннее.

Высвобождённое время заполнили встречами

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

Продукт стал сложнее, а сроки остались прежними

Команда могла использовать выигрыш не для сокращения календарного срока, а для увеличения функциональности, надёжности или безопасности.

ИИ переносит стоимость в будущее

Быстро полученный код может формально работать, но плохо вписываться в архитектуру. Если команда не понимает созданное решение, будущая стоимость сопровождения растёт.

Измеряется занятость, а не результат

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

Рынок и пользователи не ускорились

Клиенту может требоваться несколько месяцев на закупку. Регулятору — полгода на согласование. Пользователям — недели на освоение новой функции.

Технологическая скорость упирается в скорость организаций и институтов.

Когда бизнес почувствует эффект

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

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

На первых неделях эффект преимущественно локальный. Его первыми замечают сами разработчики.

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

Через три‑двенадцать месяцев компания способна автоматизировать проверки, улучшить непрерывную интеграцию и доставку — CI/CD, — уменьшить размер изменений, ускорить обратную связь и пересмотреть полномочия команд. Только тогда локальная скорость начинает превращаться в более частые полезные релизы и снижение стоимости эксперимента.

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

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

Что действительно нужно измерять

Одна метрика почти неизбежно создаёт искажённое поведение. Поэтому систему показателей нужно строить по нескольким уровням.

Именно на уровне отдельной операции обычно виден самый большой выигрыш. Но ускорение операции ещё не является производительностью бизнеса.

Для командного потока особенно важно разделять два вопроса:

1. Сколько времени над задачей действительно работали?

2. Сколько времени она ожидала человека, среды, доступа или решения?

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

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

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

Главная метрика: какую подтверждённую ценность команда создаёт за единицу времени, бюджета и принятого риска?

Почему строки кода больше не работают как метрика

Количество строк кода всегда было слабым показателем производительности. В эпоху генеративного ИИ оно становится ещё опаснее.

Агент способен создавать большие объёмы кода почти мгновенно. Если оценивать команду по количеству произведённого текста, система начнёт поощрять объём, а не результат.

При этом хороший инженер нередко создаёт ценность, удаляя код: упрощает систему, устраняет дублирование, заменяет несколько компонентов одним, удаляет устаревшую функциональность и сокращает поверхность ошибок.

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

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

Как провести честный эксперимент

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

Затем:

1. Соберите исходные данные до активного внедрения ИИ.

2. Сравнивайте задачи сопоставимой сложности.

3. По возможности случайно распределяйте задачи между режимами с ИИ и без него.

4. Измеряйте полный путь до стабильной эксплуатации, а не только написание кода.

5. Отдельно учитывайте активную работу и ожидание.

6. Измеряйте время автора и время проверяющего.

7. Учитывайте исправления и повторную работу.

8. Проверяйте качество спустя несколько недель после релиза.

9. Используйте медиану и 90-й перцентиль — p90, — а не только среднее значение.

10. Учитывайте риск, новизну и количество затронутых систем.

11. Не заменяйте объективные показатели самооценкой сотрудников.

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

13. Завершите эксперимент оценкой экономического и пользовательского результата.

Плохой итог пилота звучит так:

ИИ повысил нашу производительность в три раза.

Хороший — так:

После периода обучения медианное время полного цикла типовых интеграций сократилось на 24%. Время ожидания код‑ревью не изменилось. Количество дефектов за 60 дней не выросло. Стоимость проверки одной гипотезы уменьшилась на 31%.

Такой вывод выглядит скромнее рекламного лозунга. Но именно на нём можно строить управленческое решение.

Как изменится профессия разработчика

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

• от написания строк — к управлению намерением;

• от ручной реализации — к декомпозиции;

• от поиска синтаксиса — к выбору архитектуры;

• от создания одного решения — к сравнению нескольких;

• от ручной проверки деталей — к проектированию системы проверок;

• от локального патча — к оценке последствий для всей системы;

• от индивидуального исполнителя — к руководителю цифровых исполнителей.

Но здесь возникает важная ловушка. Чем меньше инженер пишет самостоятельно, тем труднее ему заметить тонкую ошибку в убедительно выглядящем результате.

Поэтому знание программирования не теряет ценности. Оно постепенно превращается из инструмента ручного производства в инструмент постановки задач, контроля и принятия решений.

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

Не скорость рук, а скорость системы

Кодовые агенты действительно могут радикально ускорять отдельные операции.

Но код — это не продукт.

Продукт — это изменение, которое решило проблему пользователя, безопасно работает в реальной среде и создало измеримую ценность.

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

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

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

И одновременно обнаружили: самое медленное в разработке — далеко не всегда код.

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

Источники

1. Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.

2. Elise Paradis и соавторы. How much does AI impact development speed? An enterprise‑based randomized controlled trial.

3. Joel Becker, Nate Rush, Beth Barnes, David Rein. Measuring the Impact of Early-2025 AI on Experienced Open‑Source Developer Productivity.

4. Научная версия исследования METR 2025 года: arXiv:2507.09089.

5. Joel Becker, Nate Rush, Tom Cunningham, David Rein, Khalid Mahamud. We are Changing our Developer Productivity Experiment Design.

6. Sebastian Maier, Moritz Gunzenhäuser, Jonas Schweisthal, Manuel Schneider, Stefan Feuerriegel. A meta‑analysis of the effect of generative AI on productivity and learning in programming — препринт.

7. DORA. State of AI‑assisted Software Development 2025.

8. Google Cloud. Announcing the 2025 DORA Report.

9. Gene M. Amdahl. Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities.