ИИ поменял код-ревью с двух сторон. Кода стало больше и он пишется быстрее, поэтому нагрузка на ревьюеров выросла. И появились ИИ-ревьюеры, которые комментируют пулреквесты автоматически. На собесе спрашивают, как вы с этим живёте и какие правила предложили бы команде.
Главный принцип: автор отвечает за код
Неважно, кто напечатал строки: вы, ассистент или агент. Автор пулреквеста отвечает за каждую строку так, как если бы написал её сам. Отсюда правила:
- Вы понимаете каждую строку и можете объяснить, почему она такая. «Так сгенерировалось» не ответ на вопрос ревьюера.
- Вы сами прогнали код и тесты до отправки на ревью.
- Вы сами отревьюили свой дифф перед тем, как звать коллег. Ревьюер не первый читатель сгенерированного кода.
Перекладывать проверку на ревьюера нечестно: генерация стоит секунды, а внимательное чтение стоит десятки минут чужого времени.
Что меняется в ревью кода, написанного с ИИ
Сгенерированный код выглядит гладко: аккуратные имена, комментарии, единый стиль. Это усыпляет внимание. Ошибки при этом другого типа, чем у человека:
- Вызов метода, которого нет в используемой версии библиотеки.
- Правдоподобная, но неверная бизнес-логика: код делает «примерно то», а не то, что в задаче.
- Пропущенные краевые случаи и обработка ошибок, которая просто проглатывает исключение.
- Дублирование: ассистент написал свой хелпер, хотя в проекте уже есть такой же.
- Лишние изменения: попутно переименовал, переформатировал, «улучшил» соседний код.
- Уязвимости: SQL склейкой строк, секрет в коде, отключённая проверка сертификата.
- Комментарии, которые не совпадают с кодом.
Ревьюер смотрит не на стиль, а на смысл: соответствует ли код задаче, вписывается ли в архитектуру проекта, нет ли дублей.
Размер изменений
Ассистент легко выдаёт дифф на тысячу строк. Такой пулреквест невозможно качественно отревьюить, его просто одобряют. Правила, которые работают:
- Одна задача в одном пулреквесте. Рефакторинг отдельно от фичи.
- Механические изменения (переименования, форматирование) отдельным коммитом или пулреквестом.
- Если дифф большой, автор пишет в описании, что смотреть внимательно, а что механика.
ИИ как ревьюер
Автоматический ИИ-ревьюер полезен как первый проход: опечатки, очевидные баги, забытые проверки на null, несоответствие описанию. Ограничения:
- Он не знает контекста бизнеса и договорённостей, которых нет в коде.
- Даёт ложные срабатывания, и команда быстро учится их игнорировать вместе с полезными.
- Не может отвечать за решение. Одобрение пулреквеста остаётся за человеком.
Хорошая практика: ИИ-ревью как необязательные комментарии, которые автор разбирает до прихода человека. Обязательными остаются линтеры, тесты, статический анализ и ревью коллеги.
Правила команды
Если на собесе спросят, какие правила вы бы ввели, вот разумный набор:
- Какие инструменты разрешены и для какого кода (например, нельзя отправлять в облачный сервис код из закрытого репозитория, если компания это не разрешила).
- Автор отвечает за код полностью, ревью не заменяет самопроверку.
- Размер пулреквеста ограничен, механика отдельно.
- Тесты обязательны, и их тоже читают на ревью.
- Новые зависимости, предложенные ассистентом, проверяются отдельно: существует ли пакет, кто его поддерживает, какая лицензия.
- Общие файлы с правилами проекта для ассистента лежат в репозитории и ревьюятся как код.
- Нужна ли пометка, что код написан с ИИ, решает команда. Пометка не снимает ответственности с автора.
Ревью как обучение
Для джунов ревью был главным способом учиться. Если джун приносит сгенерированный код, полезно спрашивать на ревью «почему так?» и «какие ещё варианты были?». Это проверяет понимание лучше, чем поиск опечаток.
Что сказать на собесе
Код от ассистента я ревьюю сам до того, как отправить коллегам, и отвечаю за него как за свой. ИИ-ревьюер полезен как первый фильтр, но решение и ответственность у людей.