现在编写代码很便宜

采用 agentic engineering 实践的最大挑战是接受 现在编写代码很便宜 这一事实的后果。

代码一直很昂贵。对于大多数软件开发人员来说，生成几百行干净、经过测试的代码需要一整天或更长时间。我们的工程习惯，无论是在宏观还是微观层面，都是围绕这个核心约束建立的。

在宏观层面，我们花费大量时间设计、估算和规划项目，以确保我们昂贵的编码时间尽可能高效地利用。产品功能想法根据它们可以提供多少价值 来交换那个时间 进行评估——一个功能需要多次赚取其开发成本才值得！

在微观层面，我们每天做出数百个基于可用时间和预期权衡的决策。我应该重构那个函数使其稍微更优雅，如果这增加了一个小时的编码时间吗？编写文档怎么样？值得为这个边缘情况添加测试吗？我可以证明为这个构建调试接口是合理的吗？

编码 agent 极大地降低了将代码输入计算机的成本，这扰乱了我们现有的关于哪些权衡有意义的个人和组织直觉。

运行并行 agent 的能力使得评估更加困难，因为一个人类工程师现在可以同时在多个地方实现、重构、测试和记录代码。

好代码仍然有成本

交付新代码的成本已降至几乎免费… 但交付好代码仍然比这昂贵得多。

这就是我对”好代码”的定义：

代码有效。它做它应该做的事情，没有 bug。
我们 知道代码有效。我们已采取措施向自己和他人确认代码适合用途。
它解决了正确的问题。
它优雅且可预测地处理错误情况：它不仅考虑快乐路径。错误应提供足够的信息，帮助未来的维护者理解出了什么问题。
它简单且最小——它只做需要的事情，以人类和机器现在可以理解并在未来维护的方式。
它受测试保护。测试表明它现在有效，并作为回归套件，避免它在未来悄悄破坏。
它在适当的级别上有文档，并且该文档反映了系统的当前状态——如果代码更改了现有行为，则需要更新现有文档以匹配。
设计支持未来的更改。保持 YAGNI 很重要——为可能永远不会到来的未来更改而添加复杂性的代码通常是坏代码——但同样重要的是不要编写使未来更改比应该更困难的代码。
所有其他相关的”ility”——可访问性、可测试性、可靠性、安全性、可维护性、可观察性、可扩展性、可用性——针对正在开发的特定类别软件的适当非功能质量度量。

编码 agent 工具可以帮助完成大部分工作，但开发人员仍然需要承担重大负担，以确保生成的代码是当前项目所需的好代码。

挑战是发展新的个人和组织习惯，以响应 agentic engineering 的功能和机会。

这些最佳实践仍在整个行业中摸索。我自己也仍在摸索它们。

目前我认为我们能做的最好的事情是质疑自己：任何时候我们的直觉说”不要构建那个，不值得花时间”，无论如何都要发出提示，在异步 agent 会话中，最坏的情况是你十分钟后检查，发现不值得 token。

原文链接: https://simonwillison.net/guides/agentic-engineering-patterns/code-is-cheap/