Vibe coding 与 agentic engineering 正比我想象中更接近Vibe coding and agentic engineering are getting closer than I'd like

2026年5月6日

我最近与约瑟夫·鲁西奥（Joseph Ruscio）在 Heavybit 的《高杠杆播客》（High Leverage podcast）中进行了交流，本期节目是第9集，题为《AI编程范式转变》，嘉宾为西蒙·威利斯顿（Simon Willison）。以下是我的一些感悟，包括一个令人不安的发现：在我的工作中， vibe coding（氛围式编程）和 agentic engineering（代理式工程）已经开始融合。

我特别喜欢播客的一点是，它们有时会促使我以一种能将想法清晰表达出来的方式“大声思考”，而这正是我之前一直难以做到的。

vibe coding 和 agentic engineering 正在开始重叠

在“vibe coding”这个术语首次提出几周后，我发表了文章《并非所有 AI 辅助编程都是 vibe coding（但 vibe coding 确实很棒）》，其中明确表达了我的观点：“vibe coding”与负责任地使用 AI 编写代码有着本质不同，而后者我后来称之为 agentic engineering。

当约瑟夫提到这两者之间的区别时，我突然意识到，对我来说，它们之间的界限远不如过去那样分明了：

奇怪的是，这些界限对我来说已经开始模糊了，这让我感到相当不安。我曾以为我们有一个非常清晰的划分：vibe coding（ vibe 编码）是那种你根本不看代码的情况。你可能甚至不知道如何编程。你可能是一个非程序员，提出一个需求，得到一个结果，如果结果能用，那就太好了！如果不能，你就告诉它不行，然后祈祷。但在任何情况下，你都不会真正关心代码质量或任何其他约束条件。我对 vibe coding 的看法是，只要你明白什么时候可以用、什么时候不能用，那它就是很棒的。作为个人工具，如果出错了只伤害你自己，那就大胆用吧！如果你在为别人构建软件，vibe coding 就是极其不负责任的，因为那是别人的信息。别人的数据会因你的愚蠢错误而受损。你需要有更高的标准。这与代理工程（agentic engineering）形成对比，后者你是专业的软件工程师。你了解安全、可维护性、运维和性能等方面。你正在尽自己最大的能力使用这些工具。我发现我能应对的挑战范围显著扩大了，因为我有了这些工具的支持。但我仍然依赖自己25年的软件工程经验。目标是构建高质量的生产系统：如果你是为了更快地构建低质量的东西，我认为这是不好的。我想要更快地构建更高质量的东西。我希望我构建的一切都比之前更好。问题是，随着编码代理越来越可靠，我不再审查它们为我的生产级项目编写的每一行代码。我非常清楚，如果你让 Claude Code 构建一个 JSON API 端点，运行 SQL 查询并以 JSON 格式输出结果，它就会正确地完成任务。它不会搞砸。如果你让它添加自动化测试，让它添加文档，你知道它会做得很好。但我不审查那段代码。现在我有了一种负罪感：如果我没有审查代码，我真的有责任在生产中使用这个吗？真正帮助我的是回想我在大型组织中担任工程经理的时候。其他团队正在构建我的团队所依赖的软件。如果另一个团队交付了一个东西，说“嘿，这是图像调整大小服务，这是用它来调整图像大小的方法”……我不会去读他们写的每一行代码。我会看他们的文档，用它调整一些图像，然后开始发布自己的功能。如果我遇到问题，比如图像调整器似乎有 bug 或者性能不好，我才会深入他们的 Git 仓库看看发生了什么。但大多数时候，我都把它当作一个半黑盒，直到需要时才去看。我开始以同样的方式对待这些代理。这仍然让我感到不舒服，因为人类对自己做的事情负有责任。一个团队可以建立声誉。我可以说我信任那个团队，他们在过去构建了好的软件，他们不会构建垃圾，因为这会影响他们的职业声誉。Claude Code 没有职业声誉！它无法对它所做的事情负责。但它一直在证明自己——一次又一次地，它都能以我喜欢的方式正确地完成简单的事情。

这里有一种“违规正常化”的倾向——每次模型在没有我密切监控的情况下却写出了正确的代码，我就可能在未来某个错误的时机过度信任它，从而遭遇失败。

评估软件的新挑战

过去，如果你在 GitHub 上看到一个有上百次提交、说明文档清晰、配有自动化测试的项目，你大概可以确信：写这个项目的人投入了大量心血和专注。 但现在，我可以在半小时内就创建一个拥有上百次提交、README 漂亮、且对每一行代码都有全面测试的 Git 仓库！它看起来和那些倾注了极大心血的经典项目一模一样。也许它们一样好。但我不知道。我也无法仅凭外观判断。甚至对于我自己做的项目，我也看不出来。 所以我意识到，比起测试和文档的质量，我更看重的是有人真正用过这个工具。如果你有一个 Vibecoded 的工具，并且过去两周每天都在使用它，那对我来说远比一个刚出炉、几乎没怎么动过的东西更有价值。

瓶颈已经转移

如果你能把每天产出 200 行代码提升到 2000 行，还有什么会随之崩溃？事实证明，整个软件开发生命周期原本就是围绕“一天只能写出几百行代码”这一前提设计的。而现在这个前提已经不成立了。 这不仅影响下游流程，也冲击上游。我曾看过 Jenny Wen（Anthropic 的设计负责人）的一场精彩演讲，她说我们建立了一系列设计流程，是因为我们相信：必须把设计做对——因为一旦交给工程师，他们花三个月时间做了错误的东西，后果将不堪设想。 这套复杂而详尽的设计流程之所以存在，是因为设计出错的成本很高。但如果现在只需几周就能完成开发，那么设计本身就可以承担更大的风险——毕竟，即使错了，代价也没那么大了。

为什么我仍不担心自己的职业生涯

当我与这些智能体交流时，我清楚地意识到，对绝大多数人来说，这不过是“登月语言”罢了。 尽管计算机能自己写代码，我并不担心自己作为软件工程师的职业前景，原因有很多。首先，这些工具本质上是现有经验的放大器：只要你懂行，就能用它们大幅提升效率。[...] 在与这些工具的持续协作中，我不断被提醒：我们所做的这件事其实极其困难。编写软件是一项异常艰巨的任务。就算给我世界上所有 AI 工具，我们试图达成的目标依然非常困难。[...] 政治评论员 Matthew Yglesias 昨天发推说：“五个月过去了，我想我已经决定，我不想要 Vibecoded 软件——我想要由专业软件公司用 AI 辅助编码来提供更优质、更便宜、更好的产品，然后卖给我。”我觉得这话说得挺准。如果我看足够多的 YouTube 视频，我也能自己修家里的水管；但我宁愿雇个水管工。

关于 SaaS 提供商面临企业自建解决方案威胁的问题：

我刚刚意识到，我之前说过的一个观点是，我只会在你使用这个项目几周后才会考虑使用你的项目。企业版本的意思是，除非至少两家大型企业已经成功使用该 CRM 系统达六个月之久，否则我不会考虑使用任何 CRM。[...] 你在采用解决方案之前，希望确保它们已经被证明是有效的，而不是冒险尝试。