Jellyfish研究表明，AI编码工具虽提高开发效率，但代码评审复杂化、低质量提交增多，加剧了维护者负担与行业分化。
译自：Jellyfish AI development study: The real sting has yet to land
作者：Adrian Bridgwater
开发者采用或放弃AI编码工具取决于他们对新自动化理念的信任程度、现有项目所提供的自由度以及是否心血来潮。
Jellyfish 公司表示，其最新的AI工程趋势研究旨在分析当前AI工具、软件工程智能和AI影响分析的影响，是对软件工程中AI转型的全面定量分析。
这项研究基于从700多家公司、20万名工程师和2000万次拉取请求（当开发者，现在也包括代理，请求将提议的代码更改合并到共享代码库中以供团队评审时）中提取的数据分析，旨在评估AI工具对软件开发团队的真实影响。
为什么开发者应该关注？
软件应用开发专业人员可以从这项分析中评估目前最实用和高效的工程实践类型，并（即使不总是立即，但最终会）将其应用于自己的工作流程和项目目标。他们还可以衡量整个行业认为这些工具的安全性如何。
Jellyfish 研究中超过一半的公司表示他们持续使用AI编码工具，64%的公司在AI协助下生成了“大部分代码”。这里的底线表明，在所分析的三个月中，AI采用率最高四分之一的开发团队的拉取请求吞吐量翻了一番，而采用率较低的团队则没有。
隐藏的痛点
Jellyfish 指出，特别值得注意的是，完全自主的代码代理活动（即拉取请求完全由AI代理生成）总体上仍处于低位，但正在呈指数级增长，而这正是“痛点”将显现的地方。Jellyfish 研究主管 Nicholas Arcolano 博士认为，这种增长揭示了一个故事；他简单地说，最积极采用AI代码工具的人正在乘风破浪。
完全自主的代码代理活动总体上仍处于低位，但正在呈指数级增长，而这正是“痛点”将显现的地方。
“AI编码工具现在已成为工程团队的默认选择，生产力提升是真实存在的。企业可以使用我们的指标作为客观基准，来衡量其组织对AI的采用和影响。数据显示，AI工具的深度整合与交付吞吐量和工程成果的可衡量改进之间存在明确的联系。最积极的采用者正在脱颖而出，” Arcolano 表示。
该公司的AI工程趋势门户允许任何人根据行业标准评估其成熟度。Jellyfish 客户则享有更多功能，可以使用 Jellyfish AI Impact 能力自动解析并可视化其组织的独特数据和软件工具。输出以定制仪表板的形式交付，精确映射了团队AI采用率与其工程生产力之间的确切关联。
AI编码工具现在已成为工程团队的默认选择，生产力提升是真实存在的……最积极的采用者正在脱颖而出。
“数据很清楚：不采用AI编码工具现在是一种竞争劣势。讨论已经超越了采用阶段——现在是如何以对业务有意义的方式扩展AI。像Copilot和Cursor这样的基于IDE的工具是一个自然的切入点，因为它们正好在开发者日常工作的地方满足了他们的需求，但未来是自主代理。这是一个更大的飞跃，因为代理不仅能加速编码，它们还从根本上改变了整个软件应用开发生命周期的工作方式，” Arcolano 告诉 The New Stack。
触手可及的困境
Arcolano 指出这里存在明显的分歧。他的团队发现了一个鸿沟：他说，去年排名前90%的公司将AI代码工具的采用率提高了大约七倍，而垫底的25%公司几乎为零。
这就是为什么（尽管有基于触手的刺丝囊放电的双关语），软件工程界的落后群体正在受到“蜇伤”。
Yagub Rahimov，Polygraf AI 的首席执行官，同意这里提出的趋势。他说，真正领先的团队不仅是最快采用AI的团队；他们是那些意识到不能仅仅因为机器编写了代码就将人类从评审和测试中移除的团队。他表示，这其中也存在另一个“痛点”。
“Jellyfish 的数据是真实的——我们也看到了同样的情况。在我们的团队中，有15名工程师在他们的技术栈中使用 Cursor 和 Claude Code，我们看到拉取请求的产出速度比以前快了。但吞吐量指标没有捕捉到的是：代码评审现在需要更长的时间，而且变得更加复杂。更多的代码意味着需要检查的表面积更大，而且AI生成的代码有一个特殊的特点，它看起来是对的，直到它不是，” Rahimov 告诉 The New Stack。
无摩擦生产力？嗯，差不多吧
谈到他的团队目前的运作方式，Rahimov 告诉我们，他的公司团队实际发生的变化是：编写代码的时间减少了，但验证时间增加了。他说这是一个净收益，但并非“头条数字所暗示的无摩擦生产力故事”，因此他建议谨慎平衡。他解释说，他的团队目前正在内部试用自己的软件工具集，在整个工程团队中运行一个带有代码检测护栏的安全LLM。
他说，生产力提升是真实存在的，但如果开发者不注意流经其AI工具的代码，风险也同样存在。
在当前现实问题上建立更广泛共识的是 Minimus 公司容器镜像漏洞专家兼开发者倡导负责人 Kat Cosgrove。Cosgrove 借鉴了真实的企业软件用例，目前担任 Kubernetes 指导委员会成员等职务。
“AI开发者工具日益普及，给开源维护者带来了越来越大的负担。提交者懒得运行甚至无法编译的代码、与提交内容毫不相关的拉取请求描述、涉及数十个生成文件的全面文档更改、不理解自己代码内容也无法参与评审的提交者——所有这些以及更多问题，现在都成了已经不堪重负的评审者每周都要面对的常规问题。AI所带来的产出增加，并未伴随着维护者处理这些低质量提交的能力的提升，” Cosgrove 带着明显的抱怨告诉 The New Stack。
对AI拉取请求的更严格控制
Jellyfish 最近还与 Augment Code 建立了合作，后者是一家专注于集成开发环境、命令行界面和代码评审领域的软件公司，旨在为共同客户提供AI遥测功能。Augment 的Context Engine旨在实时理解团队完整的软件技术栈，包括代码、依赖项、架构和历史。这项工作旨在使组织能够准确了解 Augment Code 在工程团队中的使用情况并衡量其影响。
除了其核心的开发者分析工作外，Jellyfish 还与 OpenAI 合作发布了一项研究，探讨了AI对软件开发的实际影响，包括编码助手和代码评审代理的工具采用情况、AI生成代码增长的新数据以及AI对拉取请求吞吐量和周期时间的影响。
Jellyfish 表示，其基准测试网站会定期更新有关此主题的新数据和分析。
