AI ускорил написание кода на 60%. Скорость поставки не выросла. Разбираемся почему [Разбор]
Вчера разговаривал с CTO одного продукта - команда 15 человек, активно используют Claude Code и Cursor больше года. CTO говорит: "Разработчики чувствуют, что стали в 10 раз быстрее. Но в спринте мы выкатываем столько же, сколько год назад". За последний месяц похожие фразы я услышал от пяти разных технических лидеров. Это уже не совпадение, это паттерн.
В статье - почему так происходит, какие данные есть по индустрии, и пять конкретных рычагов, которые реально влияют на скорость поставки. Без волшебных таблеток и без хайпа.
Написание кода никогда не было главным узким местом. Мы просто этого не замечали
До AI картина выглядела примерно так: разработчик пишет фичу 4 часа, потом полдня ждет ревью, день уходит на правки, еще полдня на QA. Из суток жизненного цикла задачи код занимал 4 часа.
Теперь AI делает эти 4 часа за 10 минут. Все остальное осталось на месте.
Что в итоге? PR висит. Ревьюер - в собственном дип-ворке и не хочет переключать контекст. Ветка устаревает. Автор ребейзит. QA отбивает обратно. Автор уже взял задачу #3, теперь переключается обратно на #1. Умножьте это на 5 PR в день с одного разработчика - и вы получите ту же скорость поставки при удвоенной "субъективной продуктивности".
Что говорят данные по индустрии
Репорты 2026 года сошлись на трех цифрах:
- Output одного разработчика вырос на ~60% год к году по объему сгенерированного кода (Pragmatic Engineer, Plandek Engineering Productivity Benchmarks).
- Топ-квартиль команд мержит PR быстрее чем за 21 час. Нижний квартиль - больше 35 часов на тот же PR. Те же AI-инструменты, разные процессы.
- PR от AI-агентов ждут ревью в 4.6 раза дольше человеческих. Acceptance rate - 32.7% против 84.4%.
То есть AI не "сломал" процессы. Он сделал разрыв между быстрыми и медленными командами видимым на цифрах. До AI разница в процессах маскировалась тем, что код в любом случае писался долго.
Где скорость реально утекает
Жизненный цикл задачи - это не "написал код, замержил". Это:
- Взять задачу из бэклога
- Возможные согласования с PM или дизайном
- Написать код (теперь 10 минут вместо 4 часов)
- Поставить на ревью
- Ждать ревьюера
- Получить комментарии
- Переключиться обратно с уже взятой следующей задачи
- Внести правки
- Ребейзнуть устаревшую ветку
- Снова поставить на ревью
- Мерж
- QA
- Возможные баги обратно в работу
- Релиз
Написание кода - один шаг из 14. AI ускорил один шаг. Остальные 13 остались на тех же скоростях.
И есть еще один невидимый налог - переключение контекста. AI генерирует больше PR на разработчика, значит больше параллельных задач, значит больше переключений между ними. А переключение контекста разрушает deep work - то самое состояние, в котором инженеры действительно производительны. По исследованиям, возврат в deep work после прерывания занимает 15-25 минут. Десять прерываний в день - и от рабочего времени остается фикция.
Пять рычагов, которые реально работают
Что мы пробуем у себя и в командах клиентов, и что дает измеримый результат:
1. First-time-right вместо "пусть ревью поймает"
Каждый круг "ревью - правка - повторное ревью" стоит deep work двум людям. Цель - чтобы PR проходил с первого раза. Это требует, чтобы разработчик сам проверял работу перед отправкой: линтеры, тесты, прогон по чеклисту. AI здесь полезен - попросите его сделать self-review до отправки в команду.
2. Аудит реальной ценности code review
Сколько часов в неделю команда тратит на ревью? Какие баги оно реально ловит? Сколько из них могли действительно навредить бизнесу? Если 80% комментариев - про именование переменных и стиль, это работа для скрипта, не для сеньора с зарплатой за 300 тысяч.
3. AI ревьюит AI
CodeRabbit, Greptile, Diamond - инструменты, которые делают первый проход по PR за секунды и ловят типовые ошибки. Человеческое ревью остается только для того, что реально может ударить по бизнесу: критичная логика, безопасность, архитектурные решения.
4. Защита блоков deep work
Три непрерывных часа дают больше, чем восемь фрагментированных. Если разработчик жонглирует пятью PR в разных стадиях, он не делает ни одну задачу хорошо. Решение - блочный календарь: утро на собственный код, час во второй половине дня на ревью чужого.
5. Ограничение размера PR
PR больше 400 строк никто нормально не ревьюит. AI любит генерировать большие диффы - команда должна форсить дробление. Stacked PRs через Graphite или аналоги помогает.
Главный вывод
Все эти проблемы существовали и до AI.
Медленное ревью. Переключение контекста. Ручные проверки, которые ловят опечатки. Мы их терпели - разница между "медленным" и "быстрым" процессом была не такой заметной, когда сам код тоже писался медленно.
AI не сломал процесс. Он надавил на синяк, который мы старались не замечать годами.
Хорошая новость - наконец-то у бизнеса есть мотивация починить эти процессы. Разрыв между командами с одинаковыми Cursor и Copilot стал слишком большим, чтобы списать его на "ну, у них хорошие разработчики".
Если ваша команда купила лицензии и не видит ускорения в поставке - дело не в инструментах. Дело в том, что осталось вокруг них.