2026软件工程基准报告——人工智能生产力版

‘26 软件工程基准测试报告 目录 3 12 引言 人工智能已迅速融入工程师每天依赖的工具和工作流程中。AI辅助编码提高了整个行业的产出，但也暴露了新的挑战：在审查、测试、发布和治理方面。许多领导者面临的问题不再是AI是否提高生产力，而是如何衡量和维持这种改进在复杂的人、工具和流程系统中的持续性。 我们非常兴奋地发布第五版软件工程基准报告。2026年的报告是对此类报告最全面的分析，基于来自42个国家的4,800个开发团队的超过810万个拉取请求。今年，我们的研究超越了传统的软件交付指标，探索了今天工程师领导者面临的最重要问题之一：人工智能如何影响软件开发？ 在LinearB，我们将AI生产力视为软件工程智能的下一阶段进化。衡量传统产出如周期时间或PR吞吐量仍然至关重要，但领导者现在也必须理解AI如何影响这些指标，以及它是如何重塑支撑它们的系统、流程和行为。现在评估AI生产力需要定量和定性洞察——不仅要捕捉到性能的变化，还要了解团队如何体验和适应这些变化。 数据来源 4,800支队伍 810万次拉取请求 42个国家 这就是为什么在2026年，我们引入了一个新的质化维度来补充我们的量化数据。除了从软件开发整个生命周期中提取的指标外，今年的报告中还包括了我们的一些见解。2026年工程领导力AI调查一项研究捕捉了工程高管、平台领导者和DevEx专业人士对AI组织影响的观点。他们的经验和观察使数据生动起来，捕捉了开发社区对AI如何改变生产力、代码质量和DevEx的真正世界视角。 [本报告中] 您会发现所有指标都按照以下标准组织：1）所有组织，2）按规模区间，3）按地理位置。需要注意的是，所有数据都已匿名化和标准化。在汇总时，我们使用了P75（第75百分位数）计算方法。P75对极端值或异常值的数据更为不敏感，提供了一个稳健可靠的度量。 我们希望您能喜欢这些关于人工智能如何重塑软件工程技艺和文化的令人着迷的新见解。最重要的是，《2026软件工程基准报告》旨在帮助您不仅了解您的团队处于何种位置，还了解其背后的原因——提供数据和视角，以指导人工智能时代更明智的决策。 [工具提示] 我们已经将数据按以下绩效级别组织，针对每个指标： 精英 Top 10% of included organizations Top 30% of the included organizations好的 公平 以撒·贝瑞 [首席技术官，LINEARB] 顶级60%的机构 底部 40% 的列入机构 度量定义度量定义 送货 合并时间 批准时间 从首次提交到拉取请求发布的用时。短编码时间与低工作量在制品、小的请求大小和清晰的要求相关。 从首次批准合并的时间。这个指标，连同批准时间，是审查时间的一个更细分的部分。 从首次评论到首次批准的时间。该指标与合并时间一样，是审阅时间的一个更细致的划分。 请求拉取时等待有人开始审查的时间。低拉取时间代表团队协作强大和审查流程健康。 部署时间 合并频率 从分支合并到代码发布的时间。低部署时间与高部署频率相关。 完成单个工程任务从“代码”到“生产”不同阶段的交付过程所需的时间。 完成代码审查并获得合并拉取请求所需的时间。低审查时间代表强大的团队合作和健康的审查流程。 团队在一段时间内合并的拉取请求或合并请求的总数。 部署频率 PR成熟度 PR尺寸 代码行修改数量（在拉取请求中）。较小的拉取请求更容易审查，更安全地合并，并且与更低的周期时间相关联。 代码发布频率的度量。精英部署频率代表了一个稳定和健康的持续交付管道。 比例关系为发布PR后添加的总变更与PR中总变更之间的比值。 度量指标定义 可预测性 变更失败率（CFR） 重构的工作代表了遗留代码的变化。LinearB将代码视为“遗留”的，如果它在您的代码库中存在超过21天。 对21天以内代码所做的更改数量。高返工率表明代码更新频繁，是质量问题的先兆。 生产中导致失败的部署百分比。 规划准确性 容量精度 计划工作与实际在冲刺或迭代中完成的工作之间的比率。高规划准确性表示高可预测性和稳定的执行。 所有完成的工作（包括计划和计划外的工作）都按计划工作比例计算。 项目管理 进行中 问题涉及分配者 进行中 问题与估算 与父母相关的问题 与问题关联的分支 该百分比表示您PM实例中与父问题（如史诗或故事）关联的问题或工单数量，不包括子任务。 代码分支中包含对特定PM问题引用的比例，以提供代码更改与计划任务对齐的可见性。 完成PM任务并指定团队成员负责的活跃PM任务所占的百分比。 当前PM任务中已分配时间或努力估计的比例。 度量指标定义 由AI代理创建的拉取请求，运行高级代理流程（例如，被分配高级任务的代理），执行生成代码、提交并创建拉取请求以合并的过程。有时这些PR可能代表较小的任务，如修复简单的错误、拼写错误等。 公关在创建（或从草案移出）后的X=30天内合并的百分比。 注意：我们已将合并阈值标准化为30天，但我们的见解适用于7天、14天，甚至无时间限制的合并阈值。 此类代理的例子包括Devin、Copilot编码代理、OpenAI Codex等。 今年新增：录取率基准 验收率指标和基准对于AI生成的代码尤其相关，因为在AI生成的代码中，所有权模式和验收流程正受到挑战。实际上，早期的验收率基准显示，AI生成的Pull Requests（PRs）与人工操作相比，运行在一个完全不同的性能范围内，这突显了这项工作流程的新颖性和不均衡性。 今年，我们很高兴在研究中增加一个新的基准： 录取率 接受率是指在创建（或从草稿中移出）后X=30天内被合并的PR的百分比。 尽管团队只有在手动PR的接受率超过95%时才被认定为精英团队，但AI PR的接受率只要超过71%即可达到同一级别，这个门槛明显更低，反映了团队处理AI贡献的当前实际情况。 工程领导者们正在说些什么 我们的调查回复清楚地表明，环境（而不仅仅是正确性）是合并AI生成的公关内容最大的障碍。领导们告诉我们，AI通常会产生表面上看似合理的变更，但却缺乏更深层次的合理依据、意图或情境意识，而这些正是审阅者需要感到自信批准这些变更所必需的。没有这个环境，即使是看起来干净的代码也可能感觉有风险：审阅者担心潜在的不良影响、缺失的假设或与系统实际工作方式不一致的逻辑。因此，他们会放慢速度，提出更多问题，或者完全拒绝PR——并不是因为代码有误，而是因为他们无法信任他们不完全理解的内容。 FOR AI PRS, MOST TEAMS FIND IT HARD TO EXCEED THE ACCEPTANCE RATE OF 这种差异贯穿所有基准层，大多数团队发现很难将AI PR的接受率超过60%——这远低于手动PR的观察值。这暗示了在SDLC中使用AI的根本挑战：更快地生成代码并不等同于更高的交付量。审阅者对AI工作持有更高的审查标准（参见下文定性见解）；AI输出仍缺乏手动代码的一致性和信任水平；不明确的归属让许多PR被遗弃。因此，AI PR不仅相对于手动PR表现不佳；它们创造了一个新的基准范围，表明代码更多并不一定导致交付量增加。 这是他们这样说的： 人工智能生成的高级代码，作者无法解释。 上下文常常是错误的或缺失的。 一些AI生成的代码非常大，可能不适用于上下文…… 没有上下文，它产生的工作比初级开发人员还多。审阅者的工作量增加了。 人工智能生产力洞察 15 AI代码在SDLC中 26 [免责声明] 33 AI辅助公关比无辅助的公关大2.6倍。 AI代码在软件开发生命周期中 AI公关有PR获取能力[洞察02]时间比无辅助者多5.3倍。 接受（合并）[洞见03]人工智能公关的费率低于人工公关的一半。 更重的代理AI[洞察04]采用并未转化为更高的价值交付。 [洞察05] 人工智能的使用倾向于新代码，而不是重构。 [洞见 06] AI 代码在软件开发生命周期（SDLC）中 在这一部分，我们将探讨三种类型拉取请求的基准：代理人工智能PR、人工智能辅助PR和无辅助PR（如下定义）。 从人类意图和所有权出发，AI提供建议、代码块或重构，由开发者将其整合到最终变更中。 人工智能辅助的公关与代理流程不同，因为AI不会独立解读任务、提交代码或打开PR。相反，开发者保持对工作流程的控制，利用AI作为辅助工具，而不是自主作者。 [拉取请求类型] 代理型人工智能公关 我们将由AI代理创建的拉取请求定义为代理式AI PR，例如Devin、CopilotCoding Agent、OpenAI Codex等。它们代表了高级代理流程，通常是分配给代理一个任务（直接或通过Jira工单等），执行生成代码、提交并创建拉取请求以合并代码的完整流程。有时这些PR可能代表更小的任务，如修复简单的错误、打字错误等。 不受协助的公关 由开发者完全撰写，未大量使用AI工具进行代码生成、修改或重构的拉取请求。 随着具有代理功能的AI系统在端到端开发流程中承担更多任务（如解释任务、生成代码和打开PR，例如），其对工程工作流程的影响越来越明显。尽管采用率激增，AI已成为大多数开发者的日常工具，但这项技术本身仍处于早期成熟阶段，这在它产生的PR中有所体现。涉及AI参与的PR（包括代理AI PR和AI辅助PR）往往比手动更改更大、范围更广、更不可预测，这对必须解释意图和评估风险的评价者提出了新的要求。 早期的（非AI）机器人公关（PR）例子包括由Dependabot、Renovate和Snyk等创建的依赖关系管理PR，例如，将依赖库的版本升级以修复安全漏洞。 人工智能辅助公关 定义为通过AI辅助开发工具创作或显著塑造的代码变更。这些Pull Requests（PRs）源自 没有人类的语境优势。结果是，广泛使用AI与支持其工作流程之间的不匹配日益加剧：AI帮助开发者更快地编写代码，但审阅者却要承担更多复杂度，而这些工具仍在不断发展。在这个时候，AI既加速了代码产出，又使审阅过程更加复杂，凸显了这项技术的创新程度仍然很高。 人工智能生成的公关文案通常比人工编写的要长得多，这一点本身就已经改变了审阅体验。在75%的标记点上，Agentic AI PRs的代码行数达到293行，而未辅助PRs仅为157行，这意味着审阅者需要处理的文件和系统部分突然多了很多。较大的差异通常涉及到更多文件和系统的更多部分，增加了下游问题的可能性，并创造了更高的代码复杂度。而且因为…… 理解代码的工作量更大，审阅者必须花费额外的时间来弄清楚所有部分是如何组合在一起的，他们才能考虑提出修改建议。此外，AI辅助的PR现在成为三大组中最大的，达到P75的408行，这表明当开发者依赖AI生成或改进代码时，即使开发者保留了作者身份和意图，代码变更的总量仍然快速增长。所有这些加在一起，使得审阅过程从一开始就感觉更加繁重，即使代码本身可能完全有效。 对于非协助提交（7.51），平均每个文件的大小保持相似（65行对66行）。这似乎表明，为开发者创建提交的AI工具在提交边界方面更加“自律”，而人类倾向于将更多工作积累到每个提交中。综合来看，这些平均值显示，代理AI和AI辅助的PR与无辅助PR相比，持续引入更大的代码变更，放大了审查者必须评估的代码量，同时也改变了底层工作的形状和分布。 定性洞察 当我们询问工程领导，“在您的角色中使用AI最大的挑战或担忧是什么？”时，一个引人注目的子集的回答直接指向了AI生成变化的日益增长规模和范围。 这是他们这样说的： 在深入查看PR（Pull Request）和单独的提交记录中，我们发现了一个不同的模式。AI辅助的提交通常更加集中，平均涉及的文件较少（4.2，相比...） 冗长代码生成在分布式生产系统中。 人工智能工具往往会使改动超出请求的范围。 能够完全信赖结果。返回的文字/信息远远超