人工智能应该帮助我们编写更好的代码

许多开发人员担心，将代码外包给 AI 工具会导致质量下降，产生快速但糟糕的代码，以至于决策者们愿意忽略其缺陷。

如果采用代码代理明显降低了您生产的代码和功能的品质，您应该直接解决这个问题：找出过程中哪些方面损害了输出质量，并加以修复。

使用代理交付较差的代码是一种选择。我们可以选择交付更好的代码。

避免技术债务

我喜欢从技术债务的角度思考交付更好代码的问题。我们之所以会产生技术债务，是因为做事情“正确的方式”需要太长时间，所以我们在时间压力下工作，并祈祷项目能够存活足够长的时间，以便以后还清债务。

减轻技术债务的最佳方法是避免一开始就产生债务。

在我看来，常见的技术债务修复类别是那些简单但耗时的更改。

我们最初的 API 设计没有涵盖后来出现的重要情况。修复该 API 需要更改数十个不同地方的代码，因此更快的方法是添加一个新的、略有不同的 API，并忍受重复。
我们早期对概念的命名很差劲 - 例如“teams”而不是“groups” - 但在代码中清理这种命名需要太多工作，所以我们只在 UI 中修复它。
我们的系统随着时间的推移积累了重复但略有不同的功能，需要合并和重构。
我们的某个文件已经增长到几千行代码，我们理想情况下会将其分成单独的模块。

所有这些更改在概念上都很简单，但仍需要专门的时间，这可能很难证明其合理性，尤其是考虑到更紧迫的问题。

像这样的重构任务是代码代理的理想应用。

启动一个代理，告诉它要更改的内容，然后让它在后台的某个分支或工作树中自行处理。

我通常使用异步代码代理，如 Gemini Jules、OpenAI Codex 网页版或 Claude Code 网页版。这样，我可以在笔记本电脑上运行这些重构作业而不会中断我的工作流程。

在拉取请求中评估结果。如果结果良好，就采纳它。如果结果接近目标，就提示它并告诉它如何做得不同。如果结果很差，就放弃它。

这些代码改进的成本已经降低到我们可以对轻微的代码异味和不便采取零容忍态度的地步。

任何软件开发任务都伴随着许多解决问题的方法。一些最显著的技术债务来自于在规划阶段做出的糟糕选择 - 错过了一个明显的简单解决方案，或者选择了一种后来证明并不完全合适的技术。

大型语言模型（LLM）可以帮助我们确保不会错过任何以前可能没有引起我们注意的明显解决方案。它们只会建议在训练数据中常见的解决方案，但这些方案往往是最有可能奏效的枯燥技术。

更重要的是，代码代理可以帮助探索性原型设计。

做出自信的技术选择最好的方法是证明它们通过原型设计是适合的。

Redis 是否适合于期望数千个并发用户的网站的活动推送？

最好的确认方法是建立该系统的模拟并运行负载测试以查看哪些地方会出错。

代码代理可以根据精心设计的提示构建这种模拟，从而使这种实验的成本几乎降为零。而且由于它们非常便宜，我们可以同时运行多个实验，测试几种解决方案以选择最适合我们问题的方案。

代理遵循指令。我们可以随着时间的推移改进这些指令，以便从未来的运行中获得更好的结果，基于我们之前学到的知识。

Dan Shipper 和 Kieran Klaassen 在 Every 描述了他们公司与代码代理合作的方法，称为复合工程。他们完成的每个编码项目都以回顾结束，称为复合步骤，他们将有效的方法记录下来以供未来的代理运行使用。

如果我们想要从代理中获得最佳结果，我们应该旨在不断提高代码库的质量。随着时间的推移，小幅度的改进会产生巨大的影响。曾经耗时耗力的质量提升现在已经降低到我们可以同时投资于质量和新功能的地步。代码代理意味着我们可以同时拥有两者。