Return on Attention: когда AI-ревью съедает внимание быстрее, чем экономит время

Если вы в соло- или малой команде уже гоняете coding agents в ежедневном цикле PR, узкое место сместилось: не «успеем ли прогнать diff», а сколько внимания уходит на разбор бот-диалогов вместо кода. В эссе разработчик cseeman описывает команду, где объём pull request'ов вырос, а качество тикетов — нет; пустоту закрыли LLM с обеих сторон ревью. Для любого агентного workflow это не локальный баг процесса, а сигнал: ускорение генерации кода не снимает когнитивную нагрузку — переносит её в ленту комментариев.

LLM на обеих сторонах ревью: от темпа к перегрузу

Команда за год выросла, PR пошли чаще, чем появлялись осмысленные тикеты. Больше людей — больше кода в пайплайне, но не больше общего контекста. Когда ревью стало тяжелее, подключили AI code review bot на каждый PR и локальные LLM/coding agents для черновиков комментариев.

Итог предсказуем: бот комментирует diff, другой бот отвечает на комментарий. В тредах появляется «bots arguing with bots» — не риторика, а наблюдаемый цикл. Модели иногда сообщали о багах, которые сами же уверенно «придумали», не имея способа проверить реальность.

Проблема не в том, что бот ревьюит код. Проблема в том, как команда этим пользуется.

Жалобы сводились к одному: комментарии стали многословными, приходилось уходить из PR за контекстом, а абзац про код, который читается за минуту, не экономил время ревьюера.

Return on Attention: узкое место — не code review

Через несколько недель перегруза CEO (имя в материале не названо) написал в Slack: жалобы на PR-review — симптом, а не болезнь. Узкое место — перегруз квалифицированного внимания контентом, сгенерированным LLM. Человеческое внимание — дефицитный ресурс; навязывать коллегам многословный текст, «дёшевый в производстве, но дорогой в потреблении», — анти-паттерн.

CEO ввёл термин Return-on-Attention (ROA): каждое слово, которое вы просите прочитать, должно окупать стоимость чтения.

Два примера из той же недели:

• ADR с большим объёмом повторов — «terrible ROA» для читателя.
• PR, который gitignore'ит одну директорию (одна строка кода, 10 символов), сопровождался описанием на 1 430 символов.

Оба случая — не про качество кода, а про цену внимания, которую автор экономит на себе за счёт читателя. Автор проводит параллель с «slop grenade» — огромным AI-ответом там, где человек написал бы одно предложение; в code review тот же провал ROA.

Coding agents, Claude и skill против шума в diff

В посте явно названы не IDE, а паттерн инструментов: корпоративный бот-ревьюер плюс локальные агенты у каждого разработчика. У автора Claude в разгар привычки вплетать в комментарии и код нарратив про design decisions («We decided this, not that») без запроса; он строит skill, чтобы остановить этот паттерн в кодовой базе.

Для читателя с агентным циклом в IDE это узнаваемо: тот же класс задач, что rules/skills против LLM-шума в diff — не «лучший промпт», а жёсткое ограничение поведения модели в ревью-комментариях.

Автор замечал и другую ловушку: отдавать задачу модели до того, как сам «посидел» с проблемой. Дисциплина workflow ослабевала не из-за неверных ответов, а из-за пропуска этапа самостоятельного разбора — агент ускорял черновик, но не заменял мышление.

Три правила, которые переживут любой агент в PR

Формальных корпоративных метрик ROA в материале нет — зато есть практические критерии, применимые к любому стеку с LLM в ревью.

1. Комментарий приписывается вам. Секция «Attributed to you»: автор PR прочитает ваш комментарий как ваше суждение и голос. Перед отправкой — «Would you have said this, at this length, in this tone?» Если нет — правьте текст, а не промпт.

2. Бот полезен, пока экономит внимание. Он оправдан, когда даёт угол, который вы сами не нашли, или ловит баг и edge case. Перестаёт быть полезным, когда чтение стоит больше, чем сэкономленное время.

3. Качество кода служит передаче знаний, не наоборот. Как формулирует автор: «Bot review isn't the problem. Misusing it is.» Комментарий, который чуть улучшает код, но истощает ревьюера, — плохой обмен.

Перед отправкой review-комментария от агента:
→ Сказал бы я это сам?
→ В такой длине?
→ В таком тоне?
Если хотя бы один ответ «нет» — сокращайте, не усиливайте промпт.

Соло-разработчик без отдельного продакта особенно уязвим: некому «снять» лишний шум в треде, и весь ROA ложится на одну пару глаз. Имеет смысл заранее решить, где агент черновит, а где вы обязаны думать сами — иначе ускорение кода обернётся вечерним разбором бот-переписки.

Источники

• Return on Attention: Why AI Code Reviews Are Wearing Us Out — cseeman, Dev.to, опубликовано 9 июля 2026; дата доступа: 11 июля 2026 (UTC).