即使有效也应拒绝AI生成代码

瓶颈已从实施转移到审查

AI编码代理加快了实施速度，但这也创造了一个新的瓶颈：审查大量生成代码的认知负担。当代理完成任务时，生成的 git diff 可能会让人应接不暇，特别是当开发者没有亲自思考架构方法时。

工程不仅仅是让CI变绿或确保代码在本地运行；而是关于实施足够的、可扩展的和可扩展的解决方案。开发者不理解但能运行的代码是一种负债，会增加技术债务。

拒绝有效AI代码的标准

功能是任何代码被合并的最低要求，但这不是质量的充分条件。在以下条件下，即使AI生成的代码通过所有测试，也应予以拒绝：

• 概念清晰度不足： 当开发者无法用自己的话解释该方法时。
• 复杂度不成比例： 当diff大于其意图解决的问题时。
• 过早抽象： 当AI在被证明必要之前就引入抽象时。
• 可推理性降低： 当代码在本地有效但使整体系统更难以推理时。
• 过度依赖输出： 当开发者对AI的输出的信任超过他们对系统自身的理解时。

"Vibe Coding"和技术债务的风险

在“vibe coding”——循环使用LLM直到程序看起来能工作——与严格的软件工程之间存在日益增长的张力。依赖AI将代码库标准化为“企业级模式”可能导致一种统一但浅薄的架构，反映的是平均模式而非领域特定的专业知识。

"杀死你项目的代码是能工作的代码，而且要么被误解，要么不可维护。而行业正在急速迈向此方向，却未能培训出能够修复它的人。"

当开发者更注重关闭工单而非长期维护时，这种风险尤为突出。在缺乏强大人工审查机制的环境中，AI生成的技术债务积累可能会迅速增长。

可持续AI集成的策略

为了在不牺牲系统完整性的情况下利用AI，工程师可以采用几种结构化的工作流程：

首先规划开发

在编写任何代码之前审查设计计划相比审查已完成的PR要高效得多。一项报告的指标表明，计划审查平均耗时0.7小时，而PR审查平均耗时16小时。通过先批准计划，开发者能够保持解决方案的心智模型，使最终的代码审查变为对“范围漂移”的检查，而不是努力理解核心逻辑。

基于关键性的分层信任

并非所有代码都需要相同程度的审查。可以根据代码的影响采用分层信任方法：

• 低关键性： 分析代码、爱好项目或临时功能可以通过端到端AI实现来处理。
• 高关键性： 影响收入或安全关键系统（例如医疗或航空航天软件）的生产代码需要对每一行都有深入的人类理解。

多代理审计

一些开发者使用多个LLM（例如Claude、GPT和Gemini）来互相审查彼此的设计计划和实现。这种对抗性方法可以捕捉单一模型可能遗漏的错误或架构缺陷，尽管它仍然需要一个人来维护整体架构文档，以确保代理拥有正确的上下文。

在AI时代中的人类角色

编码代理是强大的工具，但它们不是自主的工程师。它们需要一个熟练的人类来引导它们走向优秀的解决方案。使用AI时，第一次尝试失败与第二次尝试成功之间的区别通常不在于所使用的模型，而在于开发者对问题的自身整合。最可持续的路径是将AI视为结对编程伙伴——一种“更快的键盘”——而人类则仍然是系统可维护性的主要架构师和守护者。