当我拒绝人工智能代码时，即使它有效

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