Greptile AI Code Review Tool - Automated GitHub PR Review Bot with Full Codebase Understandinggreptile PricingSecurityBlogDocs AI Code Review: Should the Author Be The Reviewer?

AI Code Review: Should the Author Be The Reviewer?

今天 作者：Daksh Gupta 另一个标题：我正在使用 AI 编写代码。使用 AI 来审查它是否很傻？ 我是 Daksh，是 Greptile 的联合创始人。我们的产品使用 AI 来审查 pull requests，以发现人工可能会忽略的 bug 和反模式。这是一个例子 展示了它的外观。 最近，我很好奇在单个 Greptile 用户打开的 PR 数量中是否存在幂律。换句话说——是否有些用户打开的 PR 比其他用户多几个数量级？ 在执行了一个简单的 SQL 查询后，我发现确实存在幂律。 我还注意到一些非常有趣的事情： Chart showing PR authors with Devin AI at the top 在长长的 GitHub 用户名列表的最左侧是“devin-ai-integration[bot]”。一个 AI 机器人编写的 pull requests 比任何个人人类都多。[1] 鉴于 Devin 使用与 Greptile 相同的底层 LLM，这确实提出了一个有趣的问题——作者是否应该成为审查者？

[1] 诚然，这在某种程度上是一个技术细节。Devin 在多个组织中的贡献在这里被汇总计算。更准确的做法是将“Devin @ Company A”和“Devin @ Company B”视为该图表中的单独条目。

作者应该成为审查者吗？

大多数软件公司不希望 PR 审查者与 PR 作者是同一个人。 PR 审查发生的一个重要原因是确保每个新的代码段都获得_新鲜的_视角。让 Claude Sonnet 生成一堆代码，然后期望 Claude Sonnet 在其中找到 bug，这似乎很傻。 有几个值得讨论的对立观点：

无状态性 (Statelessness)

如果你使用过 LLM APIs，你会注意到它们是无状态的。每次推理调用都是对智能的全新请求。因此——要求 LLM 审查自己的代码_确实_是用新鲜的视角来看待它。

脚手架 (Scaffolding)

脚手架通常指的是工具用来包装 LLM 调用的特定工作流程，以使其能够完成手头的任务。 对于 AI 代码审查器，它可能是审查差异、检查 bug、编写注释以及最终自我评估注释严重程度所需的一组步骤，以及沿途的上下文检索，以确保它正在查看相关的文档文件和代码库中的其他代码文件。 对于 Devin，它可能同样复杂且完全不同。 换句话说，审查者实际上与作者有很大不同。 这两辆不同的车只是恰好拥有相同的_引擎_。

两个人之间到底有多大差异？

在 AI 时代之前，PR 的作者和审查者是两个不同的人。 但是，他们都包含着相同的核心智能，这与两个 AI 工具没有什么不同。 从生物学角度来看，他们不仅拥有功能上相同的头脑，而且由于他们都是训练有素的工程师，并且由于他们是同一公司的同事，因此甚至具有共享的知识和共享的背景。

AI 生成的代码需要更仔细的审查 (AI-Generated Code Needs Closer Reviewing)

AI 代码并非垃圾，但有点马虎 (AI code isn’t slop, but it is a little sloppy)

毫无疑问，AI 使程序员更快、更有效率。 也就是说，在我看来，AI 降低了 _优秀_工程师编写的代码的平均质量。 这并不完全是因为模型产生的代码比优秀的工程师编写的代码更差。 这是因为：

  1. Prompting 是一种不完美的、有损的方式，可以将需求传达给 AI
  2. 工程师低估了这一点，并且没有像审查自己的代码那样仔细地审查 AI 生成的代码。

原因 #2 不是自满，人们可以以思考和打字的速度审查代码，但不能以 LLM 生成的速度审查代码。 当你输入代码时，你会边写边审查，当你 AI 生成代码时，你就不会这样做。

有趣的是，对于平庸的工程师来说，情况恰恰相反，对于他们来说，AI 实际上提高了他们产生的代码的质量。 AI 只是让好的和坏的工程师都趋同于相同的平均水平，因为他们更多地依赖它。 Graph showing code quality convergence between good and mediocre engineers when using AI

人类不擅长捕捉 AI 引入的那些类型的 bug (Humans are bad at catching the types of bugs that AI introduces)

AI 生成的代码 通常包含更多的 bug。 此外，这些 bug 不是人类会引入的类型。 你有多少次发现 Cursor 的“Apply”功能更改了你期望它更改的一行代码，而你直到后来才注意到？ 其中有多少 bug 是你认为自己可以在没有 AI 的情况下引入的？

此外，PR 审查并不是捕捉 bug 的好方法。 人类不太擅长检测它们， 因此 PR 审查往往更多地是一种风格/模式的强制执行，偶尔也是一种架构审查。

奇怪的是，事实证明 AI 确实_比人类更擅长在代码中发现 bug。 在我们的测试中，我们发现最新的 Anthropic Sonnet 模型正确识别了我们 bug 查找基准“困难”类别中的 209 个 bug 中的 32 个。 作为参考，Greptile 中没有一个技术精湛的工程师能够识别超过 5-7 个。 Graph showing AI bug detection performance compared to humans 请注意，32/209 也不是_很好，它只是比人类开发人员更好。

最新消息：二手车推销员真诚地认为你需要一辆二手车 (Just In: Used Car Salesman Sincerely Feels You Need A Used Car)

免责声明，以防它不清楚——我们销售 AI 代码审查器，所以请自行决定是否采纳。 这不是为了说服你购买而进行的智力不诚实的行为，而是导致我们首先致力于 AI 代码审查 的真诚的智力诚实的尝试。

立即试用 GREPTILE (TRY GREPTILE TODAY)

AI 代码审查器，了解你的代码库。 合并速度提高 50-80%，捕获的 bug 数量增加 3 倍。 免费试用了解更多 14 天免费，无需信用卡 Greptile AI Code Review Tool - Automated GitHub PR Review Bot with Full Codebase Understandinggreptile GitHubXLinkedInDiscord

产品 (Product)

PricingCode Review BotIssue EnricherDocsAPIZapierSecurityPrivacyStatus

公司 (Company)

BlogCase StudiesPodcastLinkedInTerms of ServiceCareersCompetition联系我们 (Contact us)

实用链接 (Helpful Links)

Greptile vs CoderabbitCode Review ChecklistShip Faster SurveyRoast My RepoAbout Us Backed by Y Combinator Logo © 2025 Tabnam, Inc.