Return on Attention: Why AI Code Reviews Are Wearing Us Out

注意力回报：为什么 AI 代码审查让我们精疲力竭

Our team grew this year, and the PR volume has grown with it. Certainly faster than the ticket generation. New people means more code moving through the pipeline. It doesn’t mean more context. A lot of mass PRs needed real thought just to read through: what problem this is solving, why this approach, what actually matters here versus what’s incidental. That gap, more code, same amount of shared understanding, is where our troubles started.

今年我们的团队规模扩大了，PR（拉取请求）的数量也随之增长，增长速度显然超过了工单生成的速度。新人加入意味着更多的代码在流水线中流动，但这并不意味着有更多的背景信息。许多海量的 PR 仅仅是读一遍就需要深思熟虑：它解决了什么问题，为什么要用这种方法，这里什么才是重点，什么又是无关紧要的。这种差距——代码更多了，但共享的理解程度却没变——正是我们麻烦的开端。

When reviews got harder and slower, people reached for the tool that could help them attempt to keep pace. We have an AI code review bot that runs as an automated reviewer on every PR now, and separately, plenty of us run different LLM and coding agents of choice locally to draft review comments. Put those two together and you get exactly what you’d expect: a bot commenting on a PR, another bot replying to it. Some of the LLM created reported bugs, were created in the first place with total confidence by a model that had no way to know it wasn’t real. That is a real drawback about the AI coding assistance, confident wrongness.

当审查变得越来越困难和缓慢时，人们开始寻求工具来帮助自己跟上进度。我们现在有一个 AI 代码审查机器人，它会在每个 PR 上自动进行审查；此外，我们许多人还在本地运行各种 LLM（大语言模型）和编码代理来起草审查意见。将这两者结合起来，你就会得到预料之中的结果：一个机器人在 PR 上评论，另一个机器人回复它。一些由 LLM 报告的 Bug，最初就是由一个完全无法判断其真伪的模型以绝对自信的态度创建出来的。这就是 AI 编码辅助的一个真正弊端：自信地胡说八道。

What it felt like Comments stopped sounding like the colleagues who supposedly wrote them. Verbose. Every possible reference and citation included, whether the moment called for it or not. We’re a team that talks about code plainly, in our own words, and PRs started filling up with AI slop. One complaint came up more than once: having to leave the PR to get real context, pinging a person or a model outside the thread because the comment itself didn’t actually contain enough, or just way, way too much filler. The entire point of a pull request comment is that you shouldn’t have to go anywhere else for it.

这种感觉就像是：评论听起来不再像是那些本该写下它们的同事了。它们变得冗长，包含了所有可能的参考资料和引用，不管当时是否需要。我们是一个用自己的语言直白地讨论代码的团队，但 PR 开始充斥着 AI 生成的垃圾内容。一个抱怨不止一次出现：为了获取真实的背景信息，不得不离开 PR 页面，去询问线程之外的人或模型，因为评论本身要么内容不足，要么充斥着太多太多的废话。PR 评论的全部意义在于，你不应该为了理解它而去别处寻找信息。

Another: duplication, and the cost of re-reading. A paragraph explaining code you could read directly in a minute doesn’t save you time. It costs you time, on top of whatever the comment was supposed to save you from working out yourself. Someone on the team put it plainly: not sure what the right balance is now, but the whole paradigm has clearly shifted. Fair. What’s less fair is assuming the way we’re doing it right now is the only way it could be done.

另一个问题是：重复和重读的成本。一段解释代码的文字，如果你花一分钟就能直接读懂代码，那么这段文字并不能节省你的时间。它反而浪费了你的时间，而且是在你本应通过评论节省下来的思考时间之外，额外增加的负担。团队里有人直言不讳地说：现在不确定什么是正确的平衡点，但整个范式显然已经改变了。这很公平。但不公平的是，认为我们现在这种做法是唯一可行的方式。

The scarce resource

稀缺资源

A few weeks into this, our CEO said something in Slack that really got to the heart of the whole problem for me. The PR-review complaints were real, but they were a symptom, not the disease. His point: the actual bottleneck isn’t PR review specifically, it’s that the finite attention of skilled teammates can be easily overwhelmed by LLM-generated content. Human attention is the scarce resource worth guarding most zealously, and inflicting verbose, cheap-to-produce-but-expensive-to-consume writing on each other should be treated as a real anti-pattern.

几周后，我们的 CEO 在 Slack 上说的一番话真正触及了问题的核心。关于 PR 审查的抱怨是真实的，但它们只是症状，而非病灶。他的观点是：真正的瓶颈并非 PR 审查本身，而是熟练团队成员有限的注意力很容易被 LLM 生成的内容所淹没。人类的注意力是值得最严加守护的稀缺资源，而将冗长、易于生成但难以消化的文字强加给彼此，应该被视为一种真正的反模式。

His term for it was Return-on-Attention, ROA: every word you ask someone else to read has to be worth what it costs them to read it. He backed it with two examples from that same week. Some ADRs had gone out with a lot of repetition in them, and a colleague had to read through all of it. Terrible ROA. A PR that gitignored a single directory, one line of code, ten characters, came with a description running 1,430 characters. Terrible ROA for whoever had to review it. Neither example is about code quality. Both are about what you’re allowed to cost another person’s attention to save yourself thirty seconds of editing.

他将其称为“注意力回报”（Return-on-Attention, ROA）：你要求别人阅读的每一个字，都必须对得起他们阅读时所付出的成本。他用同一周的两个例子支持了这个观点。一些 ADR（架构决策记录）中包含了大量重复内容，同事不得不通读全文，这是极差的 ROA。一个仅仅是 gitignore 了一个目录、一行代码、十个字符的 PR，其描述竟然长达 1430 个字符。对于任何需要审查它的人来说，这都是极差的 ROA。这两个例子都与代码质量无关，它们关乎的是：为了节省自己三十秒的编辑时间，你是否有权消耗他人的注意力。

The same idea has a public version. noslopgrenade.com calls it a “slop grenade”: pasting a massive AI-generated response into a chat or email where a human would have written one sentence. It’s aimed at chat, not code review, but it’s the identical failure. An LLM can produce more words than a task needs, for free, and the cost of that surplus doesn’t disappear. It just moves to whoever has to read it.

同样的理念在公共领域也有体现。noslopgrenade.com 将其称为“垃圾手榴弹”（slop grenade）：在聊天或邮件中粘贴一大段 AI 生成的回复，而原本人类只需要写一句话。这针对的是聊天，而非代码审查，但本质上的失败是一样的。LLM 可以免费生成超出任务需求的大量文字，而这些多余内容的成本并不会消失，它只是转移到了必须阅读它的人身上。

The part I don’t love admitting

我不愿承认的部分

I noticed the same pull in myself, not as a reviewer but as a thinker. There were stretches where I’d hand a problem to the model before I’d actually sat with it, and I could feel my own workflow discipline getting looser. Not because the answers were wrong. Because I’d stopped doing the part where I figure things out first and ask questions second. I’m also mid-fight with a specific habit of Claude’s: narrating design decisions into comments and code. “We decided this, not that.” It shows up unprompted, and it’s never once been useful to me. A decision like that belongs in a PR description or a commit message, where it has context and a date and an author. Sitting in a code comment, it’s just noise that will be wrong the next time someone changes their mind and nobody remembers to delete it. I’m building a skill specifically to stop Claude from writing that pattern into a codebase.

我发现自己也有同样的倾向，不是作为审查者，而是作为思考者。有段时间，我会在真正深入思考问题之前就把它丢给模型，我能感觉到自己的工作纪律变得松懈了。不是因为答案错了，而是因为我停止了“先自己弄清楚，再提问”的过程。我还在与 Claude 的一个特定习惯作斗争：在注释和代码中叙述设计决策，比如“我们决定这样做，而不是那样做”。它会不请自来地出现，而且对我来说从来没有任何用处。这样的决策应该放在 PR 描述或提交信息中，那里有背景、日期和作者。放在代码注释里，它只是噪音，当下一次有人改变主意而没人记得删除它时，它就会变成错误信息。我正在专门培养一种技能，以阻止 Claude 将这种模式写入代码库。

Where the line actually is

界限究竟在哪里

Bot review isn’t the problem. Misusing it is. It’s useful when it gives a reviewer an angle they wouldn’t have found on their own, or catches a bug, a missed edge case, a real issue sitting in the diff. That’s a second pair of eyes, really helping. It stops being useful the moment it costs the reader more attention than it saves them. Review exists to ship value and to pass knowledge between people. Code quality matters because it serves that, not the other way around. If a comment leaves the code a little better but leaves the reviewer more drained, that’s not a trade worth making.

机器人审查不是问题所在，滥用它才是。当它为审查者提供了一个他们自己无法发现的角度，或者捕捉到了 Bug、遗漏的边界情况、差异中存在的真正问题时，它是很有用的。那是第二双眼睛，确实在提供帮助。但一旦它消耗读者的注意力超过了它所节省的注意力，它就不再有用了。审查的存在是为了交付价值和在人与人之间传递知识。代码质量之所以重要，是因为它服务于此，而不是反过来。如果一条评论让代码好了一点点，却让审查者更加精疲力竭，那么这笔交易就不值得做。

Attributed to you

署名权归你

Here’s a rule I use. When posting a review comment, it’s attributed to you. Sure, a coding agent might be a co-author…but that isn’t who’s going to have to follow up. It isn’t the one the PR author is going to come to with questions, or pushback. It’s you. The PR author has no way to know how it got written. Sure they probably know, especially if you’re slapping em dashes all over the place. They’re going to read it as your judgment, in your voice, and hold you to it exactly the way they would if you’d typed every word yourself. So that’s the standard before you hit submit: would you have said this, at this length, in this tone? If the answer is no, the fix isn’t a bet

这是我使用的一条规则：当你发布审查评论时，它署名是你。当然，编码代理可能是共同作者……但它不是那个需要跟进后续的人。它也不是 PR 作者会带着问题或反对意见来找的人。是你。PR 作者无法知道它是怎么写出来的。当然他们可能猜得到，尤其是当你到处乱用破折号的时候。他们会把它读作你的判断、你的声音，并像你亲手敲下每一个字一样要求你负责。所以，在点击提交之前，标准是：你会以这样的长度、这样的语气说出这些话吗？如果答案是否定的，那么修正的方法就不是……