Vibe coding和agentic engineering正在变得比我预想的更接近
2026年5月6日
我最近与Joseph Ruscio讨论了关于AI编程工具的话题，该对话收录在Heavybit的High Leverage播客中：Ep. #9, The AI Coding Paradigm Shift with Simon Willison。以下是我的一些亮点，包括一个令人不安的发现：在我自己的工作中，vibe coding和agentic engineering已经开始融合。
我非常喜欢播客的一点是，它们有时会促使我进行口头思考，从而揭示出一些我以前无法用语言表达的想法。
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（智能体工程）形成对比：你是一名专业的软件工程师。你理解安全性、可维护性、运维、性能等等。你在用这些工具发挥自己能力的极限。我发现我能应对的挑战范围大幅提升了，因为有这些工具的辅助。
但我仍然依赖我 25 年的软件工程经验。
目标是构建高质量的生产系统：如果你在更快地构建低质量的东西，我觉得那很糟糕。我想更快地构建更高质量的东西。我希望我构建的每一样东西在各方面都比之前更好。
问题在于，随着编码智能体越来越可靠，我已经不再审查它们写的每一行代码了——即使是对我生产级别的代码也是如此。
我非常清楚，如果你让 Claude Code 构建一个 JSON API 端点，它执行一条 SQL 查询并将结果以 JSON 格式输出，它就能直接做对。它不会搞砸。你让它添加自动化测试，添加文档，你知道它会很好。
但我已经不审查那些代码了。
标题：Vibe coding 和 agentic engineering 比我想象的更接近了
原文：
而现在我有了那种负罪感：如果我没有审查过代码，我把它用在生产环境里，真的负责任吗？
真正能帮到我的是回想自己在大公司做工程经理的经历。其他团队在构建我团队所依赖的软件。
如果一个团队交过来一样东西说：“嘿，这是图片缩放服务，这是使用它来缩放图片的方法”……我是不会去逐行阅读他们写的每一行代码的。
我会看他们的文档，然后用它来缩放几张图片。接下来我就开始发布自己的功能了。如果后来遇到了图片缩放工具有 bug 或者性能不好，那时我才会去翻他们的 Git 仓库看看怎么回事。但大多数时候，我把它当作一个半黑箱，除非有必要，否则不会打开看。
我开始用同样的方式对待 agent。这仍然让人感到不舒服，因为人类要为自己的行为负责。一个团队可以建立声誉。我可以说：“我信任那边那个团队。他们以前造过不错的软件。他们不会搞出些垃圾来，因为这关乎他们的职业声誉。”
Claude Code 没有职业声誉！它无法为自己的行为负责。但它一直在证明自己——一次又一次地，它在产出简单直接的东西，并且按照我喜欢的风格把它们做对。
标题：Vibe coding和Agentic engineering正在变得比我预想的更接近
原文：
这里存在一种偏差正常化的因素——每当模型在我没有密切监控的情况下写出正确的代码时，我都有可能在未来的某个错误时刻信任它，从而遭受损失。
评估软件的新挑战
过去，如果你找到一个拥有上百次提交、有完善的README和自动化测试等内容的GitHub仓库，你基本可以确定编写者对这个项目投入了大量的心血和关注。
而现在，我可以在半小时内捣鼓出一个同样拥有上百次提交、漂亮的README和覆盖每一行代码的全面测试的git仓库！它看起来与那些精心打造的项目一模一样。也许它真的和它们一样好。我不知道。我无法通过查看来分辨。甚至对于我自己的项目，我也分不清。
所以我意识到，比起测试和文档的质量，我更看重的是有人实际使用过它。如果你有一个通过vibe coding搞出来的东西，并且你在过去两周里每天都在用，那对我来说，这比你刚吐出来、几乎没怎么运行过的东西要有价值得多。
瓶颈已经转移
为什么我仍然不担心自己的职业生涯
如果你能从每天产出200行代码变成每天产出2000行代码，还有什么会崩溃？原来，整个软件开发生命周期都是围绕"一天只能写几百行代码"这一理念设计的。但现在情况不同了。
受影响的不只是下游环节，上游环节也同样如此。我听过Jenny Wen的一场精彩演讲，她是Anthropic的设计负责人。她说，我们所有的设计流程都基于这样一个想法：你必须把设计做对——因为如果你把设计交给工程师，他们花了三个月时间去构建错误的东西，那将是灾难性的。
我们之所以建立如此复杂的设计流程，是因为设计会导致昂贵的工作。但如果构建不再需要三个月，也许设计流程可以承担更多风险——因为一旦出错，成本已经大大降低了。
当我回顾自己与那些智能体（agents）的对话时，我非常清楚地意识到，对绝大多数人来说，这简直就是天书。
有很多原因让我并不担心自己作为软件工程师的职业生涯会因为计算机能自己写代码而终结，部分原因在于这些东西是现有经验的放大器。如果你知道自己正在做什么，用上它们就能跑得快得多。[...]
在使用这些工具的过程中，我不断被提醒，我们做的事有多难。生产软件是一件极其困难的事情。就算你给我全世界所有的AI工具，我们试图实现的目标依然非常困难。[...]
政治评论员Matthew Yglesias昨天发了条推文说："五个月过去了，我想我已经决定，我不想要氛围编码——我想要专业管理的软件公司使用AI编码辅助，来制造更多/更好/更便宜的软件产品，然后卖给我赚钱。"我觉得这话说得挺在理的。我可以通过看足够多的水管工YouTube视频来给自己家接水管，但我宁愿雇一个水管工。
关于企业自行构建解决方案对SaaS（软件即服务）提供商造成的威胁：
我刚才意识到，这就像我之前说的：只有当你自己用了几周你的副业项目，我才会考虑用。企业版的逻辑是，我不想用一个CRM（客户关系管理系统），除非至少还有另外两家大型企业已经成功用了那个CRM六个月以上。[...] 在你冒险之前，你希望得到那些已经被证明可行的解决方案。