如果 AI 编写了更多代码，我们是否应该停止为人类设计代码？

Valentina Servile 认为不应该。优秀的软件设计仍然重要，不仅对人，对 AI 代理也是如此。优秀代码的受众扩大了，而不是消失了。

👉 https://t.co/xF8ExkDzW1

我们是否仍应为人类设计代码？

来源：https://www.thoughtworks.com/insights/blog/programming-languages/should-still-design-code-humans

几周前，我参加了在瑞士英格堡举行的“软件工程的未来”活动（https://www.thoughtworks.com/about-us/events/the-future-of-software-development-europe-2026）。正如你对一个发生在 2026 年年中的活动所预期的那样，很多对话都围绕着 AI 工程实践和编码代理展开。

在活动中，我遇到了各种各样的观点。一些人说更愿意把代理牢牢拴住，逐行审查它们的输出，以确保代码可维护、划分良好，以及一切我们通常与优秀软件工艺联系在一起的东西（https://www.thoughtworks.com/insights/blog/agile-engineering-practices/why-ai-raising-stakes-software-engineering-craft）。

另一些人则声称，他们宁愿将软件开发周期的大部分工作委托给代理。从广义上讲，这类人并不特别在意代理实际生成的代码；对他们来说，把时间花在改进指导代理的规范和确定性检查上更好，让代理完全负责代码。（当然，只要构建保持绿色。）

人类再也不需要看代码了吗？

“完全自主”这一端的观点最让我犹豫。它让我想起了一个更大的、我经常在社交圈和媒体推送中看到的观点：

很快，人类就再也不会查看或维护代码了。几年后，优秀的软件设计还会重要吗？

这个论证大致是这样的：随着智能体工作流的发展，最终人类需要产出的只有 markdown 规范、上下文树，或者任何几个月后流行的新交互模式。这份规范可以被扔给一组 AI 代理，它们会生成、测试、审查、部署并随后演进代码。最终，对大多数公司来说，代码可能不过是实现细节；我们甚至可以让代理随时待命，在凌晨 2 点响应生产事故。

某些形式的规范驱动开发（https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html）已经在提倡将规范视为软件开发的新通用语言，而将代码视为短暂的工件。

《敏捷宣言》的第二行（https://agilemanifesto.org/）写着*“可工作的软件胜过详尽的文档”。我们是否应该改写为：“将可工作的软件作为详尽的文档”*？毫无疑问，对于像我这样以编写干净、可读代码为职业自豪感的人来说，这是一个具有挑战性的问题。是的，我承认这里有些利益冲突：毕竟，这是一篇由程序员撰写的文章，解释为什么编程仍然需要。

尽管如此，以下是我个人对这个问题的一些思考，既来自我在活动中的对话，也来自我在代理帮助下维护生产系统的亲身经历。

因此，在本文的剩余部分，我将解释为什么我相信好的设计仍然重要（即使代理完成了大部分修改），为什么人类必须保持在回路中才能生产出设计良好的软件，以及为什么这些人实际上必须在代码层面持续工作才能做到这一点。

但在那之前，我们有必要先理解一种论点：我们实际上只是在处理又一层抽象。在我看来，这并非如此，而真正相信“确实如此”的看法，正是这个问题的关键所在。

就我个人而言，我更愿意与代理一起设计代码，而不是向它抛自然语言规范。这样做可以将“把模糊性解析为一套组织良好的规则”的工作，随着代码的编写而逐步完成。这不仅节省了来回沟通的时间，还让我们能够在与代理协作时，利用代码作为共享且无歧义的优秀设计词汇。