Vibe coding 和 agentic engineering 比我希望的更接近了
Vibe coding and agentic engineering are getting closer than I'd like
Simon Willison 在 Heavybit High Leverage podcast 第 9 集与 Joseph Ruscio 讨论 AI coding tools，称 vibe coding 与 agentic engineering 在其工作中开始重叠；coding agents 提高产出并减少逐行审查，但带来责任、评估与软件开发流程瓶颈变化，项目可信度更依赖实际使用记录。
我最近和 Joseph Ruscio 在 Heavybit 的 High Leverage podcast 上聊了 AI coding tools：第 9 集，The AI Coding Paradigm Shift with Simon Willison。下面是我摘出的一些重点，包括一个让我不安的认识：在我自己的工作中，vibe coding 和 agentic engineering 已经开始汇合了。
我很喜欢 podcast 的一点是，它们有时会推动我把想法说出来，从而暴露出一个此前我还无法用语言表达清楚的观点。
Vibe coding 和 agentic engineering 开始重叠
vibe coding 这个说法首次被提出几周后，我发表了 Not all AI-assisted programming is vibe coding (but vibe coding rocks)，在文中我明确表达了自己的看法：“vibe coding”和负责任地使用 AI 编写代码是非常不同的东西；后者我后来开始称为 agentic engineering。
当 Joseph 提到两者之间的区别时，我突然意识到，对我来说，它们已经不像过去那样泾渭分明了：
奇怪的是，这些东西对我来说已经开始变得模糊，而这让我相当不安。
我原以为我们有一条非常清楚的分界线：vibe coding 指的是你完全不看代码的那种做法。你甚至可能根本不会编程。你可能是一个非程序员，只是提出想要某个东西，然后得到一个东西；如果它能用，那很好！如果不能用，你就告诉它不能用，然后祈祷。但在任何时候，你都并不真正关心代码质量，或其他那些额外约束。
我对 vibe coding 的看法是：只要你理解它什么时候可以用、什么时候不能用，它就很棒。给你自己做一个个人工具，如果有 bug 也只会伤到你自己，那就去做！但如果你是在为其他人构建软件，vibe coding 就非常不负责任，因为那涉及别人的信息。别人会被你的愚蠢 bug 伤害。你需要达到比这更高的标准。
这和 agentic engineering 形成对比：在 agentic engineering 中，你是一名专业软件工程师。你理解安全性、可维护性、运维、性能等等。你是在用这些工具发挥你自身能力的上限。
我发现自己能够处理的问题范围显著扩大了，因为我得到了这些工具的支持。但我仍然依靠自己 25 年的软件工程经验。目标是构建高质量的生产系统：如果你只是更快地构建低质量的东西，我认为那是坏事。我想更快地构建更高质量的东西。我希望我构建的一切，在各个方面都比以前更好。
问题在于，随着 coding agents 变得更可靠，我已经不再逐行审查它们写出的每一行代码了，即使是我的生产级代码也是如此。我很清楚，如果你让 Claude Code 构建一个 JSON API endpoint，执行一条 SQL query，并把结果作为 JSON 输出，它就是会正确完成。它不会把这件事搞砸。你让它添加 automated tests，让它添加 documentation，你知道它会做得很好。
但我没有审查那段代码。于是我现在有了一种负罪感：如果我没有审查代码，那么我把它用于生产环境，真的算负责任吗？
真正帮助我思考这件事的是回想我在更大组织中担任 engineering manager 的经历。其他团队会构建我的团队所依赖的软件。如果另一个团队交付了某个东西，并说：“嘿，这是 image resize service，这是用它调整图片大小的方法”……我不会去阅读他们写的每一行代码。我会看他们的 documentation，然后用它来调整一些图片大小。然后我会开始发布自己的功能。
如果我开始遇到问题，比如这个 image resizer 看起来有 bug，或者性能不好，那时我可能会去翻他们的 Git repositories，看看发生了什么。但在大多数情况下，我会把它当作一个半黑盒来对待，直到我需要的时候才会去看里面。
我开始以同样的方式对待 agents。
这仍然让我感到不舒服，因为人类要对自己的行为负责。一个团队可以建立声誉。我可以说：“我信任那边那个团队。他们过去构建过很好的软件。他们不会构建垃圾，因为那会影响他们的职业声誉。”
Claude Code 没有职业声誉！它无法为自己做过的事情承担责任。
但它仍然在证明自己——一次又一次，它产出那些直接明了的东西，并以我喜欢的风格正确完成。
这里有一种“偏差正常化”的成分：每当一个模型在我没有密切监控的情况下写出了正确代码，都会增加一种风险——未来某个错误的时刻，我可能会信任它，然后被反噬。
评估软件的新挑战
过去，如果你在 GitHub 上发现一个 repository，有一百个 commits、不错的 readme、automated tests 等等，你可以相当确定，写它的人在这个项目上投入了大量关心和注意力。
而现在，我可以在半小时内做出一个 git repository，里面有一百个 commits、漂亮的 readme，以及覆盖每一行代码的完整 tests！它看起来和那些确实投入了大量关心和注意力的项目一模一样。
也许它和那些项目一样好。我不知道。我光看它无法判断。即使是我自己的项目，我也无法判断。
所以我意识到，相比 tests 和 documentation 的质量，我更看重的是：我希望有人实际用过这个东西。如果你有一个 vibe coded 的东西，并且在过去两周每天都用它，那么对我来说，这比你刚刚吐出来、几乎还没真正跑过的东西有价值得多。
瓶颈已经转移
如果你能从每天产出 200 行代码变成每天产出 2,000 行代码，那么还有什么会出问题？
事实证明，整个软件开发生命周期都是围绕这样一个观念设计的：产出几百行代码需要一天时间。而现在不是这样了。
不仅是下游环节，上游环节也是如此。
我看过 Jenny Wen 的一场很好的演讲，她是 Anthropic 的 design leader。她说，我们有所有这些 design processes，它们都建立在这样一个前提之上：你必须把设计做对——因为如果你把设计交给 engineers，而他们花三个月构建了错误的东西，那将是灾难性的。
正因为那个设计会导致昂贵的工作，所以你会建立一整套非常完整的 design process。但如果构建它不再需要三个月，也许 design process 可以承担大得多的风险，因为一旦你做错了什么，其成本已经大幅降低。
为什么我仍然不担心自己的职业
当我看自己和 agents 的对话时，我非常清楚，对绝大多数人类来说，这就是天书。
我并不害怕自己的软件工程师职业会因为计算机现在能自己写代码而结束，原因有很多，其中一部分原因是，这些东西会放大已有经验。如果你知道自己在做什么，就可以借助它们跑得快得多。
[...]
在使用这些工具工作时，我不断被提醒：我们所做的事情有多难。生产软件是一件极其困难的事情。即使你把世界上所有 AI tools 都给我，我们在这里试图实现的目标仍然非常困难。
[...]
政治评论员 Matthew Yglesias 昨天 tweeted：“五个月过去了，我想我已经决定，我不想 vibecode——我想让专业管理的软件公司使用 AI coding assistance，做出更多、更好、更便宜的软件产品，然后卖给我。”
我觉得这说得很对。只要我看足够多关于 plumbing 的 YouTube videos，我也可以给自己家装水管。但我宁愿雇一个 plumber。
关于 SaaS providers 面临的威胁，即公司可能转而自己构建解决方案：
我刚意识到，这就是我前面说过的那件事：只有当你已经用了自己的 side project 几周之后，我才愿意使用它。这个观点的企业版是：除非至少有另外两家大型企业已经成功使用某个 CRM 六个月，否则我不想要这个 CRM。
[...]
在你冒险采用某个解决方案之前，你希望它已经被证明是有效的。
Tags: ai, generative-ai, llms, podcast-appearances, vibe-coding, coding-agents, agentic-engineering