Как эффективно делать ревью AI-кода?

Я смотрел много докладов об изменениях в процессах разработки с приходом ИИ, и почти в каждом был один и тот же тезис — код теперь пишут агенты, кода стало больше, и нагрузка перешла на код-ревью — на него уходит большая часть часов разработчика.

Есть такие цифры: например, по данным Faros на 10 тысячах разработчиков, с ИИ время в ревью выросло на 91%.

Это абсолютно не бьётся с моим видением, практикой и ощущениями, поэтому хочу порассуждать на эту тему и услышать мнения со стороны.

Про себя скажу честно и прямо — я перестал смотреть PR от своих агентов совсем. Случилось это практически сразу после перехода на разработку нейронками. И я нисколько не сомневаюсь в этом решении. В дни активной разработки у меня бывает по 30–50 PR по нескольким проектам — это могут быть десятки тысяч строк кода.

Детальное ревью этого объёма займёт у меня, наверно, целую неделю. И зачем тогда писать код нейронками?)) Я понимаю, что многие очень держатся за старое и пытаются улучшить его, но это всё равно что приделывать двигатель внутреннего сгорания к лошади, как мне кажется.

Я говорю о том, что ИИ позволяет формировать новые подходы к разработке, а не только автоматизировать какие-то звенья. И в результате — полностью исключить человека из основного процесса и при этом повысить качество и надёжность продукта.

Главное решение — это детализация и разделение ответственности.
Код-ревью раньше — это человек смотрит код, чтобы не пропустить проблемы.
Проблемы бывают очень разными, но человек умный и понимает, в каком случае и на что стоит смотреть.

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

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

2. Скрипт для проверки качества кода запускается в CI и выявляет типичные нарушения в коде.

3. Непосредственно код-ревью проверяет тесты и полноту их выполнения, а также возможные сайд-эффекты и баги.

Последний этап как будто тоже просится разбить на 2 части, пока думаю над этим.
Я пробовал делать двойное ревью от разных моделей с разными промптами — они часто находили разное и дополняли друг друга.

И есть ещё один важный шаг — это ревью всего проекта. Я провожу его регулярно — запускаю детальный анализ через агентов по всей кодовой базе. Цель — найти неэффективные решения и костыли. Из этого анализа многое идёт в развитие фреймворка.

Все эти элементы не просто обеспечивают качество кода — они создают систему разработки, которая развивается со временем и обучается на своих ошибках.