Vibe Coding与Agentic Engineering边界模糊：Simon Willison的深度反思

引言

Simon Willison——Django框架联合创始人、拥有25年经验的资深软件工程师——最近在Heavybit的High Leverage播客中分享了一个令他自己都感到不安的发现：他曾经认为泾渭分明的"Vibe Coding"（氛围编程）和"Agentic Engineering"（智能体工程）两种AI编程范式，在他自己的日常工作中已经开始融合。

这个观察触及了当前AI辅助编程领域最核心的张力——当AI代码生成变得越来越可靠，专业工程师该如何定义自己的责任边界？

两种AI编程范式的原始定义

Vibe Coding：不看代码的编程方式

Vibe Coding这个概念诞生于2025年初，由OpenAI联合创始人Andrej Karpathy首次提出。他在社交媒体上描述了一种全新的编程方式：完全依赖大语言模型生成代码，开发者只需用自然语言描述需求，然后接受AI的输出结果，不进行传统意义上的代码审查。这种方式的兴起与2024-2025年间代码生成模型能力的飞跃密切相关——当模型在HumanEval等代码基准测试中的通过率从60%跃升至90%以上时，"不看代码直接用"在某些场景下变得可行。

核心特征很直白：开发者不审查代码，甚至可能根本不懂编程。生成的东西能跑就用，跑不了就告诉AI哪里不对，然后听天由命。

Simon对Vibe Coding的态度一直很明确：它适合个人工具——如果出了bug只影响你自己，尽管放手去做。但如果是为他人构建软件，这种方式是"极不负责任的"，因为低质量代码最终会伤害到用户。

Agentic Engineering：专业工程师的AI协作模式

与之对应的Agentic Engineering，要求开发者本身是专业软件工程师，深刻理解安全性、可维护性、运维和性能等工程要素。在这种模式下，Claude Code等AI工具充当放大器，放大的是你多年积累的工程经验。

Claude Code是Anthropic于2025年推出的命令行AI编程智能体，与传统的代码补全工具（如GitHub Copilot的行内补全模式）有本质区别。它采用"智能体循环"（agentic loop）架构：接收高层任务描述后，自主规划执行步骤，能够读取文件系统、执行终端命令、运行测试、修复错误，并在多轮迭代中自我纠正。这种架构的关键突破在于"工具使用"（tool use）能力——模型不仅生成代码文本，还能调用外部工具验证自己的输出。类似的工具还包括Cursor的Agent模式、Devin、以及基于OpenAI Codex的自主编程系统。这类工具将AI从"建议者"升级为"执行者"，这正是Simon所说的"放大器"效应的技术基础。

"目标是构建高质量的生产系统：如果你只是更快地构建低质量的东西，那是坏事。我要更快地构建更高质量的东西。"

令人不安的融合：从逐行审查到选择性信任

问题出在这里：随着编码智能体变得越来越可靠，Simon发现自己已经不再逐行审查AI写的每一行代码了——即使是生产级别的项目。

他举了一个具体的例子：让Claude Code构建一个JSON API端点，执行SQL查询并输出结果，它就是会做对。加上自动化测试、加上文档，你心里清楚它会处理得很好。但你确实没有审查那些代码。

这让他产生了真实的负罪感：如果我没有审查代码，把它直接用在生产环境中真的负责任吗？

用团队信任做类比

Simon找到了一个让自己稍感安慰的类比：在大型组织中，当另一个团队交付一个图片缩放服务时，你不会去读他们写的每一行代码。你看文档，用它缩放几张图片验证效果，然后就开始构建自己的功能。只有出了问题才会深入他们的代码库。

他开始以同样的方式对待AI智能体的产出。但不安依然存在——人类团队有专业声誉和组织问责机制作为担保，而Claude Code没有。

警惕偏差正常化的风险

Simon坦率地指出，这里存在"偏差正常化"（normalization of deviance）的风险。这一概念源自社会学家Diane Vaughan对1986年挑战者号航天飞机灾难的研究。她发现NASA工程师在多次发射中观察到O型密封圈的异常磨损，但由于每次都没有导致灾难性后果，团队逐渐将这种偏离设计规范的现象视为"可接受的正常状态"。这个概念后来被广泛应用于航空安全、医疗事故和软件工程领域。

在软件工程中，典型的偏差正常化包括：跳过代码审查但系统没有崩溃、忽略安全警告但没有被攻击、不写测试但功能看起来正常。每一次"侥幸成功"都在重新校准团队对风险的感知阈值，直到某次偏差恰好触发了灾难性的连锁反应。

回到AI编程的语境：每次模型在缺乏监督的情况下写出正确代码，都会让你在下一次更加放松警惕。日积月累，你在未来某个关键时刻过度信任AI的概率会越来越高。

这种渐进式的信任膨胀，恰恰是最难防范的工程风险。

AI时代如何评估软件质量

两种范式的融合带来了一个更深层的问题：我们该如何评估软件质量？

软件质量评估经历了多次范式转移。1970-80年代，质量主要通过形式化验证和代码行数衡量；1990年代，CMM（能力成熟度模型）引入了过程导向的质量观；2000年代，敏捷运动将"可工作的软件"置于文档之上；2010年代，DevOps文化强调部署频率、变更失败率等运维指标。如今，AI生成代码的时代正在催生又一次范式转移。

过去，一个拥有100次提交记录、完善README和自动化测试的GitHub仓库，通常意味着作者投入了大量心血和时间。现在，同样的东西半小时就能生成出来，外观和结构完全一样。

"即使是我自己的项目，我都分不清了。"

Simon得出了一个务实的结论：比起测试覆盖率和文档完整度，他更看重有人实际使用过这个东西。一个被真实用户日常使用了两周的Vibe Coding项目，比一个刚生成出来、几乎没有经过实际验证的精美项目更值得信赖。

这种观点与Netflix的混沌工程（Chaos Engineering）哲学一脉相承：系统的可靠性只能通过真实负载下的持续运行来证明，而非通过静态分析或测试覆盖率来推断。在AI生成代码的时代，传统代码审查假设审查者能理解代码的意图和上下文，而AI生成的代码往往缺乏这种可追溯的"意图链"，这使得实际运行验证的重要性被进一步放大。

换句话说，实际使用时长正在取代代码审查，成为新的质量信号。

软件开发的瓶颈已经转移

当代码产出从每天200行变成每天2000行，整个软件开发生命周期都需要重新设计——因为现有流程本质上是围绕"写几百行代码需要一天"这个假设构建的。

约束理论（Theory of Constraints，由Eliyahu Goldratt提出）指出，任何系统的整体产出都受限于其最薄弱的环节。在传统软件开发中，代码编写通常是主要瓶颈——这解释了为什么整个行业围绕它构建了代码审查、持续集成、Sprint规划等流程。当AI将编码速度提升一个数量级后，瓶颈必然转移到其他环节：需求澄清、架构决策、测试验证、安全审计、部署运维。这与制造业的历史经验高度一致——当CNC机床将加工速度提升10倍后，瓶颈转移到了设计、物料准备和质量检测环节。

瓶颈的转移不仅发生在下游的测试和部署环节，上游同样如此。Anthropic的设计负责人Jenny Wen指出：传统的设计流程之所以如此严格和保守，是因为设计错误意味着工程师要浪费三个月的开发时间。但如果构建成本大幅降低，设计流程也可以承受更大的试错空间。

这意味着AI编程工具不只是改变了"写代码"这一个环节，而是在重塑从设计到交付的整条链路。当下游瓶颈消失后，上游的保守策略失去了存在的理由，整条价值链都需要重新平衡。

为什么软件工程师的职业仍然安全

尽管Vibe Coding和Agentic Engineering的边界在模糊，Simon并不担心软件工程师的职业前景，理由有三个：

1. AI是经验的放大器，而非替代品：你掌握的工程知识越多，借助AI工具跑得就越快。新手和资深工程师使用同一个AI工具，产出的质量差距依然巨大。这里的关键在于，AI工具的有效使用需要开发者具备判断输出质量的能力——你需要知道什么是好的架构、什么是安全的实现、什么是可维护的代码，才能引导AI朝正确的方向工作，并在它偏离时及时纠正。
2. 软件开发本质上极其困难：即使有了所有AI编程工具，构建可靠的生产级软件仍然是"极其艰难"的事情，这一点没有改变。分布式系统的一致性问题、安全漏洞的防范、大规模系统的性能优化、遗留系统的迁移——这些挑战的复杂性远超单个代码片段的生成。
3. 用户需要的是经过验证的专业产品：正如政治评论员Matthew Yglesias所说，人们真正想要的不是自己Vibe Code出一个工具，而是专业软件公司用AI辅助做出更好、更便宜的产品。

对于"企业会用AI自建系统替代SaaS"的担忧，Simon的看法同样务实：没有企业会采用一个CRM系统，除非至少两家大型企业已经成功使用了六个月。经过真实场景验证的解决方案，永远有不可替代的市场价值。

结语：承认不适感本身就是专业性

Simon Willison的这番反思，揭示了AI编程工具发展中一个关键转折点：当工具足够可靠时，"负责任地使用AI"和"盲目信任AI"之间的界限变得越来越难以维持。

这不是一个已经解决的问题，而是每个使用Claude Code等AI编程工具的工程师都需要持续警惕的张力。偏差正常化不会发出警报，它只会在你毫无察觉的情况下一点点侵蚀你的判断标准。

承认这种不适感，或许本身就是保持专业性的一种方式。

核心要点

• Vibe Coding（不审查代码的AI编程）和Agentic Engineering（专业工程师的AI协作）两种范式正在融合，即使是资深工程师也开始不再逐行审查AI生成的代码
• 这种融合存在'偏差正常化'风险——每次AI正确完成任务都会降低工程师的警惕性，可能在关键时刻导致问题
• 评估软件质量的标准正在改变：实际使用经验比代码质量指标（测试覆盖率、文档完善度）更有价值
• 整个软件开发生命周期需要重新设计，因为代码产出速度的量级提升改变了上下游所有环节的假设前提
• AI工具是经验的放大器而非替代品，专业软件工程师的职业前景依然稳固