Vibe coding and agentic engineering are getting closer than I’d like

资讯摘要

Vibe coding and agentic engineering are getting closer than I’d like 6th May 2026 I recently talked with Joseph Ruscio about AI coding tools for Heavybit’s High Leverage podcast: Ep. #9, The AI Coding Paradigm Shift with Simon Willison . Here are some of my highlights, including my disturbing realization that vibe coding and agentic engineering have started to converge in my own work. One thing I really enjoy about podcasts is that they sometimes push me to think out loud in a way that exposes an idea I’ve not previously been able to put into words.

资讯正文

Vibe coding 和 agentic engineering 正在变得比我希望的更接近。

我最近与 Joseph Ruscio 就 AI 编码工具接受了 Heavybit 的播客 High Leverage 的采访：第 9 集，Simon Willison 谈 AI 编码范式转变。以下是我的一些重点，包括我令人不安的顿悟：vibe coding 和 agentic engineering 已经开始在我自己的工作中趋于融合。

播客最让我喜欢的一点是，它们有时会推动我一边思考一边说出来，从而暴露出一个我之前还没法用语言准确表达的想法。

在 vibe coding 这个词刚被提出后的几周，我发表了《并非所有 AI 辅助编程都是 vibe coding（但 vibe coding 很棒）》一文，在文中我明确表明了自己的看法：vibe coding 是一种与负责任地使用 AI 编写代码截然不同的东西；此后我开始把后者称为 agentic engineering。

当 Joseph 提起这两者之间的区别时，我突然意识到，对我来说，它们已经不像过去那样截然不同了：

不过奇怪的是，这些东西在我这里已经开始变得模糊了，这让我相当不安。我原本以为界限非常清楚：vibe coding 指的是你根本不看代码的那种做法。你甚至可能都不会编程。你可能只是一个非程序员，提出一个需求，然后得到一个结果；如果它能用，那就太好了！如果它不能用，你就告诉它不能用，然后祈祷一下。但在任何时候，你其实都不会真正关心代码质量，或者那些额外的约束。

而我对 vibe coding 的看法一直是：只要你明白它什么时候能用、什么时候不能用，它就是很棒的。它适合作为你个人的工具——如果出了 bug 也只会伤到你自己，那就放手去用吧！如果你是在为别人开发软件，vibe coding 就是极其不负责任的，因为那是别人的信息。别人会因为你愚蠢的 bug 受害。你需要把标准提高到那个水平以上。这与 agentic engineering 形成对比：在那种模式下，你是一名专业的软件工程师。你理解安全性、可维护性、运维、性能等等。你在用这些工具把自己的能力发挥到最高。我发现，由于有了这些工具的支持，我能接手的挑战范围大幅扩大了很多。但我仍然依靠自己 25 年的软件工程经验。目标是构建高质量的生产系统：如果你是在更快地构建低质量东西，我认为那是坏事。我想更快地构建更高质量的东西。我希望我构建的一切，在各个方面都比以前更好。

问题在于，随着编码 agent 变得越来越可靠，我不再会逐行审查它们写出的每一行代码了，即便是我用于生产环境的东西也一样。我很清楚，如果你让 Claude Code 去构建一个 JSON API 端点，执行一条 SQL 查询并把结果输出为 JSON，它就是会把这件事做好。它不会搞砸。你让它加自动化测试，再让它补文档，你知道它会做得很好。但我并没有审查那段代码。于是我现在产生了那种愧疚感：如果我没有审查代码，那么我真的有责任把它用在生产环境里吗？

真正帮到我的，是回想自己在更大的组织里担任工程经理的时候。其他团队会构建我所在团队所依赖的软件。如果另一个团队交付了某个东西，并说：“嘿，这是图片缩放服务，下面是如何用它来缩放你的图片……”我不会去逐行阅读他们写的每一行代码。我会看他们的文档，然后用它来缩放一些图片。接着我就会开始发布我自己的功能。如果我开始遇到问题，发现图片缩放器似乎有 bug，或者性能不太好，那时我才可能深入他们的 Git 仓库看看究竟发生了什么。但在大多数情况下，我会把它当作一个半黑箱，在我需要之前并不会去看它。我开始以同样的方式对待这些 agents。只是这仍然让我感到不舒服，因为人类要对自己所做的事情负责。

一个团队是可以建立声誉的。我可以说：“我信任那边那个团队。他们以前做过很好的软件。他们不会做出糟糕的东西，因为那会影响他们的职业声誉。”Claude Code 没有职业声誉！它不能为自己做过的事承担责任。但它一直在证明自己——一次又一次，它把那些直接明了的东西做出来，而且还以我喜欢的那种风格把事情做好。

不过奇怪的是，这些界限对我来说已经开始变得模糊了，这让我相当不安。

我原以为我们之间有非常清晰的区分：vibe coding 指的是你完全不看代码。你甚至可能都不会编程。你可能只是个非程序员，提出一个需求，拿到一个结果，如果结果能用，那就很好！如果不能用，你就告诉它不能用，然后祈祷一切顺利。

但在这个过程中，你其实从来都不会真正关心代码质量，或者那些额外的约束。我的看法一直是，vibe coding 很棒，前提是你知道它什么时候能用、什么时候不能用。

如果是给你自己用的个人工具，出了 bug 也只会伤害你自己，那就去做吧！

如果你是在给别人开发软件，vibe coding 就是极其不负责任，因为那是别人的信息。别人的利益会因为你那些愚蠢的 bug 而受损。你需要比那更高的标准。

这与 agentic engineering 形成对比：在这种模式下，你是一名专业软件工程师。你理解安全性、可维护性、运维、性能等等。你在以自己最高的能力使用这些工具。由于有这些工具的支持，我发现自己能够承担的挑战范围大幅增加了。

但我仍然是在依靠自己 25 年的软件工程经验。

目标是构建高质量的生产系统：如果你是为了更快地做出低质量的东西，我认为那是坏事。我想要的是更快地做出更高质量的东西。我希望我构建的一切，在各个方面都比以前更好。

问题在于，随着编码代理变得越来越可靠，我不再逐行审查它们写出的每一行代码了，哪怕是我生产级别的工作也是如此。

我很清楚，如果你让 Claude Code 构建一个 JSON API 端点，去执行一条 SQL 查询并把结果以 JSON 输出出来，它就是会正确地完成。它不会把这事搞砸。你让它补上自动化测试，让它加上文档，你知道它会做得很好。

但我并没有审查那段代码。于是我现在产生了那种内疚感：如果我没有审查代码，那么把它用于生产环境，对我来说真的算负责吗？

真正让我有所缓解的是，回想起我曾在较大的组织里担任工程经理的时候。其他团队会在开发我们团队所依赖的软件。

如果另一个团队交过来一个东西，说：“嘿，这是图像缩放服务，下面是如何使用它来缩放你的图片”……我不会去逐行阅读他们写的每一行代码。

我要去看它们的文档，用它来调整一些图片大小。然后我会开始交付我自己的功能。如果我开始遇到问题，比如图片调整工具似乎有 bug，或者性能不太好，那时我可能才会去翻它们的 Git 仓库，看看究竟怎么回事。但在大多数情况下，我把它当作一个半黑箱，除非我需要，否则不会去看。

我开始用同样的方式对待这些代理了。可这仍然让人不太舒服，因为人类要对自己的行为负责。一个团队可以建立声誉。我可以说：“我信任那边那个团队。他们过去做过很好的软件。他们不会做出糟糕的东西，因为那会影响他们的职业声誉。”

Claude Code 并没有职业声誉！它也无法为自己所做的事承担责任。但它一直在证明自己——一次又一次，它都能产出简单直接的东西，并且按我喜欢的风格把事情做对。

这里面有一种“偏差常态化”的成分——每当某个模型在我没有密切监控的情况下，证明自己写出了正确的代码，我就有可能在未来错误的时刻信任它，结果吃亏。

过去，如果你找到一个有一百个提交、README 写得不错、还有自动化测试等等的 GitHub 仓库，你大致可以确信，写这个仓库的人在这个项目上投入了大量的心血和关注。可现在，我半小时就能敲出一个有一百个提交、漂亮的 README、而且对每一行代码都有完整测试的 git 仓库！它看起来和那些倾注了大量心血的项目一模一样。也许它和那些项目一样好。我不知道。光看表面我分辨不出来。就连对我自己的项目，我也分辨不出来。所以我意识到，比起测试和文档的质量，我更看重的是有人真的用过这个东西。如果你有一个 vibe coded 的东西，而且你在过去两周里每天都在用它，那么对我来说，它比你刚刚随手拼出来、几乎没怎么实际跑过的东西要有价值得多。

如果你能把每天产出 200 行代码提升到 2,000 行代码，还会有什么地方出问题？事实证明，整个软件开发生命周期都是围绕“每天产出几百行代码需要一整天”这一想法设计的。而现在不是了。不只是下游环节，连上游环节也是如此。我看过 Anthropic 的设计负责人 Jenny Wen 的一场很棒的演讲，她说，我们有这么多设计流程，都是建立在你必须把设计做对这一前提上的——因为如果你把设计交给工程师，而他们花三个月做出了错误的东西，那将是灾难性的。你会建立起一整套非常复杂的设计流程，就是因为这种设计一旦出错，代价会很高。但如果开发不再需要三个月，那么设计流程也许就可以冒更大的风险，因为犯错的成本已经被大大降低了。

如果你能把每天产出 200 行代码提升到 2,000 行代码，还会有什么地方出问题？事实证明，整个软件开发生命周期都是围绕“每天产出几百行代码需要一整天”这一想法设计的。而现在不是了。

不只是下游环节，连上游环节也是如此。我看过 Anthropic 的设计负责人 Jenny Wen 的一场很棒的演讲，她说，我们有这么多设计流程，都是建立在你必须把设计做对这一前提上的——因为如果你把设计交给工程师，而他们花三个月做出了错误的东西，那将是灾难性的。

你会建立起一整套非常复杂的设计流程，就是因为这种设计一旦出错，代价会很高。但如果开发不再需要三个月，那么设计流程也许就可以冒更大的风险，因为犯错的成本已经被大大降低了。

当我审视自己与这些 agents 的对话时，我非常清楚地意识到，这对绝大多数人类来说都是火星语言。之所以我并不担心软件工程师这份职业会因为电脑能自己写代码而终结，有很多原因，其中一部分是这些工具会放大既有经验。你如果知道自己在做什么，就能借助它们跑得快得多。[...] 在使用这些工具的过程中，我不断被提醒，我们所做的事情有多么困难。做软件是一件极其困难的事。就算把世界上所有的 AI 工具都交给我，我们想要实现的目标依然非常困难。[...] 政治评论员 Matthew Yglesias 昨天在推文中写道：“用了五个月后，我想我已经决定了，我不想 vibe code——我想要的是由专业管理的软件公司使用 AI 编码辅助，做出更多、更好、更便宜的软件产品，然后卖给我赚钱。”我觉得这话相当到位。我可以在看了足够多管道维修的 YouTube 视频后自己给房子装管道。可我还是更愿意请一位水管工。

当我审视自己与这些 agents 的对话时，我非常清楚地意识到，这对绝大多数人类来说都是火星语言。

我并不担心自己的软件工程师生涯会因为电脑现在能自己写代码而结束，原因有很多，其中一部分是这些工具本质上是在放大既有经验。如果你知道自己在做什么，借助它们就能跑得快得多。[...]

当我使用这些工具时，我不断被提醒，我们所做的事情有多难。开发软件是一件极其困难的事。即便把全世界所有的 AI 工具都给我，我们试图实现的目标仍然非常困难。[...]

政治评论员 Matthew Yglesias 昨天在推特上写道：“用了五个月后，我想我已经决定了：我不想 vibe code——我想要的是由专业管理的软件公司使用 AI 编码辅助，做出更多、更好、更便宜的软件产品，然后卖给我赚钱。”我觉得这话相当准确。我只要在 YouTube 上看够多的管道维修视频，就可以自己给家里做管道布设。不过我还是更愿意请一位水管工。

至于企业自己动手做方案会对 SaaS 供应商构成什么威胁：

我刚意识到，这和我前面说的那句话是一回事：我只会在你已经把你的副项目用了几周之后才想用它。放到企业版上就是，除非至少有另外两家大型企业成功使用某个 CRM 六个月，否则我不想用它。[...] 你需要的是那些在承担风险之前已经被证明可行的解决方案。

我刚意识到，这和我前面说的那句话是一回事：我只会在你已经把你的副项目用了几周之后才想用它。放到企业版上就是，除非至少有另外两家大型企业成功使用某个 CRM 六个月，否则我不想用它。[...] 你需要的是那些在承担风险之前已经被证明可行的解决方案。

来源与参考

1. 原始链接
2. Vibe coding and agentic engineering are getting closer than I’d like