文章
你的编码智能体不够配监护人了探讨工程团队中管理 AI 编码智能体的挑战。了解为何会产生信任问题，以及如何有效监督它们。
Nicholas Arcolano
·2026年10月21日·8分钟阅读
想象一下，你领导着一个工程团队，而你对其中 20% 的开发者存在严重的信任问题。
这些开发者足够可靠，你会让他们写代码，但他们需要相当多的监督。他们不能独自评审他人的工作，当然也不能批准将代码合并到重要系统。就开发者而言，他们属于二等公民。
传统软件工程会将这种状况视为严重的结构性问题。高效的开发团队建立在信任高自主性个体的基础之上——这些个体（配合良好的流程和保障措施）能够编写、评审和发布代码，而无需被微观管理。
然而，这正是当今典型工程团队所处的境况，只不过我们所说的这 20% 的开发者是 AI 智能体。大多数团队要求每个智能体都有人监护——而监护人根本不够用。
智能体信任问题，两张图说清
在 Jellyfish，我们追踪工程组织如何使用 AI 编码工具和智能体，以及这种使用如何与产出相关联，比如实际交付了什么代码、正在构建什么产品和功能，以及这些事情的成���是多少。通过我们的平台，我们可以洞察约 1,300 家公司中约 30 万名工程师和超过 1 亿个拉取请求，这是业内最大的软件工程工作流数据集。
在我们最近一期的月度 AI 工程趋势报告中，有两张图尤其凸显了工程团队在扩大自主编码智能体使用规模时当今所面临的挑战。
第一张是自主智能体活动，我们将其定义为一家公司已合并 PR 中由自主编码智能体撰写的比例（即由编码智能体编写代码、提交 commit 和/或发起 PR）。中位数公司目前为 22% 的 PR，高于一个月前的 18%。处于第 90 百分位的公司为 53%。
按公司百分位划分的自主智能体活动。来源：Jellyfish AI 工程趋势，2026 年 9 月。
对于任何在 2026 年使用过 AI 编码智能体的人来说，这些工具惊人的采用率应该不会太令人意外。执行框架和模型能力的进步，使 AI 编码智能体能够接管很大一部分编码工作负载。但可以说，这只是“原始编码”部分——你仍然需要批准、合并和部署这些代码。
让我们再看另一张图：“智能体合并的 PR”，即由智能体评审并合并、未经人工评审的拉取请求。这种做法要少见得多。中位数公司仅对约 0.6% 的 PR 实现了纯 AI 评审，而排名前 10% 的公司为 9%，且仍在攀升。
按公司百分位划分的智能体合并 PR。来源：Jellyfish AI 工程趋势，2026 年 9 月。
因此，在典型公司中，智能体现在撰写了约五分之一的代码，但几乎所有这些代码在流程的某个环节都需要人工介入。这种人工监督是建立信任和确保质量的合理方式，但它也构成了编码智能体能够提供多少额外产能的硬性约束。
人人都在谈论软件工厂，但一个每个单元在出厂前都必须经过人工检验员的工厂并不是工厂——它只是一个拥有更多传送带的手工作坊。
评审瓶颈是一个 ROI 问题
评审瓶颈不仅让工程师们压力山大，也让领导团队倍感压力，因为它是 ROI 问题的一大成因。
所谓“ROI 问题”，我指的是代码创建的上游加速远比下游影响更为显著。例如，在 2026 年全年，我们普遍测得拉取请求增加了约 2 倍，但产品产出（如交付的功能）仅增加了约 40-50%。
造成这一差距的一个原因是，智能体撰写的 PR 中途夭折的比例要高得多。当人类撰写 PR 时，约有 20% 的情况未能合并，原因各种各样且完全正常（例如实验性工作、方案错误、新需求、优先级变化）。而对于智能体，放弃率翻倍（40% 对 20%）。与此同时，确实合并的智能体 PR 受到的审查不是更少而是更多：在过去一年里，每个已合并智能体 PR 的人工评审次数增加了一倍以上。
这一切本身并无不合理之处。智能体代码确实更难评审，评审者对其保持谨慎是正确的。问题在于，随着编码智能体能力持续增长，这些负载给系统带来的压力。评审负载随智能体产出的增加而扩大，而人类注意力仍是固定约束，并且我上面展示的自主性曲线每个月都在复利增长。
如果今天的中位数公司达到今天前 10% 公司的水平（自主智能体撰写超过一半的代码），代码评审有可能变成人类的全部工作，从而挤占经验丰富的开发者本应从事的所有其他重要事项的时间，比如与产品和设计协作、塑造软件架构，以及将他们的工程判断力用于没有明确解决方案的问题。
如何更快地建立信任
幸运的是，一些公司正在解决这个问题。那些自主智能体合并了 9% PR 的顶尖公司，并不是盲目地更加信任他们的智能体。相反，他们投入精力来加速信任的建立。
通常，这需要大量的平台工作，例如将低风险工作路由到自主智能体的系统、用于安全可靠开发和部署的沙箱与预发布环境，当然还有大量、大量的自动化测试。不过，也许最重要的是，他们很早就开始并且正在大力推进；信任只能随着时间建立，你等得越久，就必须越久地忍受不断堆积的评审积压。
为每个智能体安排陪护是合理的起步方式，但这种方式无法扩展。
如果你有兴趣进一步了解自主智能体如何演进（或者更准确地说，如何颠覆）软件开发生命周期，欢迎来参加 aiDevCon ，11 月 2 日至 4 日在纽约市举行。我将在我的演讲 《陪护式看管无法扩展：如何在真实工程组织中应对自主性与信任的僵局》中谈论这一点以及更多内容，并分享我们从分析 Jellyfish 数据中学到的内容：最优秀的工程团队如何应对 2026 年最大的工程工作流挑战。
复制并分享
Nicholas Arcolano
我是 Jellyfish 的创始团队成员兼 AI 与研究负责人，我和我的团队研究 AI 转型如何重塑软件行业。我们拥有独特的真实世界视角，可以了解数十万名开发者如何在生产环境中使用 AI 编码工具和智能体，并利用这一视角帮助工程领导者明智地投入、更快地交付，并专注于对业务真正重要的事情。 我在初创公司工作了 13 年，在此之前还在麻省理工学院林肯实验室从事了 10 年国防研究。我的背景是应用数学（哈佛大学博士）和电气工程（波士顿大学硕士、伍斯特理工学院学士）。
1 篇文章
阅读
·
0%
本文内容
智能体信任问题，两张图看懂评审瓶颈是一个 ROI 问题如何更快地建立信任复制并分享
Nicholas Arcolano
我是 Jellyfish 的创始团队成员兼 AI 与研究负责人，我和我的团队研究 AI 转型如何重塑软件行业。我们拥有独特的真实世界视角，可以了解数十万名开发者如何在生产环境中使用 AI 编码工具和智能体，并利用这一视角帮助工程领导者明智地投入、更快地交付，并专注于对业务真正重要的事情。 我在初创公司工作了 13 年，在此之前还在麻省理工学院林肯实验室从事了 10 年国防研究。我的背景是应用数学（哈佛大学博士）和电气工程（波士顿大学硕士、伍斯特理工学院学士）。
1 篇文章