Почему ускорение написания кода с помощью ИИ не меняет скорость разработки продукта

Но прод от этого не стал выезжать в пять раз быстрее: код застревает в ревью, безопасности, тестовых средах и релизных окнах. Очередной «AI productivity x5» разбивается о обычную корпоративную трубу. Никакой магии, просто bottleneck переехал.

Скорость генерации — не скорость поставки

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

Дальше начинается реальная разработка. Нужно понять требования, раскопать старую кодовую базу, выбрать решение, проверить побочные эффекты, договориться с соседними командами. Потом PR ждёт ревью. Затем security review. Затем свободный слот в релизном календаре. И вот «сэкономили час» превращается в «два дня ждём апрув».

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

Хабр приводит показательный контраст: в контролируемом эксперименте с реализацией HTTP-сервера на JavaScript участники с GitHub Copilot завершили конкретную задачу на 55,8% быстрее контрольной группы. Это говорит о скорости решения ограниченной стандартизированной задачи. Не о том, что весь отдел внезапно стал производительнее на те же 55,8%. Между HTTP-сервером и продом, как обычно, лежит кладбище интеграций.

Метрика «строк в минуту» — костыль для отчёта

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

Смотреть стоит на весь маршрут изменения: от появления идеи до работающей возможности у пользователя. Где висит задача после генерации? Сколько времени занимает ревью? Сколько — проверки безопасности? Есть ли очередь на стейдж? Отваливаются ли изменения на интеграции? Возвращаются ли PR на доработку, потому что агент уверенно закодил не то?

Тот же принцип работает в инфраструктуре. Можно за секунды сгенерировать конфиг, Terraform-модуль или клиент для API — а потом неделю искать, почему в проде выросли таймауты. В системах с высокой нагрузкой ценность часто не в самом коде, а в корректно выбранной точке интеграции, лимитах, наблюдаемости и отказоустойчивости. Даже при выборе RPC-узлов Solana для быстрых транзакций решает не скорость написания клиента, а поведение всей цепочки под нагрузкой.

ИИ не убирает системные ограничения. Он просто быстрее доставляет код к следующему ограничению.

Где искать эффект без презентационных цифр

Практический сценарий простой: не раскатывать агента на весь бэклог и не объявлять победу по числу закрытых тикетов. Возьмите повторяемый тип задач: тесты, миграции, CRUD-ручки, документацию, типовые SQL-запросы. Замерьте время от постановки до прода, количество возвратов с ревью, дефекты после релиза и время ожидания между этапами.

Если генерация ускорилась, а цикл поставки нет — чинить надо не промпт. Надо разбирать очередь, правила ревью, тестовый контур и релизный процесс. Иначе ИИ становится дорогим костылём: он печатает код быстрее, команда быстрее создаёт очередь, а бизнес снова видит прежний throughput.

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