开发者曾竞相采用旨在将产出翻倍的工具，许多人确实成功了。然而，他们如今交付的代码往往隐藏着隐性成本，这些成本会在数月后以代码审查积压、生产事故和不断累积的技术债务形式显现出来。
本月发布的BairesDev对705名开发者的调查显示，42%的开发者现在允许人工智能编写至少一半的代码，而一年前这一比例仅为12%。报告指出，67%的开发者花在审查AI生成输出上的时间比过去更多，52%的开发者表示修复模型引入问题所花费的调试时间有所增加。
生产力提升确实实现了，但节省下来的打字时间并未转化为自由产能，而是消失在了检查、修正和解释之中。这种模式在企业中反复出现。
技术债务与安全漏洞凸显
研究人员分析了超过6,00个公共仓库和30万个留有AI编程助手痕迹的提交记录，识别出484,366个独特问题。其中，代码异味（Code smells）占89.3%。来自每个主要AI助手的提交中，有超过15%引入了至少一个问题。更糟糕的是，22.7%的这些由AI引入的问题在仓库的最新版本中仍然存在。这篇题为《AI热潮背后的债务》的论文于4月在arXiv上发表，清晰地描绘了长期维护负担的画面。
但并非所有研究都讲述同一个故事。一项针对五个自主代理的37,623个带有来源标签的拉取请求的分析发现了混合结果。某些代理生成的代码被回退的频率低于人类贡献，而其他代理则触发了更多的回退。总体而言，代理代码中的安全异味出现频率较低。差异证明是特定于供应商的，而非统一的。9月的arXiv预印本强调了审查工作如何集中且分布不均，某些工具吸引了更多的人类审视。
早期的警告指出，如果AI编程似乎降低了代码质量，那么组织并没有以足够的严谨性管理质量。该文章提出了实用的控制措施——更严格的审查关卡、自动异味检测器、架构监督——许多团队目前仍缺乏这些措施。它仍然是最早呼吁将AI输出视为草稿材料而非成品的清晰呼声之一。
重复代码讲述了另一个故事。GitClear对数亿行变更代码的分析发现，自AI工具主流化以来，重复代码块增加了81%。重构活动，即健康代码演变的标志，急剧下降。移动代码从2022年变更代码行的21%降至今年的3.8%。团队粘贴得更多，重构得更少。媒体报道检视了这些指标，质疑行业是否已悄然回归到“编码与修复”的心态。
安全漏洞以顽固的速度出现。Veracode在其2026年夏季报告中对其测试的11个前沿模型进行了80项编码任务，平均安全通过率仅为56%，近一半的任务产生了已知漏洞。自该公司2025年首次研究以来，这些比率几乎没有改善。CodeRabbit在审查真实的GitHub拉取请求时发现，AI共同参与的变更中的问题数量是人类单独参与的1.7倍，可读性问题高出三倍以上。多项研究汇总汇编了这些数据以及来自多个来源的类似数据。
大厂的现实与困境
公司公开谈论这种转变。Google告诉投资者和员工，AI现在生成了其75%的新代码，高于去年秋天的50%。Airbnb在第一季度报告了这一比例为60%。微软和其他公司引用了相当的数字。然而，内部工程讨论揭示了不同的现实：审查队列增长，高级工程师抱怨他们整天都在阅读机器生成的样板代码。初级开发者若过于轻易接受建议，可能会错过基础性的课程。
Techreviewer.co的一项研究发现，89%的软件公司现在使用AI进行代码生成，AI对代码库的中位数贡献率在26%到50%之间。97%的团队显示出生产力提升。与此同时，90%的团队报告了重大缺点：幻觉、增加的审查负担、安全漏洞以及早期职业工程师的技能退化。调查显示，52.8%的受访者将幻觉建议列为首要挫折，另有33.1%的人遇到过由AI代码引入的漏洞。
最近的学术工作加强了这一担忧。Yuecai Zhu、Nikolaos Tsantalis和Peter C. Rigby在9月发表的一篇论文考察了LLM和代理驱动的软件开发。能力更强的模型生成了更大、耦合更紧密的代码。代码量成为结构衰败的完美预测因子。无论是功能正确性还是详细的提示都无法阻止这一趋势。作者描述了一种随规模恶化而加剧的推理复杂性权衡。
开发者感受到了压力。Stack Overflow对超过49,000名受访者的2025年调查发现，80%的人使用AI工具，但只有29%信任其准确性，低于前几年的40%。66%的人表示他们花更多时间修复那些“几乎正确”的代码。在新调查中，情绪持续下滑。
应对策略与未来选择
一些组织通过新流程来应对。Synthesia在其工程师积极采用Claude Code后，看到拉取请求同比激增120%，其中95%的请求包含AI生成的内容。该公司加倍投入人力审查，而不是减少监督。其他公司则尝试使用Anthropic、Qodo和新兴初创公司提供的专用AI审查员，承诺在合并前捕获逻辑错误。
然而，仅靠工具无法解决更深层次的问题。AI擅长生成通过表面测试且看起来一致的代码，但在架构连贯性、长期可维护性以及大型系统间的微妙交互方面表现挣扎。结果往往是从业者现在所谓的“垃圾代码”（slop）——功能可用但脆弱、冗长且难以更改。
将AI视为判断力不均的结对程序员并加以管理的团队表现更好。他们设定明确的质量阈值，运行针对捕捉机器特定模式优化的静态分析，并要求关键路径需经资深人员签字批准。他们不仅追踪速度，还追踪耐久性指标：代码在不重写情况下存活六个月的频率。
数据显示出明显的分歧。某些代理降低回退率，而其他代理则增加它们。某些代码库以适度的降级吸收AI贡献，而其他代码库则以惊人的速度积累异味。上下文、审查纪律和工程文化对结果的影响大于所选模型。
生产力数字乍一看令人眼花缭乱。产出上升，功能发布更快。但长期的账目包括更高的维护成本、新员工入职速度变慢以及剩余审查者认知负荷的增加。BairesDev的调查直接捕捉到了这种张力：58%的开发者感到对他们未完全编写的代码负有更大的个人责任，59%的人表示发现细微的bug比过去需要更多的脑力努力。
行业领导者现在面临选择。他们可以追逐每位工程师产生的原始代码行数，或者构建在每个阶段衡量和保护质量的系统。前者带来令人印象深刻的季度指标和最终的后悔，后者需要对流程、工具和人才发展进行投资，而许多组织已推迟了这些投入。
AI编程助手会不断改进，新的代理将处理更大的范围。然而，根本的非对称性依然存在。机器能快速生成选项，但人类仍必须决定哪些选项值得在生产环境中保留。这一步骤的判断成本变得更高，而非更低。
早期忽视质量关卡的采用者付出了惨痛代价。他们的继任者看着同样的模式在整个行业中以更大的规模重现。代码不断涌入，问题是工程组织能否及时赶上以管理它。