内容概要
Jellyfish 的研究负责人 Nicholas Arcolano 分享了基于分析 2000 万个 Pull Request（拉取请求）和 20 万名开发者的使用数据得出的洞察，旨在揭示 AI 对软件工程的真实影响。本次演讲涵盖了成功的 AI 采用是什么样的、在 PR 吞吐量（Throughput）和周期时间（Cycle Time）方面可量化的生产力提升、诸如 PR 规模增加等副作用，以及代码架构在实现这些收益中发挥的关键作用。
目录
-
引言与关键问题
-
数据方法论
-
定义良好的采用情况
-
自主智能体（Autonomous Agents）的现状
-
衡量生产力提升
-
副作用：PR 规模与质量
-
代码架构的影响
-
回顾与总结
引言与关键问题
大家好，我是 Nicholas Arcolano，Jellyfish 的研究负责人。今天我想和大家探讨 AI 转型，特别是通过真实世界的数据来揭示当下的实际情况。
目前，许多 AI 原生（AI-native）公司正在成立，还有更多现有公司正试图转型为 AI 原生企业。我与这些公司的人交流时，发现大家都有同样的几个大问题。
第一：AI 编码工具和智能体的“良好采用”究竟是什么样子的？ 第二：在我们转型团队和工具的过程中，应该期待什么样的生产力提升？ 第三：这种转型的副作用是什么？ 也许最重要的是，如果 AI 转型没有带来预期的效果，到底出了什么问题，又能做些什么？
在 Jellyfish，我们相信获取答案的最佳方式是通过数据。因此，在接下来的 15 到 20 分钟里，我将分享一些基于我们研究的数据洞察，帮助大家解答这些关键问题。
数据方法论
在开始之前，我们先花点时间谈谈本次演讲背后的数据来源。Jellyfish 为软件工程领导者提供分析和洞察服务。
为了做到这一点，我们结合了多个来源的信息，包括与 AI 编码工具（如 Copilot、Cursor、Claude Code）的交互和使用情况，与自主编码智能体（Autonomous Coding Agents，如 Devin 和 Codex）的交互，以及 PR 审查机器人。
我们将这些数据与来自源代码管理平台（如 GitHub）的数据相结合，以便了解发生实际工作的代码库情况。我们还引入了任务管理平台（如 Linear 或 Jira）的数据，这能告诉我们正在进行的工作的实际目标是什么。
本次演讲的其余部分，我们将基于通过上述方式收集的客户数据。该数据集包含约 2000 万个 Pull Request，由来自约 1000 家公司的 20 万名开发者编写并合并。我们收集这些数据已有一年多，因此今天我们将查看从 2024 年 6 月至今的结果。
定义良好的采用情况
让我们深入探讨第一个问题：良好的采用是什么样子的？我们先从代码行数说起。我不认为这是一个很好的指标，但媒体经常提到它，所以值得一谈。
这是我们要自去年 6 月以来追踪的一组公司的数据。图表显示，从去年夏天开始，只有约 2% 的公司有 50% 或更多的代码是由 AI 生成的。但你可以看到这一比例一直在稳步增长，截至上个月，在这些公司中，现在已有近一半的公司通过 AI 生成了 50% 或更多的代码。
我认为更有价值的观察指标其实是“开发者采用率”，因为它触及了你希望在团队中看到的实际行为变化。这也是我所见过的与良好生产力结果最直接相关的指标，我们稍后会详细讨论这一点。
首先，我们通过计算开发者在编码时使用 AI 工具的时间比例来定义“AI 采用率”。对于一个开发者来说，100% 意味着你每次编码都在使用 AI 工具。一家公司的采用率则是其所有个人采用率的平均值。
数据显示，截至去年夏天，采用率的中位数约为 22%。也就是说，中位数公司的开发者在编码时有 22% 的时间在使用 AI。自那以后，这一数字稳步增长，如今我们看到的中位数采用率已接近 90%。
如果你像我一样，持续并行使用多种工具（包括同步和异步模式），你的采用率可能就是 100%。你可能会觉得其他人没达到 100% 很不可思议。然而，现实情况是，对于许多团队来说，要更全面地采用这些工具，仍然存在真正的技术、组织和文化障碍。
自主智能体（Autonomous Agents）的现状
这引出了关于采用率的最后一点。你可能会问：自主编码智能体怎么样？刚才展示的结果绝大多数来自交互式编码工具（如 Copilot、Cursor、Claude Code）。虽然这些工具都有交互式的智能体模式，但那些真正的全自主智能体（如 Devin 或 Codex）呢？
也许你正在通过这些智能体或其他工具获得很好的效果，或者你还没有真正开始使用自主智能体。无论你处于哪个阶段都没关系。如果感觉在自主智能体的起步阶段进展缓慢，我想告诉你，你并不孤单。
在我们的数据集中，只有约 44% 的公司在过去 3 个月内对自主智能体进行了任何尝试。其中绝大多数工作属于“试用和实验”性质，而非大规模生产应用。最终，在同一时期合并的数百万个 PR 中，由自主智能体完成的占比不到 2%。所以，我们仍处于非常早期的阶段。
衡量生产力提升
接下来我们谈谈生产力。尽管自主智能体尚未大规模交付成果，但我们仍然看到交互式编码智能体的采用带来了巨大的收益。
首先，我们所说的“生产力”指什么？这是一个承载很多含义的词，定义方式多种多样。一个好的起点是朴素的“PR 吞吐量”（PR Throughput）。平均每个工程师每周合并多少个 Pull Request？这不是最奇特的指标，但它经过了验证并被广泛接受。
请注意，PR 吞吐量的绝对水平是变化的，它取决于诸如工作范围界定方式等因素，实际上也取决于你的架构——请先记住这一点，稍后我们会详细讨论。然而，测量 PR 吞吐量的“变化”（尤其是保持其他因素不变时），是追踪生产力提升的好方法。
另一个好指标是“周期时间”（Cycle Time）。其定义也有很多种，基本上是指代码部署的延迟或交付周期。为了便于分析，我们针对每个 PR，测量从该 PR 的第一次提交到其被合并的时间跨度。
关于 PR 吞吐量的变化，我们看到了明显的关联：AI 采用率与 PR 吞吐量之间存在清晰的正相关。平均趋势是，从零采用到完全采用，吞吐量大约增加了 2 倍。也就是说，平均而言，一家公司如果从完全不使用 AI 到 100% 采用 AI 编码工具，其 PR 吞吐量有望翻倍。
我们在周期时间上也看到了一些收益，工作不仅更多了，而且速度更快了。数据显示，随着 AI 编码工具的采用率从 0% 到 100%，周期时间平均减少了 24%。
这是一个很有趣的分布图，你可以看到两个明显的水平带。下方的聚集带对应少于一天的任务，中间的带对应大约两天的任务，然后有一条长尾向上延伸，代表耗时更长的任务。
副作用：PR 规模与质量
大局上看，生产力提升是好消息，也许你们的组织中也看到了这些现象。但是副作用呢？众所周知，天下没有免费的午餐。在 AI 转型过程中，还有什么发生了变化？
我们观察到的一件事是 PR 变大了。数据显示，已完全采用 AI 编码工具的团队提交的 PR，在净新增代码行数（Net lines of code added）方面平均大了 18%。
这种规模变化主要源于新增代码，而非删除。这意味着变化的组合主要来自净新代码，而不一定是完全重写或大量修改的代码。
另一个有趣的细节是，平均触及的文件数量基本保持不变。这意味着变化更多是关于代码变得更详尽，或者仅仅是更冗长，并不是说 AI 触及了更多的文件或在代码库的更多不同地方修改代码。这些变化主要发生在相同的文件内。
既然团队提交了更多的 PR，编写和合并的速度更快，且 PR 变得更大，你可能会担心质量问题。我们在使用更多 AI 并更快推送代码时，是否看到了对质量的影响？
目前的答案是：并没有真正看到显著影响。我们查看了创建的 Bug 工单和 PR 回滚（Revert）率，并没有发现与 AI 采用率有统计学意义的关联。
有趣的是，我们发现 Bug “解决”率有所上升。深入挖掘数据后发现，这是因为团队不成比例地使用 AI 来处理积压的 Bug 工单。这很有道理，Bug 通常是范围明确、可验证的任务，AI 编码工具非常适合这类工作。
总的来说，目前还没有关于质量下降的确凿证据，尽管我们会继续深入研究，特别是随着异步智能体使用量的增长。
代码架构的影响
最后一个问题：如果你在自己的组织中看到的情况与我们刚才讨论的结果不符怎么办？如果这不是你的现实情况呢？
我想我已经说得很清楚，首先最重要的是“采用”。在让大家大规模使用这些工具之前，你不会看到收益。这是常识。但也许你们已经有了很高的采用率，却仍然没有看到 LinkedIn 上大家吹嘘的那种生产力提升。这是怎么回事？
我们研究了很多因素，其中有一个特别有趣，那就是“代码架构”。
我所说的代码架构，是指产品和服务的代码在仓库（Repository）中的组织方式。比如是单一仓库（Monorepo）还是多仓库（Polyrepo）。这种代码排列方式可能指示了单体服务与微服务（Microservices）的区别，或者是集中式与联邦式产品策略的区别。
我们衡量这一点的一个关键指标是“每位工程师的活跃仓库数”（Active repos per engineer）。这很简单，就是典型工程师在给定的一周内推送代码的不同仓库数量。
这个指标很酷的一点是它与规模无关。通过计算人均值，我们消除了与公司规模或团队规模的相关性。它告诉我们在日常和每周的基础上，工程师必须处理的代码形态，无论公司有多大。
根据这个指标，我们将架构分为四种状态：集中式（Centralized）、平衡式（Balanced）、分布式（Distributed）和高度分布式（Highly Distributed）。
这就很有意思了。还记得之前展示的 PR 吞吐量 2 倍增长吗？如果我们将数据按照这四种架构状态进行细分，会看到巨大的差异：
-
集中式和平衡式架构：趋势更像是 4 倍增长，远超平均水平。
-
分布式架构：看起来更接近全球平均的 2 倍趋势。
-
高度分布式架构：AI 采用率与 PR 吞吐量之间基本上没有相关性，甚至微弱的趋势略呈负相关。
为什么拥有高度分布式架构的团队会陷入困境？他们似乎没有从 AI 中获得实际收益。
很大一部分原因在于“上下文”（Context）问题。目前大多数工具最好是针对一次处理一个仓库而设置的。跨仓库结合上下文通常很具挑战性——无论是对人类、编码工具还是智能体而言。
此外，这些仓库与它们相关的系统和产品之间的关系，往往甚至没有清晰地记录下来，可能主要锁在资深工程师的脑子里，编码工具和智能体通常无法访问。
这需要团队投入时间进行必要的“上下文工程”（Context Engineering）。这是一个有趣的挑战，特别是考虑到许多人认为微服务是 AI 原生开发的正确方向。我也能预见未来我们解决了这些上下文挑战，大规模采用自主智能体，情况发生反转，高度分布式成为最高效的方式。但就目前而言，这是我们在现实世界中看到的现状。
顺便提一下，在高度分布式架构中，完成事情总体上需要更多的 PR，这是由于迁移、跨仓库协调等原因。这也是为什么绝对数量上的 PR 计数不是一个好指标的原因之一，你确实需要追踪 PR 吞吐量的“变化”来理解生产力。
回顾与总结
最后回顾一下。
-
AI 编码工具正在被大规模使用，但这对于观看本视频的人来说可能不是新闻。但自主智能体目前还处于早期阶段。
-
我们看到了巨大的生产力提升，代码发布更多且更快，即使你只使用了交互式 AI 编码工具（如 Copilot、Cursor 和 Claude Code）。你应该期待 2 倍的 PR 吞吐量变化。
-
你应该预见到 PR 会变大。但也许我们可以减轻一些极端的质量焦虑，目前还没有看到重大的质量问题。
-
最后，你的实际效果可能会有所不同，原因有很多。你可以从思考“代码架构”开始：它是否在阻碍你？你能做些什么来弥补上下文限制？并最终尝试解锁那些令人向往的 AI 生产力提升。
以上就是我分享的全部内容。我是 Jellyfish 的研究负责人 Nicholas Arcolano，非常感谢大家的聆听。
