Можно ли для начала убрать код-ревью из части процесса?

Сейчас заметно, что многие уже не особо внимательно смотрят PR. И тут возникает вопрос: если ревью в каких-то местах стало формальностью, почему бы его там не убрать?

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

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

А зачем вообще было нужно код-ревью?

Во-первых, для обучения коллег и шаринга знаний внутри команды.

Во-вторых, чтобы находить то, что автор задачи мог упустить.

Еще ревью помогало следить за качеством кода, потому что исправлять проблемы потом часто было дорого. А многие косяки, пропущенные на ревью, потом уже никто не исправлял.

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

Кажется, нам нужно разделять правила на nice to have и must have.

Nice to have правила можно сделать менее критичными. Если агент где-то про них забыл, это не должно блокировать весь процесс.

А вот must have правила должны соблюдаться всегда. Их лучше покрывать CI/CD, проверками, тестами и другими автоматическими кубиками.

Какие проблемы при этом остаются?

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

Агенты могут терять контекст или забывать важные детали. В некоторых местах они могут делать хрупкие и плохо расширяемые решения, неудачно структурировать код или оформлять его так, что людям потом будет сложно разобраться. Ну и еще агенты очень любят дублировать код.

А зачем людям вообще лезть в код, если его пишут агенты?

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

Как можно сохранить чистоту и поддерживаемость кода, но сократить ручное ревью?

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

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

В итоге это даст несколько вещей: поиск проблем, статистику по качеству кода и понятную обратную связь для настройки агентов, если они регулярно приносят одни и те же ошибки.

Кажется, будущее ревью может быть не в двух апрувах на каждый PR, а в жестких автоматических проверках для критичных вещей и регулярном аудите качества кода.

А что вы думаете по поводу код-ревью в мире, где большую часть кода пишут агенты?

@defendend_ai_dev