Что именно подешевело
Генеративные модели и агенты на их основе действительно сломали старое соотношение цены и скорости написания кода. Прототипы, интерфейсы, тесты, миграции баз данных, документация — всё это теперь производится на порядки быстрее, чем пять лет назад. Это не иллюзия маркетинга: любой, кто наблюдал, как агент за вечер собирает работающее приложение, видел реальный эффект.
Проблема в том, что лёгкость демонстрации и надёжность продукта — разные категории. Сгенерированный код может безупречно работать на контролируемом примере и ломаться при параллельных запросах, нестандартных данных, смене требований или простом повторе запроса после сетевого таймаута. Разница между «работает в демо» и «можно доверить продакшену» — это и есть то пространство, где всегда жила экономическая ценность инженерной работы, и именно оно пока не поддалось автоматизации в той же степени, что и написание строк.
Показательный пример — функция перевода денег между счетами. Модель за секунды пишет код, который проходит тесты и корректно обрабатывает очевидный случай. Но в нём отсутствует защита от повторного списания при повторе запроса, от гонки при одновременных переводах, от отрицательной суммы, от разной валюты счетов — список дефектов, которые проявятся не в демонстрации, а в проде. Инженерная версия того же кода длиннее черновой в разы не потому, что писать её сложнее, а потому что нужно заранее знать, какие именно десять пунктов проверки должны там оказаться. Строки стали дешёвыми. Список того, что нужно учесть, — нет.
Разрыв между коммитами и релизами
Самое прямое подтверждение этому механизму дало масштабное исследование более 100 тысяч разработчиков на GitHub, которое проследило эффект трёх поколений инструментов — от автодополнения до автономных агентов. На уровне коммитов рост был огромным: автодополнение увеличило активность примерно на 40%, интерактивные агенты — на 140%, автономные агенты — почти на 180%.
А вот дальше эффект начал стремительно таять. Тот же прирост в 180% на уровне коммитов превратился лишь в примерно 50% прироста завершённых проектов и около 30% прироста фактических релизов. На уровне использования приложений в маркетплейсах — заметного роста вообще не зафиксировано: появилось больше новых приложений, но не больше пользователей.
flowchart TD A["Генерация кода +180%"] --> B["Ревью и проверка"] B --> C["Интеграция с системой"] C --> D["Решение о релизе +30%"] D --> E["Использование клиентами"]
Каждая стрелка на этой схеме — не технический переход, а точка, где требуется человеческое суждение: оценить, правильно ли написан код, совместим ли он с остальной системой, достаточно ли он надёжен, чтобы его выпускать. Ни один из этих шагов не ускорился пропорционально генерации, потому что ресурс, который их ограничивает — внимание, опыт и время квалифицированных людей, — не вырос вместе с объёмом кода.
Авторы исследования формализуют это как «гипотезу слабого звена»: оценённая эластичность замещения между усилиями AI и человека составила около 0,25 — значение заметно ниже единицы, что означает сильную взаимодополняемость, а не взаимозаменяемость. Проще говоря: нельзя компенсировать нехватку ревью или интеграционной экспертизы просто за счёт увеличения объёма сгенерированного кода — это два разных ресурса, и дефицит одного не лечится избытком другого.
Почему к самой цифре 180% нужно относиться осторожно
Здесь важна оговорка, которую легко упустить за красивой арифметикой. Коммит — это единица поведения разработчика, а не единица кода: агент, работающий пошагово, естественно порождает больше коммитов на ту же задачу, чем человек, фиксирующий результат одним действием в конце. Часть прироста в 180% может быть артефактом самого способа измерения, а не реальным увеличением объёма построенного. Это не отменяет направление эффекта — соотношение сгенерированных артефактов к выпущенным релизам действительно выросло, — но превращает конкретный коэффициент «в два с лишним раза» скорее в верхнюю оценку, чем в точное измерение.
Стоит добавить и ограничение по выборке: исследование охватывает открытые репозитории на GitHub, а не закрытую корпоративную разработку с её процессами согласования, комплаенсом и легаси-системами. Перенос этих цифр напрямую на «всю индустрию» — это уже интерпретация, а не то, что измерил сам эксперимент.
Где AI реально экономит время, а где создаёт новую нагрузку
Чтобы не путать «код стал дешевле» с «разработка стала дешевле», полезно развести задачи по тому, насколько они поддаются автоматизации сегодня.
| Тип работы | Что происходит с AI | Кто остаётся узким местом |
|---|---|---|
| Написание шаблонного кода, прототипов, тестов-заглушек | Сильное ускорение | Почти не требуется человек на этом шаге |
| Ревью корректности и безопасности | Слабое ускорение | Нужен эксперт, способный оценить риск |
| Архитектурные решения, выбор компромиссов | Минимальное ускорение | Нужен человек с пониманием долгосрочных последствий |
| Сбор и уточнение требований | Минимальное ускорение | Нужен человек, умеющий говорить с заказчиком |
| Интеграция с легаси-системами | Слабое ускорение | Нужен человек, знающий историю и ограничения системы |
| Решение о релизе и ответственность за него | Практически не затронуто | Человек принимает решение и несёт риск |
Разрыв между верхней и нижней частью таблицы — это и есть то самое «слабое звено». Автоматизация максимально ускорила верхний слой задач: написание синтаксиса по чёткому ТЗ. Но именно нижний слой — суждение, проверка, ответственность — всегда определял, сколько стоит инженерная работа, и его объём автоматизация пока не уменьшила.
Контрпример, который не стоит игнорировать
Честный разбор требует и обратного кейса. Отдельное контролируемое исследование с участием опытных разработчиков открытого кода, работавших над реальными задачами в знакомых им крупных репозиториях, показало обратный эффект: с доступом к AI-инструментам разработчики тратили на решение задач на 19% больше времени, а не меньше. При этом сами участники до и после эксперимента были уверены, что AI их ускорил примерно на 20% — расхождение между ощущением и фактическим результатом оказалось почти зеркальным.
Авторы прямо предупреждают: это не доказательство того, что AI бесполезен в разработке в целом — речь именно о сценарии, где от разработчика требуется глубокое знание большой, зрелой кодовой базы с высокими стандартами качества, а не о задачах для новичков или в незнакомом окружении. Это важная деталь: эффект от AI-инструментов сильно зависит от типа задачи, опыта исполнителя и сложности системы, и ни одно из крупных исследований не претендует на универсальный вердикт для всех контекстов.
Вместе два источника — массовое наблюдение за 100 тысячами разработчиков и контролируемый эксперимент с опытными мейнтейнерами — рисуют одну и ту же фигуру с разных ракурсов: там, где задача хорошо очерчена и не требует глубокого контекста, AI ускоряет работу заметно; там, где нужно понимание сложной системы и высокая планка качества, выигрыш может оборачиваться потерей времени на проверку и исправление сгенерированного.
Что из этого следует на практике
Главная ошибка — измерять успех внедрения AI объёмом произведённого кода или активностью в репозитории. Рост числа коммитов или новых прототипов — это метрика деятельности, а не метрика результата: она ничего не говорит о том, дошло ли изменение до пользователя и принесло ли ему пользу. Бизнес-ценность создаётся не на этапе генерации, а на этапах ревью, интеграции, релиза и последующей поддержки — и ни один из них не стал автоматически быстрее просто потому, что код стало дешевле писать.
Это не история про исчезновение профессии и не история про то, что AI-инструменты бесполезны. Это история про перераспределение ценности внутри самого процесса разработки: синтаксис подешевел, а умение правильно поставить задачу, отличить рабочий код от надёжного и взять на себя ответственность за решение о выпуске — подорожало. Команды, которые считают успехом рост объёма сгенерированного кода, скорее всего, измеряют не то, что в итоге определяет, получит ли пользователь рабочий продукт.
