即使AI代码能工作，我也会拒绝

# 即使AI代码能运行，我也会拒绝它 来源：https://vinibrasil.com/when-i-reject-ai-code-even-if-it-works/ 随着实现速度越来越快，真正的瓶颈转移到了审查AI生成的大量代码上。我甚至不是在谈论同事（及其代理）的PR，而是你自己的`git diff`——在你的编码代理完成工作之后。 即使我遵循良好实践——比如从计划模式开始，将大任务分解为多个阶段，并小步快跑地交付变更（https://vinibrasil.com/how-ai-is-changing-my-job-tracer-bullets/）——在审查自己并未真正思考过的东西时，我仍然感到认知过载。 **更好的契合** 在编码代理出现之前，接到任务时，我会探索代码库，思考不同的解决方案，进行实验，然后才着手实现。这可能花费数天时间来整合所有上下文。当最终提交PR时，信心更高，向同事解释每项变更也更容易。 我必须承认，有了AI，完成大任务仍然需要数天。很多时候，我会拒绝AI做出的所有更改，然后重新开始。第一次会话和第二次会话之间的区别不在于LLM模型，而在于屏幕背后的人。有了更多时间来巩固我试图解决的问题（https://vinibrasil.com/on-asking-why/），我能够引导代理走向更好的解决方案，而不是被它所驱动。 **你能信任这个 diff 吗？** **图：你能信任这个 diff 吗？** 越来越多的时候，我因以下原因拒绝AI代码： - 当我无法用自己的话解释这个方案时，我拒绝AI代码。 - 当 diff 比问题本身还大时，我拒绝AI代码。 - 当AI在证明抽象层必要性之前就引入它们时，我拒绝AI代码。 - 当代码能在本地运行但使系统更难以推理时，我拒绝AI代码。 - 当我更相信AI的输出而非自己的理解时，我拒绝AI代码。 看到工程师过快接受AI生成的变更并不罕见，这也是我主张在AI审查之外必须有人工审查的原因。现实是，能运行且通过CI的代码仍然可能是一个糟糕的解决方案，而工程始终是关于实现充分、可扩展且可扩展的解决方案。 我已经使用编码代理一段时间了，尽管它们令人印象深刻，但仍然需要优秀的工程师引导它们走向优秀的解决方案。是的，编码代理可以帮助你完成这个任务，不仅仅是通过编写代码，但这并不意味着它们能够以可持续的方式完全自主完成——*至少目前还不能*。