我们看到诸多数据与研究表明，随着 AI 编码助手和智能体的普及，人们对 自满于 AI 生成的代码 的担忧也在加剧。尽管有充分证据显示，这类工具可显著加快开发速度——尤其是在原型开发和全新项目场景中——但研究结果也表明，随着时间推移，代码质量可能会出现下降。 GitClear 2024 年的研究发现，重复代码和代码的反复变动比预期增长更多，而提交历史中的重构活动则有所下降。类似趋势也出现在微软研究中：知识型员工因 AI 助手而增强的自信，往往以批判性思维能力下降为代价——我们也注意到，长期使用编码助手后容易出现惰性和过度依赖的现象。 随着编码智能体推动更大范围的自动化变更，这一风险也被放大，因为由 AI 生成的更大代码变更集更加难以评审。正如任何系统一样，流水线中的某一环提速后，其他环节的压力也会随之增加。我们的团队发现，要在生产环境中高效安全地使用 AI，必须重新关注和强化代码质量。我们建议继续落实如 TDD（测试驱动开发）和静态分析等成熟实践，并将这些措施直接集成进开发流程，例如通过为软件团队精选共享指令等方式实现。
随着 AI 编码助手的普及，越来越多的数据和研究也揭示了关于 自满于 AI 生成的代码 所带来的问题。GitClear 最新的代码质量研究显示，到 2024 年，重复代码和代码频繁变更的现象比预测的还要严重，而提交历史中的重构活动却在减少。同样反映出对 AI 的自满，微软的研究显示，AI 驱动的信心往往以牺牲批判性思维为代价——这种模式在长期使用编码助手时表现得尤为明显。随着监督式软件工程代理的兴起，这种风险进一步放大，因为当 AI 生成的变更集越来越大时，开发者在审查这些结果时面临的挑战也随之增加。而 vibe coding 的出现——即开发者在审查极少的情况下让 AI 生成代码——更是说明了人们对 AI 生成输出的信任正在增长。这种方法可能适用于原型或其他一次性代码，但我们强烈建议不要将其用于生产环境的代码。
AI 编程助手，如 GitHub Copilot 和 Tabnine，已经变得非常受欢迎。根据 StackOverflow 2024 年开发者调查 的数据，“72% 的受访者对开发中的 AI 工具持赞成或非常赞成的态度”。尽管我们也看到了这些工具的好处，但我们对它们在中长期对代码质量的影响持谨慎态度，并提醒开发者警惕 自满于 AI 生成的代码 。在经历了几次积极的 AI 辅助体验后，很容易在审查 AI 建议时变得不够谨慎。像 GitClear 的这项研究 显示了代码库快速增长的趋势，我们怀疑这与更大的 Pull Request 有关。还有 GitHub 的这项研究 让我们开始思考，提到的 15% 的 Pull Request 合并率的增加是否真的是好事，还是人们因为过于信任 AI 的结果而更快地合并了更大的请求。我们仍在使用 一年多前提供的基本 “入门建议”，也就是要警惕自动化偏见、沉没成本谬误、锚定偏见和审查疲劳。我们还建议程序员建立一个良好的 在何时何地不使用和信任 AI 心理框架 。
