来源笔记
Understanding the Rejection of Fixes Generated by Agentic Pull Requests -- Insights from the AIDev Dataset
摘要
本文研究 AI 代理提交的修复型 pull request 为什么会被拒绝，基于 AIDev 数据集中的 306 个被拒绝修复样本。这个问题很重要，因为 Copilot、Devin、Cursor 和 Claude 提出的修复中有 46.41% 被拒绝，这会浪费评审时间、测试成本、token 和算力。
问题
- AI 编码代理经常提交修复 PR，但开发者后来会关闭它们而不合并。
- 论文想回答这些修复型 PR 为什么失败，以及它们浪费了多少评审工作。
- 目标是让代理生成的修复更容易信任，也更便宜地审查。
方法
- 作者使用 AIDev 数据集，筛选出由 Copilot、Devin、Cursor 和 Claude 创建或共同创建的 bug 修复 PR，并从 1,497 个被拒绝修复中抽取 306 个样本。
- 两位作者通过阅读讨论、CI 结果和相关工件，手动标注每个 PR，然后由第三位作者协调分歧。
- 他们建立了一个包含 14 个原因、分为四个高层主题的拒绝分类法。
- 他们用每个拒绝类别的代码变更量和评论数来衡量浪费的工作量。
- 他们报告了一致性指标 Cohen’s κ = 0.605。
结果
- 数据集中有 3,225 个来自这四个代理的修复 PR，其中 1,497 个被拒绝，拒绝率为 46.41%。
- 人工研究发现了四个主题下的 14 个拒绝原因：相关性、实现问题、提供方失败和技术问题。
- 相关性问题是最常见的可见原因，主要是无活动 53 例（17.3%）和被新 PR 取代 18 例（5.9%）；低优先级有 3 例（1.0%）。
- 实现问题包括修复不正确 17 例（5.6%）和方法错误 8 例（2.6%）；CI 失败占 21 例（6.9%）。
- 被拒绝的 PR 的代码变更量中位数在 81 到 293 行之间，技术问题的变更量最高，实现问题的中位数大约为 103 行。
- 被拒绝的 PR 中位数评论数为 1 到 4.5 条，与已合并修复相近，所以大量评审讨论最终落在了后来被丢弃的改动上。