Vibe coding 和 agentic engineering 正在变得比我预想的更接近

来源: Simon Willison’s Weblog | 作者: Simon Willison | 日期: 2026-05-06 原文链接: https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/

一句话总结

随着 AI 编程 agent 越来越可靠，Simon Willison 发现自己曾经坚持的 “vibe coding”（随意编程）与 “agentic engineering”（专业 AI 辅助编程）之间的严格界限正在模糊——他不再逐行审查 agent 写的代码了，这让他既兴奋又不安。

速览

Vibe coding 与 agentic engineering 正在融合——随着 agent 可靠性提升，即使是专业工程师也开始跳过代码审查，两种模式的边界正在消失
“用过”比”写得好”更有价值——AI 能在半小时内生成看起来完美的项目，真正的质量信号不再是代码本身，而是实际使用时长
偏差正常化的风险——每次 agent 在无监督下正确完成任务，都在增加未来错误时刻过度信任的风险
软件开发生命周期的整体假设被颠覆——不仅下游（测试、部署）受影响，上游（设计流程）也需要根本性重构
设计流程可以更冒险了——当构建成本从三个月变为几天，犯错的代价大幅降低，设计流程不必那么保守
AI 是经验的放大器——拥有深厚经验的工程师用 AI 工具获益最大，门槛并未消失
SaaS 不会被自建方案取代——企业需要经过验证的解决方案，就像个人需要”用过两周”的工具一样

核心内容

Vibe coding 与 agentic engineering 的边界正在瓦解

Simon 曾经在 2025 年 3 月明确划出了分界线：vibe coding 是不看代码、祈祷能用的方式，适合个人工具；agentic engineering 是专业工程师利用 AI 辅助、依然对质量负责的方式。

但现在他发现自己已经不再逐行审查 Claude Code 写的代码了。他知道让 Claude Code 构建一个运行 SQL 查询的 JSON API 端点，它就是会正确完成——不会搞砸。于是他开始像对待大公司里另一个团队的交付物那样对待 agent 的输出：看文档、用起来、出问题再查代码。

这让他感到不安，因为人类团队有职业声誉作为质量担保，而 Claude Code 没有。但它一直在用正确的方式、他喜欢的风格完成工作。

偏差正常化——信任的危险积累

Simon 指出这里存在”偏差正常化”的风险模式：每一次 agent 在无人审查的情况下做对了，都在悄悄抬高信任阈值。问题不在于它今天做对了，而在于当它终于做错的那一刻，你已经放松了警惕。

“用过”成为新的质量信号

AI 可以在半小时内生成一个有一百个 commit、漂亮 readme、全面测试的 GitHub 仓库——从外表完全无法区分它是精心打造还是随手吐出。Simon 的新标准是：有人真正使用过这个东西吗？一个每天使用了两周的 vibe coded 项目，比一个刚生成出来没怎么验证的项目有价值得多。

瓶颈从编码转移到整个生命周期

当代码产出从每天 200 行变成 2000 行，整个围绕”编码慢”这个假设构建的软件开发流程都需要重新审视。Jenny Wen（Anthropic 设计负责人）指出：复杂的设计流程存在的前提是”工程实现很贵”，当实现成本大幅降低，设计流程可以承受更多试错。

AI 工具是经验放大器，不是经验替代品

Simon 看自己和 agent 的对话记录，对普通人来说完全是天书。这些工具放大已有经验，而不是消除门槛。生产软件本身仍然极其困难。Matthew Yglesias 的比喻很贴切：你可以看 YouTube 学修水管，但你更想请专业水管工。

SaaS 和经过验证的软件仍有价值

企业版的”用过”标准是：我不想要一个 CRM，除非至少两家大型企业已经成功使用了六个月。即使 AI 让自建变得更容易，人们仍然想要经过验证能用的解决方案。

名言金句

“The goal is to build high quality production systems: if you’re building lower quality stuff faster, I think that’s bad. I want to build higher quality stuff faster.”
“Claude Code does not have a professional reputation! It can’t take accountability for what it’s done. But it’s been proving itself anyway.”
“What I value more than the quality of the tests and documentation is that I want somebody to have used the thing.”
“The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn’t.”
“I can plumb my house if I watch enough YouTube videos on plumbing. I would rather hire a plumber.”

可行建议

建立 agent 输出的验证机制：不要依赖代码审查，而是通过实际使用和自动化测试来验证 agent 产出的质量
重新定义”质量信号”：从代码外观（commit 数、测试覆盖率）转向使用时长和实际验证
重构设计流程：既然构建成本降低了，让设计流程更快速、更允许试错，用原型替代冗长的规格说明
保持对偏差正常化的警觉：定期抽查 agent 代码，不要因为连续成功就完全放松监控

资源清单

Heavybit High Leverage Ep. #9 播客
Not all AI-assisted programming is vibe coding — Simon 2025 年的原始分类文章
Agentic engineering 指南
The normalization of deviance
Jenny Wen: Don’t Trust the Process — Anthropic 设计负责人谈设计流程变革

Vibe coding 和 agentic engineering 正在变得比我预想的更接近

我最近和 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 是那种你完全不看代码的方式。你甚至可能不会编程。你可能是一个非程序员，你要求一个东西，得到一个东西，如果这东西能用，那太好了！如果不能用，你告诉它不能用，然后祈祷好运。

但在这个过程中你完全不关心代码质量或任何额外的约束条件。我对 vibe coding 的看法是：它很棒，前提是你理解什么时候可以用，什么时候不可以。

给你自己用的个人工具，如果有 bug 只伤害你自己，那就尽管用吧！

但如果你在为其他人构建软件，vibe coding 是极度不负责任的，因为这涉及其他人的信息。其他人会被你愚蠢的 bug 伤害。你需要有更高的标准。

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

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

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

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

我完全清楚，如果你让 Claude Code 构建一个运行 SQL 查询并将结果输出为 JSON 的 API 端点，它就是会正确完成。它不会搞砸这个。你让它添加自动化测试，让它添加文档，你知道它会做得很好。

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

真正帮助我的是回想我在大型组织工作时的经历，那时我是一个工程管理者。其他团队在构建我的团队依赖的软件。

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

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

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

Claude Code 没有职业声誉！它无法为自己所做的事情承担责任。但它一直在证明自己——一次又一次地，它在按照我喜欢的风格正确完成那些直截了当的事情。

这里有一种偏差正常化的元素——每次模型在我没有密切监控的情况下写出了正确的代码，都有风险让我在未来错误的时刻过度信任它而被坑。

评估软件的新挑战

过去，如果你找到一个有一百个 commit、良好 readme 和自动化测试的 GitHub 仓库，你可以相当确定写这些东西的人在这个项目上投入了大量的关注和心血。

而现在我可以在半小时内生成一个有一百个 commit、漂亮 readme 和覆盖每一行代码的全面测试的 git 仓库！它看起来和那些投入了大量关注和心血的项目完全一样。也许它确实和它们一样好。我不知道。我从外表看不出来。即使是我自己的项目，我也看不出来。

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

瓶颈已经转移

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

不仅仅是下游的东西，上游的东西也一样。我看了 Jenny Wen 一个很棒的演讲，她是 Anthropic 的设计负责人，她说我们所有的设计流程都是基于这样一个假设：你需要把设计做对——因为如果你把它交给工程师，他们花三个月构建了错误的东西，那就是灾难性的。

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

为什么我仍然不担心我的职业

当我看我和 agent 的对话时，对我来说非常清楚的是，这对绝大多数人来说是天书。

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

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

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

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

我刚才意识到这就是我之前说的——我只想用你那个已经用了几周的业余项目。企业版的说法就是，我不想要一个 CRM，除非至少有另外两家大型企业已经成功使用了那个 CRM 六个月。[…] 你想要经过验证能用的解决方案，然后再冒险采用。