21CTO 导读：使用AI 编码目前似乎陷入一个悖论中，用与不用的区别和优缺点到底在哪里？

数据展示起来

研究人员对此进行了分析。哈佛大学研究员菲奥娜·陈（Fiona Chen）和詹姆斯·斯特拉顿（James Stratton）动用了Jellyfish所提供的汇总分析数据，此工具用来衡量工程团队的细颗粒度产出情况。这些数据涵盖了3亿个独立的"工作事件"（例如提交与拉取请求），以及2021年至2026年3月期间，700多家相关软件开发、科技企业、超过70万名员工的问题管理软件的数据。

研究人员还综合使用了直接测得的AI使用情况，以及对GitHub的活动分析，确定每家公司何时开始将AI编程助手（主要辅助人类自动完成代码）或AI编程智能体（主要根据提示自主编写并提交代码）引入其工作流程。研究人员通过较为复杂的计算方法，对不同组织在不同时间点引入这些工具前后的关键变量进行了"双重差分"的回归分析。

就原始代码产出而言，研究结果清晰而鲜明。企业引入AI编程智能体后，生成代码总行数平均增加30%，提交总数增加20%，拉取请求平均增加23%。但所有这些额外的代码并没有直接转化为企业层面软件产出的提升。相反，Jira等工具跟踪的"问题"和"史诗"（即整体软件功能）的解决率，在引入AI工具后也并未出现统计学意义上的显著变化。

这种差异的原因可以直接从代码审查流程中找到答案，该流程在引入AI编程智能体后明显耗时更长。总体来看，从拉取请求提交到最终合并进代码库之间的平均"审查流程"时间，在引入AI智能体后平均膨胀了49%。

研究人员发现，AI智能体引入后，从事代码审查工作的员工比例增加了14%。他们还写道，在查看Jellyfish上的活跃员工总数并与这些企业的LinkedIn数据进行交叉比对后，"无法将显著的用人变化归因于AI"。

尽管理论上AI也可以帮助处理审查流程，但研究人员发现，到目前为止，这种影响仍然微乎其微。到2026年3月，被调查企业中有80%使用了某种形式的AI代码审查，但AI智能体仅贡献了全部审查评论的23.3%和全部拉取请求的10.8%，这表明绝大部分此类工作仍需人类承担。

人们无法信任AI生成的代码

AI代理能够在几分钟内提供初步解决方案并提高产量。代理生成的变更（包括代码修改、服务重构和测试编写）的增加意味着人工审查无法跟上步伐。因此软件开发组织面临的关键挑战不是编写更多代码，而是建立对进入生产环境的代码的信心。

已完成的拉取请求并不能保证可靠的结果，因为代码可能编译通过测试，但仍然违反架构约定或引入安全漏洞。

组织可以通过包含意图、指导原则、验证和证据的公式，将代码可靠性融入软件交付系统中。

代码信心的关键支柱是什么

工程师、产品经理意图要求在代理开始工作之前，要明确业务逻辑、安全预期、设计模式和性能需求。

Guiderails 将这种意图转化为操作边界，定义允许的存储库、依赖关系、数据、操作和人工审批点。验证包括独立检查每一项变更的正确性、可靠性、安全性、可维护性以及是否符合组织标准。

组织不应仅仅依赖产生变更的同一概率系统来判断其安全性。

证据提供了应用标准、执行检查、调查结果和解决方案的持久记录，使质量可衡量、可审计。这种方法有助于团队随着时间的推移改进实践，并为快速发展提供可靠的基础。最有效的智能体软件开发愿景是将人、智能体和验证系统整合在一起，让它们各自发挥优势。

能够将代码可靠性融入到每一次变更（无论变更量大小，无论变更速度快慢）的组织才可能获得成功。

结语

当然，AI智能体在编程领域仍是相对新生的事物，截止本次研究2026年3月的数据截止日期以来，其产出也经历了显著的更新和升级。虽然截至目前，研究所涉企业中已有95%引入了AI编程智能体，但许多企业无疑仍在摸索在何时、如何最佳地部署这些工具。

就目前而言，让AI编写代码看起来像是一把双刃剑：编码速度的提升被人工代码审查时间和精力的相应增加所抵消。这样的结果不禁让人怀疑，对大多数公司而言，投入大量时间和成本去让AI编程智能体运转起来，究竟是否真的值得。

作者：洛逸