审查债务的定义与隐性危机
随着 AI 编码助手的广泛采用，软件工程领域正在经历前所未有的效率变革。然而，在这股热潮背后，隐藏着一个很少被量化却日益严重的隐患——审查债务（Review Debt：由于 AI 生成代码的速度远超人类审查的极限，导致未被深入理解和充分信任的代码在仓库中不断累积的差距）。来自 GitHub 的 2025 年 10 月报告显示，全球公开拉取请求（Pull Request, PR）的提交量（Commits）同比增长了 25%，然而与此同时，作为评审活跃度直接指标的 PR 讨论评论（Comments on comments）却骤降了 27%。代码产出量与审查精力的这种反向变动，正是审查债务加速累积的铁证。
为了进一步探究这一现象，Faros AI 在其 2026 年的基准研究中追踪了采用 AI 团队的表现，发现 PR 平均评审时间飙升了 441.5%，即经过审查的 PR 现在需要比过去多耗费 5.4 倍的时间；与此同时，无审查直接合并（Merged without review）的 PR 比例也增加了 31%。这表明 AI 虽然能以极快的速度生成代码并创建 PR，但人类工程师的评审带宽却无法按比例缩放，从而形成了巨大的瓶颈。为了应对这种审查瓶颈，团队需要首先看清在研发指标提升背后隐藏的系统性疲劳。
Original English Source
Hi everyone. I'm Sachin Gupta and I'm a software engineer. The title is exactly what it sounds like. Your coding agent is creating review debt. Before I start, sit with the title for a second. Notice what it is not saying. I'm not saying that coding agents are bad. I'm not saying they don't make us faster. I'm saying they're creating a kind of debt that nobody is measuring. And that debt is going to come to you. Over the next few minutes, here's what I'm going to do. I will define what review debt is. I'll walk five signal families that are going to compose it. I'll score three real pull requests side by side and I will show you a cross repo scan of over 500 PRs, which is nothing but three public code bases. So let's go. Look here. Here's the gap nobody's measuring. GitHub's 2025 October's report that covers almost every public pull request on the planet shows that the commits climbed 25% year over year. And now over the same year, comments on the comments dropped 27%. Now, these comments are nothing but the proxy for review activity. Code production volume actually went up, but the review attention went down. They moved in opposite directions that to in the same year. Now, look at the teams for this along the AI adoption curve. Faros AI tracks this cohort in their 2026 benchmark. Median PR review time is up by 441.5% and if you see like if you calculate, you'll figure out that the reviewed PRs take 5.4 times longer than what they used to. And then 31% more PR are now merged with no review at all. So AI produce AI is producing the code very fast. AI is producing the pull request very fast, but humans cannot responsibly review them at that pace. This gap is called as review debt. It actually accrues quite a bit. It compounds and right now nobody has a number for it. But by the end of this talk, I will make sure that you will have a certain number.研发指标假象与评审疲劳
在评估 AI 加速效果时，许多团队往往沉浸在虚荣指标的虚假繁荣中。例如，每位开发者的 PR 数量上升了 16%、PR 平均规模从 44 行代码攀升至 72 行（增幅达 63%），或是开发到合并的周期时间（Cycle Time）略有缩短。但实际上，PR 数量的增加可能只是由于大 PR 被生硬拆分；PR 体积的膨胀实际上是代码冗余（Bloating）的体现；而周期时间的缩短，往往是因为评审人疲于奔命而放弃了严格的推敲和阻拦。这种“效率”并未转化为真正的系统信任，反而带来了严重的评审人疲劳（Reviewer Fatigue），使工程师承担了比以往重得多的评审负荷。
在这种疲劳下，团队往往会陷入以下几种病态研发模式：
- 深夜合并（Late-night merges）：PR 往往被搁置数天无人问津，直到周五截止日前夜，在半夜 11 点仓促获得一个毫无实质审查的批准绿灯。
- 测试戏剧（Test Theater：编写测试仅为了断言代码的实际运行结果，而非验证代码是否符合预期的行为逻辑，从而把已有的 Bug 锁死在测试断言中）。
- 架构漂移（Architectural Drift）：同一个技术问题在三个不同的文件中被以三种完全不同的方式解决，缺乏全局的技术决策把关。
- 故障滞后（Incident Lag）：由于缺陷未被评审发现，故障在合并数周或数月后才爆发，且难以溯源到 AI 编写的代码修改。
这种审查债务的恶性循环类似于财务借贷，其收取的利息是“人类的注意力”。它的滚雪球效应源于三个反馈回路：首先，未被深度评审的劣化代码会被用于 AI 的微调和检索增强生成（RAG），从而污染后续的代码生成；其次，评审注意力收缩至表面语法，导致重大架构决策在评审中被永久忽略；最后，管理层对交付速度期望值的重置，导致团队无法按比例补充评审人手。为了斩断这一恶性循环，我们需要建立一套客观且不依赖主观情绪的量化度量体系。
Original English Source
Now, if you look at this particular slide, here is the story every team is telling right now. PR per developer are up 16%. That's the Faros AI acceleration Whiplash benchmark and that from April 2026. There were like 22,000 developers, 4,000 teams. And the median PR size is up 63%. 44 lines to 72 lines per pull request. That is basically 16 months of long-term data from DX 2026 study, which includes 400 organizations. Now, if you see the cycle time, open to merge, that is modestly down and it is coming from the same DX study. The framing is really generous. PR throughput grew actually about 8% and the AI usage rose about 65%. The gain that we see today is real, but it is actually smaller than the hype that is present. Every one of these numbers are real. None of them is a lie, but everyone is a vanity metric. PR count goes up when one PR splits into seven PRs. Median PR size going up is not a benefit, it's actually a bloating. Cycle time going down when reviewers stop pushing back. These things tell you the speed of production. They do not tell you the speed of trust. Now, we will go into the next slide to see more. Now, if you go looking for the second story, here is what you're going to find. Reviewer fatigue. Engineers carry far more review load than a year ago. They're not happier about it. Late-night merges. PRs are sitting unreviewed for 3 days, 4 days, and then they suddenly get a thumbs up at 11:00 p.m. before a Friday deadline. Test theater. Tests are getting added, but they're actually asserting what the code did, not what the code should do. They lack in behavior, including bugs. Architectural drift. Again, the same problem that is solved in three different ways in three different files. Nobody is actually holding up the architectural trade. Finally, incident lag. When something breaks, the bug lags week or months or months after merge. Nobody connects the dot back to the AI authored change. These costs don't show up in any dashboard until now. So now, let me give you the definition. Review debt. It's the accumulating gap between code your agent has produced and the code humans have actually reviewed, trusted, and understood. It rhymes with technical debt, but it is more like a financial debt because it compounds. It actually accrues interest, but this interest is not money. This interest is paid in human attention. It compounds because of the three feedback loop. First, the agent learns from your code base, fine-tuning, rag grounding, in-context suggestions. Code that was not deeply reviewed yesterday grounds tomorrow's PR. This debt becomes generative in nature. Second one, reviewers seed the architectural call. When most of a PR was generated, attention contracts to syntax and obvious bugs. Big picture decision moved from review time to never. Third one, velocity expectations reset. Once leadership sees the new throughput, you don't get to hire reviewers in proportion. There is no slack left to pay the debt back. Each loop on its own is survivable. Together, you will have a runway, but the next question is, how are you going to measure it?确定性度量框架的五大信号
为了精准评估拉取请求（PR）的审查难度，Sachin Gupta 提出了由 10 项确定性检查组成的五大度量信号家族。该度量完全基于 PR 元数据及代码库的客观计算，不依赖大语言模型（LLM）作为裁判。这确保了评分的客观稳定（模型更新不会导致旧 PR 评分变化）和可辩护性（可在技术评审和管理汇报中直接引用）。
以下是该度量框架的核心信号家族：
- 修改规模与耦合度（Dev Size and Coupling）：评估净修改行数与受影响的文件范围。AI 助手倾向于在调用处进行就地修复，而人类工程师倾向于根治底层原因。这导致 AI 编写的代码改动往往四处蔓延（Sprawling），其评审成本呈非线性增长，极大地破坏了评审人的心智模型。
- 测试证据缺口（Test Evidence Gap）：新增测试行数与新增生产代码行数的比例。AI 提交的 PR 通常具有极低的测试代码比。虽然 AI 能生成大量测试，但多数只是对现有代码行为的盲目断言（锁定 Bug），无法替代对预期行为的验证。
- 目录与所有权扩散（Directory and Ownership Spread）：PR 中涉及的不同代码所有者（Code Owner）团队的目录数量。跨越多个团队所有权的 PR 会产生巨大的协同沟通开销，可能直接抵消 AI 编写代码节省的时间。
- AI 署名特征（AI Authorship Indicators）：非惩罚性的识别指标（占总分权重的极小部分），主要通过三种模式检测：Git 的
Co-authored-by署名脚注、包含cursor/copilot等特定前缀的分支命名模式，以及 PR 描述与提交信息中的特定生成式词汇。 - 背景证据与合规缺口（Evidence and Rational Gaps）：评估 PR 是否解释了修改的“原因”（Why）而不仅仅是“做了什么”（What）。简陋的 PR 说明（例如只有 18 个字符或仅写着“Updates”）会使得代码变得完全不可评审。
结合上述五大信号，ReviewDebt 框架会计算出一个 0 到 100 之间的数值分数，并将审查负荷划分为四个区间：0-24（极低负担，可直接合并）、25-49（正常负担，常规审查）、50-74（中高负担，需作者在高级工程师审查前提供补充证据）、75及以上（极高负担，建议拆分 PR 或要求更详尽的上下文）。这种清晰的分级标准，能够指导研发团队进行合理的工程行为干预。
Original English Source
So, how do we measure review debt? There are five signal families that has like 10 deterministic checks. Remember, the keyword here is deterministic. Every check is computable from a pull request and its repository. No, we don't need any language model. Why? Because LLM, when it acts as a judge, it possibly can break two things. Number one, the score becomes a moving target. The same PR, basically the score that you got for the same PR, will score differently when your model will change. Two, the score stop being defensible in an engineering review. You cannot put it on a slide. You cannot put it in front of a leadership. So, what do you want? You want a number that is traceable to a deterministic computation, different size and coupling. Second, test evidence gap. Third, directory and ownership spread. Fourth, AI authorship indicators. Fifth, evidence and rational gaps. These are the five families that will have 10 checks under them. Let's walk each of them. The first one, the first signal that we have is dev size and coupling. This is the simplest one to calculate, basically. It's also the most often misread. What it measures is the net lines changed, the files touched, whether changes cluster in one module, or is it sprawling across many. Why the agent is struggling here? Agents are biased toward fix at the call site. A human engineer routes a fix to the root cause. That keeps the difference very small. But an agent will reach into many files looking for the same symptom. The review cost of a sprawling difference is not proportional to the size. It is actually much steeper. So, the cross-file coupling explodes the mental model and reviewer has to hold. We'll look into the second signal, which is test evidence gap. So, what is test evidence gap? Test evidence gap is nothing but test lines added divided by the production lines added per pull request. So, AI authored PRs, they ship with a far lower test to code ratio. Sometimes there is no test file in place. And if there is any, it's minimal. So, this gap is actually a consistent gap. And the problem with this particular thing is the number The reason this number is basically brutal is the agent generate test. They generate a lot of test. But these test basically assert what the code is doing. It does not generate the test cases what the code should actually do. They lock in the behavior including the bugs. The ratio does not capture the quality gap. It just measures whether the test showed up at all. So, the deeper signal is the next step that is a layer down. We'll see the next one, which is directory and ownership spread. So, what is directory and ownership spread? Count the distinct code owner teams whose file appear in the difference. Now, what does it mean? Basically, a well-shaped PR concentrates in one team directory. But a sprawling one reaches across many team file. And the review cost is enormous in this scenario. No single human hold the whole mental model. You need multiple approvals from multiple engineers in multiple different context. The coordination overhead easily exceeds the time the agent save producing the code. This is where you start to feel the economics of review debt. The agent gave you three hours of typing. You spend those three hours by multi-party reviewer attention. And the next one we are going to see is AI authorship indicators. So, what is AI authorship indicator? Before everyone gets defensive, this is not for the blame. We are not flagging that engineers use coding agents. We wait the scores for a PR shape like agent assisted authorship get extra reviewer attention. So, that way you know, right like, okay, this is the PR that is directly coming from the agent. And there are like the very common three detection mode. I must I think everyone must have seen it by now. One is the co-authored footer, which is basically one of your strongest signal. You see that co-authored by Copilot. Second one is the branch name pattern. Generally, you must have seen it says codex, Copilot, cursor prefixes. Third one is basic generated by assisted by, which is nothing but your PR body. your commit message phrases. We did actually a real data check on three public repos, which comprised of 524 PRs. I'm not going to name the company, but for the sake we are just calling it A, B, and C. Now, if you see the highest signal was the co-authored footer. And the second one the lowest signal was 0% on the repo C. Even though it was done by coding agent, but they might have blocked it saying any co-authored or generated by etc. etc. The next thing that we are going to see is evidence and rational gaps. So, evidence and rational gaps. I think this is one of the most deterministic that I personally feel. It's the one that destroys review ability the fastest. What it measures basically? Does the PR explain the why or just the what? On the left, if you see, we have an high gap. On the right, we have a low gap. The title says "Fix leaky test" and all the data that you're seeing here is actually from some public repos. Now, the PR body length is 18 characters, the commit message says updates. Obviously, I will not be if you give it to me, I won't be able to review this. Okay, I cannot accept this. But then on the right, if you see when there is actually a low gap, the title actually is telling you what the change is all about. The body has a symptom, the diagnosis, the change, and the link to the benchmark. Now, a reviewer can do the job. So, in our regression fixtures and hands code teams, this signal destroys reviewability fastest. In the real open source data, PR bodies follow conventional commit format. So, it fires most rarely there. But if you see the regression fixtures are just the demos. Okay, let's see how those five signals combine. You will only have one number that is going to from zero to 100. And the exact weights are basically your defaults. Now, if you're planning to adopt this, I would like you to do this first. Run it backwards over the last 200 PRs that have been merged in your company. Calibrate the weights against your team's actual reviewer experience. The score has to feel right against your actual guts. We you you are going to divide it into four bands. If you are zero to 24, which means you have very low review burden. If you have 25 to 49, you are normal, proceed with the standard care. 52 to 74, you need evidence from the author before senior review. And if you're 75 and above, definitely it's high split or request more context. Same shape as technical debt categories, but the unit is different. Now, we are going to see what the scanner actually did. Now, if you see this is the clean PR. Unfortunately, I won't be able to give you a live demo today, but I will walk you through a CLI. I wanted you to show three scored pull requests side by side, the level where the framework become useful as a repeatable review conversation. This is the first one. If you see, this is what the scanner says when a PR is all changed. Score out zero out of 100. The burden is basically nil. It's zero. We have a low review burden. The estimated minutes is six. No checks were fired. And if you look the structure here, that is why the list is empty. Reviewer focus is empty. Author next action is empty. The framework only generate advice when it has something specific to say. A healthy PR produces a tiny, almost ceremonial report. That's exactly what you want. And the takeaway is most healthy PRs produce zero noise. They get the work done without making any noise. This is not a tool that complains by default. Running it on every PR cost you one comment that says look good. That's it. Let's see the high debt PR now. Now, you see what you see actually on the screen is from a public repo. This is a real scenario from the scanner regression suite. If you see, the score is here 60 out of 100. It requires evidence. It's on the audit and it says needs evidence. 86 estimated minutes of review effort. Look at the structured output. It's actually not a score. A wire list explaining what fired. A reviewer focus list telling the reviewer what to do next. An author next action list telling the author how to bring the score down. This is the part most PR quality tool miss. The score alone is useful. The structured advice is what actually moves the team behavior. Now, if you read the bullet point, it says PR has soft indicators of AI assisted authorship. This is information only, not a definitive claim, and not a penalty on its own. This particular step sentence is in the scanner output. The AI indicator check contributes five of the 60 points, which is nearly about 8%. The other 55 came from a different size claim mismatch and missing test. Those would be high burden signals on any PR, agent authored or not authored. This is not an anti-AI scorecard. Basically, this is more of a review burden scorecard. The agent did not cause the score, but the shape of the PR that is created by the agent did this. Let's see the next one. This is a PR, basically, which is AI authored. It's very well shaped, and the score is seven, seven, which is low review burden. Now, if you see the same agent, it has done the same kind of work, but the test were added. So, the CI is green. The risky path is called out in the PR description. That's why we got the score as seven out of 100. It's very low burden, took only 14 minutes. The AI indicator check still fires, but it contributes 2.1. One, low severity. Second, the framework explicitly says, quoting the report itself, "Information only, not a definitive claim, and not a penalty on its own." So, when your team is going to ask, "Will this tool penalize us for using coding agents?" No, the answer is on your screen, low review burden. It's a very well shaped AI PR.规模化落地与代码治理模型
对跨越 3 个公开代码仓库、包含 524 个拉取请求（PR）的 90 天数据扫描分析表明，代码库的总体审查工作量是由**PR 提交量（Volume）**直接决定的，而非单纯取决于 AI 编写代码比例的上下波动。在扫描中，有四个 PR 触发了高危信号并落入“需作者说明”或“高审查负荷”区间，它们均涉及底层的结构性修改，例如大规模的版本迁移、SDK 重构或跨多团队的文件调整。这印证了 ReviewDebt 框架能够公平地反映出复杂度的累积，而不会对合理使用 AI 的团队产生误判。
为了有效遏制审查债务的无序扩张，Sachin Gupta 提出了五步法落地路径：
- 历史追溯（Backfill）：在公司内部对过去合并的 200 个 PR 运行评分器，找出得分最高的 PR 并进行根因复盘。
- 基线划定（Threshold）：设定明确的审查准入线（默认建议为 50 分）。超过该分数的 PR 必须附带作者关于必要性的书面说明。
- 流程显性化（Surface）：在每次 PR 提交时以非阻塞式评论自动张贴当前 ReviewDebt 评分，让审查负担透明化。
- 周度聚合（Aggregate）：按团队聚合每周的分数斜率（Slope），以便工程经理敏锐察觉系统债务的增长趋势。
- 常态化讨论（Talk about it）：在迭代回顾与路线图讨论会中常态化引入该量化指标，将开发团队的讨论从感性的倾诉引向理性的度量。
展望 2027 年，AI 辅助研发的行业共识必将由“工具的采纳”彻底转向“系统性的治理模型”。团队必须能够回答：我们提交的代码是否真正可信？当 AI 编写的代码引起线上故障时，谁来承担最终的追责？ReviewDebt 评分机制正是帮助团队在享受 AI 速度红利的同时，守住工程质量与系统信任防线的桥梁。团队应当尽早纠正“QA 兜底”或“逢 PR 必写 LGTM”的粗放习惯，用量化数据赋能每一次代码的平稳交付。
Original English Source
We are going to see the next one, which is basically our three public repos over 524 PRs. I wanted to show you a 90-day AI search slope across three public repos and 524 pull request. The review burden climbs even when the AI authorship doesn't. If you see this particular scan, we observe three things. One of them is the volume is the actual variable. AI authorship was flat and it was 5 to 20% steady state, but the review burden was not. If you see one repo accumulated 186 senior reviewer hours in 27 days and another one took 43. The window length is same, but the volume was not the same. The burden was not the same. That is what PR volume is. Second is amplifier only holds up under real data, which means AI indicators fired on 5 to 20% of PRs every week across all three repos. None of those AI authored PRs disproportionately landed in the high burden band. The positioning contract holds against real code bases. Third one is complexity drives burden, not authorship, which means across 524 PRs four landed in needs evidence or high bands, which means all four were structural changes, which were large migration, SDK rewrites, multi-team refactors. The framework score complexity fairly. AI driven volume creates the condition under which these accumulate. So now, what 524 PR look like under the lens? Where does the review debt actually show up? In absolute terms, the scanner saw 524 real pull request in three public repos, 228 senior reviewer hours cumulative across three public repos that were scanned over 27 to 90-day windows. Second one is nine PR per day sustained merge rate the high velocity repo. So, if you see, it's all about the volume that is basically driving the burden. Third one is 5,036. These are the minutes that are basically spent on a single PR, which is nothing but 84 hours of review effort estimated for one single pull request. The score that we received there was 73, which said it requires an evidence band. Now, 5 to 25% of these PR every week across every week fired at AI indicator signal. Again, remember this is volume, which is causing the review debt, which is changing the game altogether. We'll move to the next slide. Measure the problem. We have shown the cost. Now, what do we do about it? So, first thing is you should have one logical change per PR. I'm not saying like not small PR in the abstract. One logical change, that is enough. Second, test ship with the change. Even if the agent wrote the code, even if the agent wrote the test, the human author confirms the test assert what the code should do, not what the code is doing, what the code is supposed to do. Okay? Third, stay in one owner territory. Cross-cutting work splitting into per per team PR. Remain in your own territory. One approval, one context, one mental model. Author writes the why. The agent should not write the PR body. That's the moment the human author commits to understanding what they are actually shipping. Same review standard for the AI PRs as human PRs. The AI indicator amplifier only fires when other signals are weak. Keep the other four strong. The amplifier is invisible. So, make sure there is no exception for AI. None of these is actually requiring you to have a new tool. These are the moves that you already are aware of. You just need to implement it. Now, how are you planning to adopt this? If you see, we again have five steps. Backfill, threshold, surface, aggregate, and talk about it. Backfill. So, you run the scorer over your last 200 merge PR. Look at the one basically that has the highest score. Second, threshold. Set a basically justify line. Default, let's say you want to give it to 50. So, any PR scored at 50 or above requires a comment from the author. As simple as that. Surface it. Post the score as a PR comment on every PR. Don't block it. Just for the visibility purpose, surface it so that everybody should know what's happening over there. Aggregate weekly per team. Which means the slope of each team deadline is the leading indicator. That's what your engineering manager should watch. Talk about it. Bring the number to a retrospective, every roadmap view. In every meeting, you should discuss about that number. Like, what was your score when you did this particular PR. That's it. Why this number matter? Because of this conversation? Absolutely not. Without a number, what you are just conversing is why. But if you have a number, it's actually structured. You can tell like, okay, with AI coding agents, we have a rollout which has added X percentage of the throughput. But you need to make sure you are also adding the Y points of the review debt that has been occurred over Z weeks. Now, at your current slope, that's roughly N senior N senior engineer hours that you need to talk about. That moves the discussion from feeling to measurement. So, you should always have a number. If you see 2026, we are adopting things. But, 2027 is the year when this conversation will shift to the governance model. And, it's actually starting right now. Can you trust the code that you're shipping? If yes, we are good. If no, then who is accountable when an AI authored change causes an incident? Where is the audit trail? So, reviewed it is basically the bridge between these two columns. It's the first number that lets you have the right-hand side conversation without abandoning the left-hand side gains. We'll look into the final slide now. Now, three things I would like you to take away. First one is, measure the gap. Don't build the tooling yet. Take 20 PRs from the last week, score them using the five signals that we discussed. You will basically get a number so that you will understand, okay, whether the framework is working right or not. Try to make the slope visible. The slope of a reviewed it over time matters most than the level. So, plot it weekly, and then discuss it with your team maybe in a meeting or in a sprint planning, whatever the way you feel like. Have this conversation. Bring the number to your next review. Like, say that, okay, we do have extra report, wide it, and this is the slope. And, then you are basically moving away from the wide culture to the measurement culture. One quick callout on anti-patterns to avoid. First thing is, approve with comment merges. The AI did the boring part. No. We'll catch it in QA. No. PRs smaller now. No. Stop writing LGTM on the PRs. Make sure whatever we have discussed, the habits that we have discussed, we are going to follow them. This is the entire point of the talk. Thank you very much for listening.📌 文中提及的人物和组织
人物: Sachin Gupta