Узнайте, почему ревью кода, написанного ИИ, занимает больше времени и как снизить этот налог. Практические советы для команд уже сейчас.
«Просто отдай это ИИ» — возможно, самая опасная фраза в разработке прямо сейчас. Я сам так говорил. Передавал задачу, получал чистый код за секунды, просматривал его и шёл дальше, потому что выглядело правильно и тесты были зелёными. Но однажды я ревьюил PR, который не писал, а только проверял. ИИ-сгенерированный, чистый, организованный, проходил все тесты. Я одобрил его, как одобрил бы всё, что выглядит компетентно на поверхности. Баг всплыл позже — не на ревью, не в тестах, а в проде, после того как коду уже доверяли. Ничего в нём не выглядело неправильно. В этом и была проблема: он был не очевидно неправильным, а тихо неправильным — так, что проявляется только при реальных условиях.
После этого я вернулся к тому PR и изучил его как следует. Не просматривая, а реально читая, понимая, что и зачем делает код, относясь к ревью как к настоящей работе, а не формальности перед мержем. Это заняло гораздо больше времени, чем одобрение. Только так я бы поймал баг до прода. С тех пор я не тороплю ревью ИИ-кода. Я уделяю им столько времени, сколько, казалось бы, не требовалось для написания. И, как оказалось, я далеко не один такой.
Согласно отчёту Harness «State of Engineering Excellence 2026» (опрос 700 инженеров из США, Великобритании, Индии, Франции и Германии), 81% разработчиков тратят больше времени на ревью кода с момента внедрения ИИ-инструментов. 28% сообщают о росте времени ревью на 30% и более.
Вот сделка, которую никто не рекламировал: ИИ сокращает время до создания PR примерно на 58%. Но те же PR теперь висят на ревью в 4.6 раза дольше. Время ревью на разработчика выросло примерно на 11.4 часа в неделю. Скорость не исчезла — она переместилась. Она перешла от «времени на написание» к «времени на проверку», а проверка оказалась более трудной и медленной частью работы.
Я начал называть это «налогом на ревью», и это не преувеличение. Почти 31% времени разработчика уходит на «невидимую работу»: проверку ИИ-вывода, исправление тонких багов, контекстные переключения для объяснения кода, который никто в команде не писал вручную.
Это не просто «больше кода для проверки». Это принципиально другой, более выматывающий вид ревью. Когда вы ревьюите код коллеги, вы проверяете работу человека с известным опытом. Вы знаете его привычки, типичные ошибки, примерно его стиль мышления. Когда вы ревьюите ИИ-код, этого контекста нет. Вы оцениваете вывод системы, которая пишет с одинаковой уверенностью и когда права, и когда ошибается, не давая сигналов, как их различить.
Разработчики назвали основные трудности: проверка точности ИИ-кода (53%), исправление тонких багов в ИИ-коде (52%), объяснение ИИ-кода коллегам (48%). Исследователи описывают растущий разрыв между двумя типами разработчиков в команде:
Неудобная правда: ИИ делает «скользящих» внешне более продуктивными. Они открывают больше PR, трогают больше строк. Менеджер, следящий только за выходом, видит высокую производительность. Но «строители», которые ревьюят эту работу, знают, что именно они ловят то, что иначе сломалось бы в проде, — тихо, без блеска, вне всяких дашбордов скорости.
Фонд Godot недавно полностью запретил ИИ-авторские вклады в код. Их обоснование: «ИИ не может нести ответственность, и мы не можем доверять активным пользователям ИИ в том, что они достаточно понимают свой код, чтобы исправить его». Один из мейнтейнеров описал более глубокую цену: когда ваша обратная связь на ревью поглощается процессом, а не обучает будущего контрибьютора, становится сложнее оправдывать затраты своего времени на ревью.
Это часть налога на ревью, которая не видна в метриках продуктивности. Это не только медленнее, но и менее мотивирующе. Ревью кода человека, даже если он требует доработки, — это инвестиция в человека, который станет лучше благодаря вашей обратной связи. Ревью ИИ-вывода, который забудет все исправления сразу после сессии, лишает этого измерения. Вы не наставляете, вы просто бесконечно ловите ошибки.
Я не думаю, что ответ — ревьюить менее тщательно, и не думаю, что надо избегать ИИ. Вот что сработало у меня и что подтверждают исследования.
Стоимость бага резко растёт, чем позже он найден: примерно 1x, если найден при проектировании, около 6x — при кодировании, и от десятков до сотен раз — в проде. Пре-коммит проверки ловят большую часть проблем до того, как они попадут к человеку, и это дёшево.
Строки кода и количество PR всегда были сомнительными метриками продуктивности. С ИИ они активно вводят в заблуждение, поощряя именно то поведение, которое раздувает налог на ревью.
Если человек, открывающий PR, не может объяснить свой подход за пару минут, PR не мержится, независимо от того, насколько чистый дифф. Это правило отсеивает большую часть того, что превращается в медленное и болезненное ревью.
Только 38% организаций отслеживают время на ревью ИИ-кода. Большинство разработчиков (94% в одном опросе) говорят, что технический долг, время валидации и выгорание не отражаются в метриках, которые смотрит руководство. Нельзя исправить то, что никто не измеряет.
«Мы относимся к ИИ как к инструменту черновиков, а не как к инструменту релиза» — звучит очевидно, пока команда не работает без такого явного соглашения. Команды, которые это проговаривают, ревьюят иначе, чем те, где каждый молча гадает, какая степень проверки ожидается.
Налог на ревью — это не только проблема продуктивности. Это проблема людей, одетая в одежды проблемы продуктивности. Когда ваши самые внимательные ревьюеры начинают молчать на PR, это редко означает, что они расслабились. Чаще это ранняя тихая форма выгорания, которая не объявляет о себе, пока человек уже не решил уйти.
Команды, которые выстраивают реальные нормы вокруг ИИ-ревью, сохранят разработчиков, которые действительно понимают свои системы. Команды, которые этого не делают, в итоге будут укомплектованы людьми, выпускающими много кода, который никто, включая автора PR, не сможет полностью объяснить.
Вопрос, над которым стоит подумать, — не «использовать ли ИИ для написания кода», а «кто несёт ответственность, когда никто в команде не писал код, который они выпускают».
Чувствовали ли вы налог на ревью в своей команде? Какой самый худший ИИ-сгенерированный PR вам приходилось распутывать, и изменился ли ваш процесс ревью после этого? Поделитесь в комментариях.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →