跳到正文
Tessl Blog· Nicholas Arcolano·· 3 小时前AI 评分58

Jellyfish 数据:编码智能体已写 22% 的 PR,但仅 0.6% 由智能体独立合并

There Aren’t Enough Chaperones for All Your Coding Agents

AI 导读

Jellyfish 统计约 1300 家公司、30 万名工程师的数据发现,企业中位水平的公司已有 22% 的合并 PR 由自主编码智能体编写,较一个月前的 18% 上升,前 10% 公司达 53%。

正文 · 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。我将在我的演讲《Botsitting Doesn’t Scale: How to Navigate the Autonomy-Trust Gridlock in Real Engineering Orgs》中谈论这个话题以及更多内容,并分享我们从分析 Jellyfish 数据中了解到的、关于最优秀的工程团队如何应对 2026 年最大工程工作流挑战的经验。

来源:Tessl Blog · tessl.io