Vibe coding 和 agentic engineering 的界限正在变得比我想象中更模糊

来源: Simon Willison’s Weblog | 作者: Simon Willison | 日期: 2026-05-06 原文链接: https://simonwillison.net/2026/May/6/code-w-claude-2026/#atom-everything

一句话总结

Simon Willison 坦承，随着 AI 编程 agent 可靠性提升，他已经不再逐行审查其产出的代码，vibe coding 和 agentic engineering 之间的清晰界线正在他自己的实践中逐渐消融——这既令人兴奋也令人不安。

速览

两种范式正在融合——即使是强调”负责任使用 AI”的 agentic engineering 从业者，也开始像 vibe coder 一样不再逐行审查代码
信任建立机制类似于团队协作——Willison 把 AI agent 视为一个已证明能力的”隔壁团队”，按黑盒方式使用其交付物
偏差正常化的风险真实存在——每次模型在无人监督下做对了，都增加了未来在错误时刻过度信任的概率
传统代码质量信号已失效——一百个 commit、完善的 README、全覆盖测试的仓库现在半小时即可生成，无法再作为质量判断依据
“被使用过”比”看起来好”更有价值——真正的质量信号是作者持续使用了两周，而不是表面的工程完善度
软件开发生命周期的基础假设已改变——整个上下游流程都建立在”一天产出几百行代码”的前提上，这个前提不再成立
设计流程可以承担更大风险——当构建成本大幅下降，犯错成本也随之下降，设计无需追求一次做对
AI 工具是经验的放大器而非替代品——有 25 年经验的人用 AI 跑得更快，但生产软件本身仍然极其困难
普通人仍然需要专业软件公司——大多数人不想 vibecode，他们想买更好更便宜的专业产品
企业采购逻辑不变——没人想用未经验证的方案，需要至少两家大企业成功使用六个月才敢冒险

核心内容

Vibe coding 与 agentic engineering 的融合困境

Willison 曾在 2025 年 3 月明确划清两者界线：vibe coding 是不看代码、不关心质量的快速原型方式；agentic engineering 是专业工程师在 AI 辅助下追求高质量生产系统的工作方式。

但现实是，随着 Claude Code 等工具可靠性提升，他发现自己即使在生产级项目中也不再逐行审查代码。“如果你让 Claude Code 构建一个 JSON API 端点——运行 SQL 查询、输出 JSON——它就是会做对。“既然知道它会做对，审查的动力就消失了。

这带来了负罪感：如果没审查代码就用于生产，这算负责任吗？

“隔壁团队”类比：建立对 AI 的信任模型

Willison 找到的心理框架是回忆大型组织中的工作方式。当隔壁团队交付一个图片缩放服务时，你不会去读他们的每一行代码——你看文档，用它，出了问题再去翻 Git 仓库。

他开始以同样方式对待 AI agent。但不适感仍在：人类团队有声誉、有责任感、有”做出垃圾会毁掉职业生涯”的约束。Claude Code 没有职业声誉，也无法承担责任。

然而它一直在证明自己——一次又一次按照他喜欢的风格正确完成任务。

偏差正常化：无声积累的风险

Willison 引用了”偏差正常化”的概念：每次在缺乏监督的情况下模型做出了正确的结果，信任就增加一分。但这种渐进式信任建立的风险在于——你无法知道哪一次会翻车，而到那时你可能已经完全放松了警惕。

代码质量信号的失效与新标准

过去：一百个 commit + 好的 README + 自动化测试 = 作者倾注了心血。现在：同样的东西半小时就能生成，即使是 Willison 自己的项目，他也无法通过外观分辨质量。

新的判断标准：有人是否真正使用过这个工具。连续使用两周的 vibe coded 项目，比刚生成但未验证的”完美”项目更值得信赖。

瓶颈转移：整个生命周期需要重新设计

当产出从 200 行/天变成 2,000 行/天：

下游：测试、部署、运维流程是否能承受 10 倍代码量？
上游：Anthropic 设计负责人 Jenny Wen 指出，设计流程存在的原因是”交付给工程师后三个月构建错误的东西是灾难”。当构建成本趋近于零，设计可以更大胆、更迭代、更容错。

职业前景：放大器而非替代品

Willison 不担心自己的职业生涯，理由是：

他与 agent 的对话对大多数人来说是”天书”
AI 工具放大已有经验，知道在做什么的人能跑得更快
生产软件仍然极其困难，所有 AI 工具也无法改变这一事实
引用 Matthew Yglesias 的话：大多数人不想自己 vibecode，他们想要专业公司卖给他们更好更便宜的产品——就像你可以看 YouTube 学修水管，但你宁愿雇水管工

名言金句

“如果你只是更快地产出低质量的东西，我认为那很糟糕。我想要的是更快地构建更高质量的东西。”
“Claude Code 没有职业声誉！它无法为自己所做的事情承担责任。但它一直在证明自己。”
“我不想用你那个 CRM，除非至少有两家大企业已经成功用了六个月。”
“生产软件是一件极其困难的事情。你可以给我世界上所有的 AI 工具，我们想要实现的事情仍然非常困难。”
“五个月过去了，我不想 vibecode——我想要专业管理的软件公司使用 AI 编程辅助工具来为我制造更多/更好/更便宜的软件产品。” —— Matthew Yglesias

可行建议

建立”使用验证”机制：对 AI 生成的代码，持续使用两周再推向生产，比逐行审查更实际
意识到偏差正常化：定期强制自己对 AI 产出做深度审查，打破”每次都对所以不用看”的惯性
重新评估质量信号：不再以 commit 数、测试覆盖率作为唯一标准，增加”实际使用时长”和”经历过的 edge case”作为判断维度
调整设计流程：当构建成本下降时，允许设计更具探索性，用快速原型替代冗长的前期设计
承认新的信任模型：像对待”隔壁团队”一样对待 AI agent——信任但验证，出问题再深究

资源清单

Ep. #9, The AI Coding Paradigm Shift with Simon Willison — Heavybit High Leverage 播客原集
Not all AI-assisted programming is vibe coding — Willison 对 vibe coding 的初始定义
Agentic Engineering Patterns — Willison 的 agentic engineering 指南
Don’t Trust the Process — Jenny Wen (Anthropic) 关于设计流程变革的演讲
Normalization of Deviance — 偏差正常化概念讨论

Vibe coding 和 agentic engineering 的界限正在变得比我想象中更模糊

2026 年 5 月 6 日

我最近和 Joseph Ruscio 在 Heavybit 的 High Leverage 播客中聊了聊 AI 编程工具：Ep. #9, The AI Coding Paradigm Shift with Simon Willison。以下是我的一些精华片段，包括一个令我不安的发现——vibe coding 和 agentic engineering 在我自己的工作中已经开始融合了。

播客有一点我特别喜欢，它有时会逼着我即兴思考，从而说出一些我之前无法用文字表达的想法。

Vibe coding 和 agentic engineering 开始交叉重叠 #

在 vibe coding 这个概念被提出几周后，我发表了《并非所有 AI 辅助编程都是 vibe coding（但 vibe coding 很棒）》，明确表达了我的观点：“vibe coding”和负责任地使用 AI 编写代码是截然不同的两件事——后者我后来称之为 agentic engineering。

当 Joseph 提到这两者的区别时，我突然意识到，对我来说它们已经不像以前那么泾渭分明了：

奇怪的是，这两件事对我来说已经开始模糊了，这让我相当不安。

我原以为有一条非常清晰的界线——vibe coding 就是那种你根本不看代码的方式。你甚至可能不会编程。你可能是一个非程序员，向 AI 提出需求，拿到产物，如果能用就太好了！如果不行，你告诉它不行，然后祈祷好运。

在整个过程中，你根本不关心代码质量或任何额外的约束条件。我对 vibe coding 的看法是：它非常棒，前提是你知道什么时候可以用、什么时候不可以。

一个只给你自己用的工具，如果有 bug 只伤害你自己，那就放手去做！

但如果你是在为其他人构建软件，vibe coding 就是极其不负责任的行为，因为涉及的是别人的信息。别人会因为你的低级 bug 而受到伤害。你需要达到更高的标准。

这与 agentic engineering 形成对比——在后者中，你是一名专业的软件工程师。你理解安全性、可维护性、运维和性能等等。你是在用自己最高的能力水平使用这些工具。我发现自己能承接的挑战范围已经显著扩大了，因为有了这些工具的支持。

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

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

问题在于，随着编程 agent 变得越来越可靠，即使是我的生产级项目，我也不再逐行审查它们写的每一行代码了。

我很清楚，如果你让 Claude Code 构建一个 JSON API 端点，运行一个 SQL 查询并将结果输出为 JSON，它就是会做对。它不会搞砸这种事情。你让它加上自动化测试，让它加上文档，你知道它会做好。

但我没有审查那些代码。现在我有了负罪感：如果我没有审查代码，把它用在生产环境中真的负责任吗？

真正帮助我释然的是回想起在大型组织工作时的经历——那时我是工程经理。其他团队构建的软件是我的团队所依赖的。

如果另一个团队交付了某个东西并说：“嘿，这是图片缩放服务，这是使用方法”……我不会去阅读他们写的每一行代码。

我会看他们的文档，然后用它来缩放一些图片。然后我就开始开发自己的功能了。如果我开始遇到问题——图片缩放服务似乎有 bug 或者性能不好——那时我才会去看他们的 Git 仓库，了解发生了什么。但大多数情况下，我把它当作一个半黑盒，不需要时不去看。

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

Claude Code 没有职业声誉！它无法为自己所做的事情承担责任。但它一直在证明自己——一次又一次地处理那些简单直白的任务，并且按照我喜欢的风格把它们做对了。

这里有一种偏差正常化的成分——每当一个模型在我没有密切监督的情况下写出了正确的代码，就增加了一分风险：未来某个错误的时刻我可能过度信任它，然后翻车。

评估软件的新挑战 #

过去，如果你在 GitHub 上找到一个有一百个 commit、良好的 README、自动化测试的仓库，你基本可以确定作者对这个项目投入了大量的心血和关注。

而现在，我半个小时就能搞出一个有一百个 commit、漂亮的 README、覆盖每一行代码的全面测试的 Git 仓库！它看起来和那些精心打磨的项目一模一样。也许它确实一样好，我不知道。光看是看不出来的。甚至对我自己的项目，我也分辨不出来。

所以我意识到，比起测试和文档的质量，我更看重的是有人是否真正用过这个东西。如果你有一个 vibe coded 的工具，而你在过去两周里每天都在使用它，那对我来说比你随手吐出来的、几乎没怎么验证过的东西要有价值得多。

瓶颈已经转移了 #

如果你能从每天产出 200 行代码变成每天 2,000 行代码，还有什么会崩溃？事实证明，整个软件开发生命周期都是围绕”一天产出几百行代码”这个假设设计的。而现在这个假设不成立了。

不仅是下游的东西会崩溃，上游也一样。我看过 Jenny Wen 的一个精彩演讲——她是 Anthropic 的设计负责人——她说我们所有的设计流程都建立在一个前提上：你需要把设计做对——因为如果你把它交给工程师，他们花三个月构建了错误的东西，那就是灾难。

你建立了这一整套非常周全的设计流程，是因为设计会导致昂贵的工程工作。但如果构建不再需要三个月，也许设计流程可以冒更大的险，因为犯错的成本已经大幅降低了。

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

当我回看自己和 agent 的对话时，非常明显的是，对绝大多数人来说这就是天书。

我不害怕我作为软件工程师的职业生涯因为计算机能自己写代码而终结，原因有很多，部分是因为这些工具是现有经验的放大器。如果你知道自己在做什么，使用它们可以跑得快得多。[…]

在使用这些工具的过程中，我不断被提醒我们所做的事情有多难。生产软件是一件极其困难的事情。你可以给我世界上所有的 AI 工具，我们在这里想要实现的事情仍然非常困难。[…]

政治评论员 Matthew Yglesias 昨天发推说：“五个月过去了，我想我已经决定了，我不想 vibecode——我想要专业管理的软件公司使用 AI 编程辅助工具来为我制造更多/更好/更便宜的软件产品，然后卖给我赚钱。“这和我的感觉差不多。我可以看足够多的 YouTube 水管工视频来自己修水管。但我宁愿雇一个水管工。

关于 SaaS 供应商面临的威胁——企业可能会自己开发解决方案，而不再购买：

我刚意识到这和我之前说的一样——我只想用你那个已经使用了好几周的 side project。企业版的说法就是：除非至少有两家其他大型企业已经成功使用了那个 CRM 六个月，否则我不想用。[…] 你需要经过验证有效的解决方案，才敢冒险去用。