Код-ревью с AI: как не тратить внимание команды впустую

Почему AI-ревью стало проблемой, а не помощью

Вы замечали, что после внедрения AI-бота для ревью пул-реквестов PR-ы стали длиннее, а толку меньше? Наша команда выросла, объём кода увеличился, но общее понимание осталось прежним. AI-агенты начали комментировать друг друга, генерировать ложные баги — и всё это с абсолютной уверенностью. Знакомо? Давайте разберёмся, как не утонуть в AI-шлаке и сохранить внимание команды.

Что пошло не так: симптомы AI-шума в код-ревью

Комментарии перестали быть «живыми»

Вместо кратких замечаний коллег PR-ы заполнились многословными AI-ответами. Каждая ссылка и цитата — вставлены, даже если не нужны. Команда перестала узнавать друг друга в комментариях. Приходилось покидать PR, чтобы уточнить контекст — а ведь смысл ревью именно в том, что всё нужное уже есть в обсуждении.

Дублирование и потеря времени

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

Главный ресурс — внимание, а не код

Наш CEO сформулировал ключевую мысль: узкое место — не ревью как процесс, а конечное внимание опытных разработчиков. AI может штамповать тонны текста, но каждый прочитанный символ стоит внимания команды. Он ввёл понятие Return on Attention (ROA) — отдача от внимания. Каждое слово в комментарии должно оправдывать затраты на его прочтение.

Примеры из жизни: ADR с кучей повторов — ужасный ROA. PR, который добавляет одну строчку в .gitignore, но имеет описание на 1430 символов — тоже. Это не про качество кода, а про то, сколько чужого внимания вы готовы потратить, чтобы сэкономить 30 секунд своего.

Та же идея известна как «помойная граната» (slop grenade) — когда AI-ответ заменяет одно предложение человека многословной простынёй. Стоимость surplus-текста не исчезает — она перекладывается на читателя.

Как не стать жертвой собственного AI

Я заметил, что начал делегировать модели задачи до того, как сам в них разобрался. Дисциплина ослабла. А ещё Claude любит вставлять в код комментарии вроде «Мы решили сделать так, а не иначе». Это бесполезно: решение должно быть в описании PR или коммите, а не в коде, где оно устареет при следующем изменении.

Где грань: полезное vs вредное AI-ревью

AI полезен, когда даёт ревьюверу новый угол зрения, ловит баг или пропущенный краевой случай. Это как второй набор глаз. Но он бесполезен, когда стоит читателю больше внимания, чем экономит. Ревью существует, чтобы доставлять ценность и передавать знания. Если комментарий улучшает код, но высасывает силы из ревьювера — это не trade-off, а ошибка.

Вот простое правило: перед отправкой комментария спросите себя — сказали бы вы это в таком объёме и тоне лично? Если нет — не улучшайте промпт, а редактируйте. Оставьте только то, что действительно ваше.

Практический вывод: как повысить ROA ваших PR

Прямо сейчас попробуйте:

• Перед отправкой комментария сократите его вдвое. Оставьте только суть.
• Не используйте AI для написания описаний PR, если одна строка кода — проверьте, не получается ли «помойная граната».
• Установите лимит на длину комментария (например, не более 2-3 предложений для простых замечаний).
• Тренируйте модели не вставлять шаблонные фразы в код — это шум, который станет дезинформацией завтра.

Внедрите принцип «отдача от внимания» в свою команду: каждый символ должен быть оправдан. И помните: ревью — это про людей, а не про AI.