Код ревью в эпоху ИИ

Ещё одна мысль после конференций — код ревью придётся делать иначе.

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

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

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

И, возможно, вообще не все ПРы нужно ревьюить.

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

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

Но полностью отменять код ревью пока рано. Оно нужно не только новичкам, но и для шеринга знаний. Даже сеньоров стоит ревьюить: иначе критичный контекст может остаться в одной голове, а bus factor станет слишком маленьким.

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

Ещё появляется неприятный антипаттерн: коллега вместо ревью полностью отдаёт PR ИИ-агенту, не валидирует его замечания — и в пулл реквесте появляется куча нейрослопа. Не надо так 😬.

А как вы делаете ревью?
👍 — проверяю каждый пул реквест сам
🔥 — одновременно делаю ревью сам и прошу сделать ревью агента
👀 — отдал полностью агентам, пусть сами занимаются этой фигнёй

#ai #processes #codereview