随着实现速度越来越快，真正的瓶颈转移到了审查 AI 生成的代码量。我不仅仅在讨论你的同事（及其代理）的 PR，而是在谈论当你的编程代理完成工作后，你自己的 git diff。即使我遵循良好的实践——例如，从计划模式开始，将大任务分成几个阶段，以及推出小变更——在审查一些我自己没有认真思考过的内容时，我仍然感到认知超负荷。在有编程代理之前，当接到任务时，我会探索代码库，思考不同的解决方案，进行实验，最后才实施。这可能需要几天的时间来整合所有的上下文。当我最终提交那个 PR 时，自信心更高，向我的同事解释每一个更改也更容易。我不得不承认，对于 AI 来说，完成大任务仍然需要我几天的时间。往往，我会拒绝所有 AI 的更改并重新开始。第一次会话和第二次会话之间的区别不是 LLM 模型，而是屏幕背后的人。花更多时间来巩固我想解决的问题，我可以引导代理找到更好的解决方案，而不是被它驱动。你能相信差异吗？越来越多的情况下，我出于同样的原因拒绝 AI 代码：当我不能用自己的话解释方法时，我拒绝 AI 代码；当差异比问题更大时，我拒绝 AI 代码；当它引入抽象而没有证明这些是必要的时，我拒绝 AI 代码；当它在本地有效但使系统难以推理时，我拒绝 AI 代码；当我更信任输出而非我的理解时，我拒绝 AI 代码。看到工程师过于迅速地接受 AI 生成的更改并不罕见，这就是为什么我主张在 AI 审查的同时必需有人类审查。现实是，运行并使 CI 成为绿色的代码仍然可能是一个糟糕的解决方案，工程一直以来都在于实现足够、可扩展和可扩展的解决方案。我已经使用编程代理有一段时间了，尽管它们令人印象深刻，但它们仍然需要出色的工程师来引导它们找到优秀的解决方案。是的，编程代理可以帮助你完成这项任务，不仅仅是编写代码，但这并不意味着它们可以在可持续的方式下自主完成这项工作。