Аутентификация со схемой базы, API-роутами и юнит-тестами собирается за тридцать секунд. Дальше эта же фича идёт до продакшена три недели. Разрыв между скоростью генерации и скоростью релиза стал главным сюрпризом 2026 года для команд, которые уже поставили агентов в рабочий процесс. Код перестал быть дефицитом. Дефицит теперь в другом: в способности команды этот код понять, проверить и взять за него ответственность.

Разработчик по имени Harsh описал этот разрыв на dev.to в конце октября, и описал честно: он сам попался. Фича на пару дней, промпт в Cursor, аккуратный pull request в тот же вечер. Ощущение десятикратной продуктивности держалось ровно до момента, когда коллега двое суток разбирался в коде. Причина была не в ошибке синтаксиса. Модель придумала тонкий краевой случай в логике кеширования, о котором ни автор, ни ревьюер сначала не догадывались. Потом деплой уронил legacy-систему, о существовании которой модель не знала, и следующая неделя ушла на откат и переписывание «идеального» сгенерированного кода под реальное, грязное окружение.

Что такое налог на ревью

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

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

Парадокс Джевонса, а не ошибка планирования

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

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

Три места, куда переехала стоимость

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

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

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

Закон Амдала для команды

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

Теория ограничений Голдратта объясняет, что происходит дальше. Пропускная способность системы определяется самым узким местом, а улучшение не-узкого места не увеличивает выпуск, оно увеличивает запас перед узким местом. На практике это выглядит как растущая очередь pull request'ов и ревьюеров, которые перестают успевать смотреть не только новый код, но и старый. Команда при этом формально работает быстрее, а поставляет столько же.

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

Что делать: переносить усилие в дизайн

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

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

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

Защищать ревью-мощность

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

Работают несколько практичных ограничений. Держать размер изменения в пределах, которые человек способен удержать в голове за один проход, обычно это двести-четыреста строк. Разделять генерацию и проверку: если человек сам писал промпт и смотрел, как код появляется на экране, он уже настроен на согласие с результатом, и ему нужен второй глаза. Требовать объяснение своими словами для рискованных мест: если автор не может описать, как работает блок и почему он выбран, изменение не готово. И давать ревью временной слот, а не «когда освобожусь».

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

Удалять вместо добавления

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

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

Как измерить сдвиг

Мерить надо не скорость печати, а время прохождения. Базовый набор известен: lead time от первого коммита до продакшена, время ожидания ревью, распределение размеров изменений, доля изменений, которые пришлось править повторно в течение двух недель, частота сбоев и время восстановления. Первые три показывают, где очередь. Четвёртая показывает цену качества. Пятая и шестая показывают, не переехал ли долг в продакшен.

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

Кому от этого хуже, а кому лучше

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

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

Часто задаваемые вопросы

Разве AI-ревьюеры не решают эту проблему?

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

Может, просто запретить агентов в команде?

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

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

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

Итог

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

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