本文翻译自 Vibe coding and agentic engineering are getting closer than I’d like，原载于 Hacker News。

Simon Willison 最近参加了 Heavybit 的 High Leverage 播客（第 9 期：The AI Coding Paradigm Shift），和 Joseph Ruscio 聊了聊 AI 编码工具。播客的好处在于，它常常推动你在对谈中梳理出从未清晰表达过的想法。而这次，Simon 说出了一个让自己都感到不安的发现。

曾经泾渭分明的两条路

在 vibe coding 这个概念被提出几周后，Simon 就写过一篇文章——《并非所有 AI 辅助编程都是 vibe coding》，明确区分了两种模式：

Vibe coding（感觉编码）：你根本不看代码，甚至可能不会编程。你向 AI 描述需求，得到结果，能用就行，不能用就让 AI 再改改。代码质量？安全？可维护性？统统不在考虑范围内。Simon 认为这种模式用在个人工具上完全没问题——出了 bug 只影响你自己。但如果是面向其他用户的软件，vibe coding 就是极其不负责任的。

Agentic engineering（智能体工程）：你是专业软件工程师，理解安全、可维护性、运维、性能。你把 AI 工具当作放大器，在自身专业能力的基础上用它们做到更高的水准。目标是构建更高质量的生产系统，而不是更快地产出低质量的东西。

这两者之间的界限曾经非常清晰。但现在，这条线开始模糊了。

当 AI 代理变得过于可靠

Simon 坦言，随着编码代理（coding agent）越来越可靠，他自己在生产级项目中也不再逐行审查 AI 生成的代码了：

我非常清楚，如果你让 Claude Code 构建一个 JSON API 端点——执行 SQL 查询、返回 JSON 结果——它就是能做对。不会出问题。你让它加上自动化测试，加上文档，你知道最终结果会是好的。

但我没有审查那段代码。于是我开始感到内疚：如果我没有审查代码，把它用在生产环境中真的负责任吗？

他找到了一个让自己安心的类比——把 AI 代理当作另一个团队。在大公司工作时，如果另一个团队交给你一个图片压缩服务，你不会去逐行阅读他们的代码。你会看文档，试用一下，然后就开始构建自己的功能。只有在遇到 bug 或性能问题时，你才会去翻他们的 Git 仓库。

不过 Simon 也承认这种类比并不完美。人类团队有职业声誉约束——他们不会随便交付垃圾，因为这会影响自己的信誉。而 Claude Code 没有职业声誉，不能为自己的行为负责。尽管如此，它一次又一次地证明了自己——用 Simon 喜欢的风格，稳定地产出正确的代码。

这其中有「偏差常态化」的风险：每一次 AI 在你没有密切监督的情况下写出了正确的代码，你信任它的程度就增加一分，直到某一天在关键时刻被狠狠打脸。

软件评估的新挑战

这段讨论中最让我印象深刻的观点是关于如何评估软件质量：

过去，如果你发现一个 GitHub 仓库有上百次提交、漂亮的 README、完善的自动化测试，你可以相当确定作者在这个项目上倾注了大量的心血和注意力。

而现在，我可以在半小时内搞出一个有一百次提交、精美 README、覆盖每行代码的全面测试的 Git 仓库！它看起来跟那些倾注了大量心血的项目一模一样。也许它确实一样好。我不知道。光看外表我分辨不出来。甚至对我自己的项目，我也分辨不出来。

Simon 由此得出一个重要结论：比起测试和文档的质量，我更看重的是有没有人真正在「用」这个东西。 一个用 vibe coding 搞出来但每天实际使用了两周的工具，远比一个刚生成出来、几乎没实际运行过的项目有价值。

这个观点对开发者选择开源项目和依赖库同样有指导意义——看 star 数和测试覆盖率不如看 issue 活跃度和实际使用情况。

瓶颈已经转移

Simon 指出，当你的代码产出从每天 200 行飙升到 2000 行，整个软件开发流程中还有什么会断裂？整个软件开发生命周期（SDLC）的设计前提是「产出几百行代码需要一天时间」。现在不是了。

不仅是下游环节，上游设计也受到了冲击。他引用了 Anthropic 设计负责人 Jenny Wen 的观点：我们现有的设计流程都建立在一个前提上——设计必须做对，因为一旦交给工程师花三个月构建了错误的东西，代价是灾难性的。但如果构建成本大幅降低呢？设计流程也许可以承担更多风险，因为试错的成本已经降到了可以接受的程度。

这一点对国内开发者的启示尤为深刻。我们常说「敏捷开发」，但真正的敏捷不仅仅是迭代快，而是在构建成本足够低的时候，可以更频繁地验证方向、更快地转向。

为什么不用担心职业前景

在被问及 AI 是否会取代程序员时，Simon 的回答非常精彩：

当我审视自己和 AI 代理的对话记录，我很清楚这对绝大多数人类来说就像「天书」一样。

他认为这些工具是现有经验的放大器。如果你知道自己在做什么，有了它们你可以跑得更快。软件开发仍然是一件极其困难的事情——就算给你世界上所有的 AI 工具，我们要实现的目标依然非常困难。

他引用了政治评论员 Matthew Yglesias 的一条推文，大意是：「五个月过去了，我觉得我不想 vibe coding——我想要专业管理的软件公司用 AI 编码辅助来生产更多、更好、更便宜的软件产品，然后卖给我。」Simon 对此深表认同，并补了一个绝佳的类比：我看了足够的 YouTube 水管工视频也能自己装修水管，但我宁愿雇一个专业水管工。

关于 SaaS 会不会被企业自己用 AI 搞的方案取代，Simon 同样用前面的逻辑回应：我只用你经过几周实际使用的个人项目。企业版就是——除非至少有两家其他大型企业成功使用了这个 CRM 六个月以上，否则我不会冒险采用。你需要的是经过验证的解决方案。

几点个人思考

作为每天都在使用 AI 编码工具的开发者，Simon 的这段分享让我深有共鸣：

1. 代码审查的方式正在改变。我们不再需要逐行审查每一行 AI 生成的代码，而是需要建立更高层次的审查机制——关注架构决策、安全边界、数据流，而非每一个函数实现。

2. 「用过」比「写得好」更重要。在 AI 时代，软件的价值不再取决于代码的「工整程度」（因为 AI 生成的代码天然就很工整），而取决于它是否经过了真实场景的锤炼。这对我们评估开源项目和选择技术方案都是一个重要的思维转变。

3. 设计可以更大胆。当构建成本急剧下降，我们在技术方案和产品设计上可以承担更多风险、进行更多尝试。这不是降低标准，而是在同样的时间和资源约束下探索更多可能性。

4. 专业知识依然是核心竞争力。AI 工具放大的是你已有的能力。一个不了解安全、性能、可维护性的开发者，用 AI 只能更快地产出糟糕的代码。而一个经验丰富的工程师，用 AI 可以把 25 年的经验放大到前所未有的效率。