跳到正文
Tessl Blog· Nicholas Arcolano·· 4 小时前精选AI 评分61

Jellyfish 数据:智能体已写两成代码,但人工审查跟不上

There Aren’t Enough Chaperones for All Your Coding Agents

AI 导读

Jellyfish 对约 1300 家公司、30 万工程师的 PR 数据统计显示,中位数公司已有 22% 的合并 PR 由自主编码智能体撰写,90 分位达 53%,但由智能体独立审查并合并的 PR 中位数仅 0.6%,前 10% 为 9%。

推荐理由

基于约 30 万工程师的 PR 数据,作者量化了智能体写码与人工审查之间的落差,并解释这一瓶颈如何拖累投入回报。

正文 · AI 翻译

想象一下,你带领着一个工程团队,而你对其中 20% 的开发者存在严重的信任问题。

这些开发者足够可靠,你会让他们写代码,但他们需要相当多的监督。他们不能独自担任他人工作的审核者,当然也不能批准将代码合并到重要系统中。就开发者而言,他们属于二等公民。

传统软件工程会将这种状况视为严重的结构性问题。高效的开发团队建立在信任高自主性个体的基础之上——这些个体(配合良好的流程和保障措施)能够编写、审核和交付代码,而无需被微观管理。

然而,这正是当今典型工程团队所处的境况,只不过我们所说的这 20% 开发者是 AI 智能体。大多数团队要求每个智能体都有人陪同——而陪同人员根本不够用。

智能体信任问题,两张图表

在 Jellyfish,我们追踪工程组织如何使用 AI 编码工具和智能体,以及这种使用如何与产出相关联,比如实际交付了什么代码、正在构建什么产品和功能,以及这些事情的成 本是多少。通过我们的平台,我们可以洞察约 1,300 家公司中的约 30 万名工程师和超过 1 亿个拉取请求,这是业内最大的软件工程工作流数据集。

在最近一期的月度 AI 工程趋势报告中,有两张图表尤其凸显了工程团队在扩大自主编码智能体使用规模时当今所面临的挑战。

第一张是自主智能体活动,我们将其定义为一 家公司已合并 PR 中由自主编码智能体撰写的比例(即由编码智能体编写代码、提交和/或发起 PR)。中位数公司目前为 22% 的 PR,高于一个月前的 18%。处于第 90 百分位的公司为 53%。

Companies at the 90th percentile are at 53%.

按公司百分位划分的自主智能体活动。来源:Jellyfish AI 工程趋势,2026 年 9 月。

对于任何在 2026 年使用过 AI 编码智能体的人来说,这些工具惊人的采用率应该不会太令人意外。执行框架和模型能力的进步使 AI 编码智能体能够接管很大一部分编码工作负载。但可以说,这只是“原始编码”部分——你仍然需要批准、合并和部署这些代码。

让我们看另一张图表:“智能体合并的 PR”,即由智能体审核并合并、未经人工审核的拉取请求。这种做法远不那么普遍。中位数公司约有 0.6% 的 PR 实现了纯 AI 审核,而排名前 10% 的公司为 9% 且仍在攀升。

The median company has achieved AI-only review for about 0.6% of its PRs, while the top 10% of companies are at 9% and climbing.

按公司百分位划分的智能体合并 PR。来源:Jellyfish AI 工程趋势,2026 年 9 月。

因此,在典型公司中,智能体现在撰写了约五分之一的代码,但几乎所有这些代码在流程的某个环节都需要人工介入。这种人工监督是建立信任和确保质量的合理方式,但它也构成了编码智能体能够提供多少额外产能的硬性约束。

大家都在谈论软件工厂,但一个每个单元在出厂前都必须经过人工检验员检查的工厂并不是工厂——它只是一个拥有更多传送带的手工作坊。

审核瓶颈是一个 ROI 问题

评审瓶颈不仅让工程师们倍感压力,也让领导团队倍感压力,因为它是造成 ROI 问题的一大因素。

我所说的“ROI 问题”,是指代码创建上游的加速幅度远大于下游的影响。例如,在 2026 年期间,我们普遍测得拉取请求数量增长了约 2 倍,但已交付功能等产品产出仅增长了约 40-50%。

造成这一差距的原因之一是,由智能体编写的 PR 中途夭折的比例要高得多。当人类编写 PR 时,约有 20% 的情况无法合并,原因都是些完全正常的理由(例如实验性工作、方案错误、需求变更、优先级调整)。而对于智能体,放弃率翻了一倍(40% 对 20%)。与此同时,那些确实合并了的智能体 PR 反而受到更多审查而非更少:在过去一年里,每个已合并智能体 PR 所获得的人工评审数量增加了一倍多。

这些本身都并非不合理。智能体代码确实更难评审,评审者对其保持谨慎是正确的。问题在于,随着编码智能体能力持续增长,这些负载给系统带来的压力。评审负载随着智能体产出的增加而增长,而人类注意力始终是固定的约束条件,我上面展示的自主性曲线每个月都在叠加放大。

如果今天处于中位水平的公司达到今天前 10% 公司的水平(自主智能体编写超过一半的代码),代码评审就有可能变成人类的全部工作,从而挤占经验丰富的开发者本应从事的所有其他重要事项的时间,比如与产品和设计协作、塑造软件架构,以及将他们的工程判断力用于那些没有明确解决方案的问题。

如何更快地建立信任

幸运的是,一些公司正在解决这个问题。那些让自主智能体合并 9% PR 的顶尖公司,并不是在盲目地更加信任它们的智能体。相反,它们投入精力去加速信任建立的速度。

这通常涉及大量平台工作,例如将低风险工作路由给自主智能体的系统、用于安全可靠开发和部署的沙箱与预发布环境,当然还有大量的自动化测试。不过,也许最重要的是,它们很早就开始并大力推进;信任只能随时间建立,你等得越久,就要越久地忍受不断堆积的评审积压。

为每个智能体充当保姆是合理的起步方式,但无法规模化。

如果你有兴趣进一步了解自主智能体如何演进(或者更准确地说,如何颠覆)SDLC,欢迎于 11 月 2 日至 4 日在纽约市参加 aiDevCon。我将在我的演讲《当保姆无法规模化:如何在真实工程组织中应对自主性与信任的僵局》中谈论这一点以及更多内容,并分享我们从分析 Jellyfish 数据中了解到的、关于最优秀的工程团队如何应对 2026 年最大工程工作流挑战的经验。

来源:Tessl Blog · tessl.io