AI в code review
AI в code review полезен не как судья, а как второй проход по чек-листу
Я не очень верю в формат: "модель посмотрела diff и решила, можно мержить или нельзя".
Для production backend это слишком большая ответственность для инструмента, который не знает контекст команды, историю сервиса и реальные инциденты.
Но как второй проход перед review - AI уже полезен.
Например, я бы просил его смотреть не на "красивый ли код", а на более приземленные вещи:
1. Что изменилось в поведении API. 2. Где появились новые edge cases. 3. Есть ли риск N+1 или лишних запросов к базе. 4. Не сломали ли idempotency, retry или timeout. 5. Что будет при partial failure. 6. Какие тесты не покрывают новый сценарий. 7. Где diff стал сложнее, чем сама задача. 8. Что в PR стоит объяснить ревьюеру заранее.
Это не заменяет senior review.
Но снижает количество глупых пропусков перед тем, как человек тратит внимание на архитектуру, домен и компромиссы.
Главная мысль: AI-review не должен быть "автоматическим судьей".
Лучше, когда он работает как внимательный ассистент, который устал меньше человека и каждый раз проходит один и тот же чек-лист.
А финальное решение все равно остается за инженером.
Интересно, у кого в командах AI уже встроен в review workflow - как фильтр, помощник или полноценный gate?
· вчера
Мне кажется, тут скоро придется пересобрать саму рамку ревью.
Если мы уже доверяем моделям писать все больше кода, странно считать, что проверка навсегда останется ручной. Кода становится больше, скорость выше, а внимание ревьюера не масштабируется.
Поэтому вопрос не только в том, может ли AI найти N+1 или забытый тест. Более интересный сдвиг в другом. Переносить проверку раньше, на уровень намерения, контракта и ожидаемого поведения, а не ждать огромный diff и потом разбирать его руками.
Возможно, будущее не в том, что AI помогает человеку делать code review. А в том, что человек все чаще делает intent review, а основной проход по реализации забирают агенты.
ответить
коммент удалён