即便AI代码能运行，我也拒绝它的理由
作者认为，尽管AI生成代码的速度很快，但当开发者无法用自己的话解释其思路、代码改动比问题本身还大、引入了不必要的抽象、或者让系统变得更难理解时，就应该拒绝这些代码。瓶颈已经从实现转移到了代码审查，人类判断对于可持续的工程实践仍然至关重要。
随着实现速度越来越快，真正的瓶颈已经转移到了审查AI生成的代码量上。我不仅指的是同事（及其智能体）的拉取请求，也包括自己使用编码助手后产生的差异。即使遵循良好的实践——比如从计划模式开始，将大任务分解成多个阶段，交付小改动——在审查自己并未深入思考的代码时，我仍然会感到认知过载。
在编码助手出现之前，当我接到一个任务时，我会先探索代码库，思考不同的解决方案，进行实验，然后才实现。这个过程可能需要花费数天时间来整合所有上下文。当我最终提交拉取请求时，信心更高，向同事解释每个改动也更加容易。
我必须承认，即使有AI的帮助，完成大任务仍然需要数天时间。很多时候，我会拒绝AI做出的所有改动并重新开始。第一次会话和第二次会话之间的区别不在于LLM模型，而在于屏幕后面的人。有了更多时间来整合我试图解决的问题，我可以引导智能体走向更好的解决方案，而不是被它牵着走。
我越来越多地因为以下原因拒绝AI代码：当我无法用自己的话解释这个方案时；当改动量比问题本身还大时；当它在证明需要之前就引入了抽象时；当它在本地能运行但让系统更难理解时；以及当我更信任输出而不是自己的理解时。
工程师们过快接受AI生成的改动并不罕见，这正是我主张在AI审查之外还必须有人工审查的原因。现实是，能运行并通过CI的代码仍然可能是糟糕的解决方案，而工程一直关乎实现适当、可扩展且可维护的方案。
我已经使用编码助手一段时间了，尽管它们令人印象深刻，但仍然需要优秀的工程师引导它们走向优秀的解决方案。是的，编码助手可以通过不止写代码的方式来帮助完成这项任务，但这并不意味着它们已经能够以可持续的方式自主完成。