图源：Sequoia Capital 视频页面。
Karpathy 最近在 Sequoia AI Ascent 的一场炉边对话里，讲了一个很有意思的转折。
去年，他因为提出 “vibe coding” 这个词被很多人记住。大意是：你描述想要什么，让模型去写代码，你更多跟着感觉走，而不是逐行控制实现。
但这一次，他没有继续把话题停在"代码生成更快"上。
主持人问他，今天这个更严肃的阶段应该叫什么。他给出的区分很直接：Vibe Coding 是提高所有人做软件的下限；Agentic Engineering 是在专业软件里保住原有的质量线。
这句话很关键。
它不是在否定 Vibe Coding。相反，Vibe Coding 的价值很大：它让很多过去不会写软件的人，也能把想法变成可以运行的东西。
但专业工程的问题从来不只是"东西能不能跑"。
真正的问题是：它能不能长期维护？权限有没有漏洞？数据边界清不清楚？异常路径有没有处理？测试和日志能不能证明它可信？上线后出了问题，能不能回滚？
所以，从 Vibe Coding 到 Agentic Engineering 的变化，不是从"不用 AI"到"会用 AI"。
而是从"让模型把代码写出来"，进入"设计一套模型参与后仍然可验证、可审计、可负责的软件生产线"。
一、Karpathy 为什么说自己"从没这么落后过"
这场对话一开始，主持人提到 Karpathy 之前说过一句很反直觉的话：他从未像现在这样觉得自己作为程序员落后。
这句话从他嘴里说出来，分量很重。
他的解释是，去年底开始，他明显感觉到代码 Agent 的能力出现了一个跃迁。以前模型可以帮你写一些代码块，但你经常要改、要补、要纠错。后来某个阶段开始，它给出的代码块越来越完整，连续追加需求也能接住，他自己开始越来越信任这套系统。
于是，熟悉的那种 Vibe Coding 状态出现了：不断开新项目，不断让模型生成，不断把想法推向可运行状态。
这就是很多人最近的共同体验。
它不是"工具又快了一点"，而是工作方式突然变了。
过去，工程师卡在实现上。现在，很多实现突然不再卡了。
但问题也正从这里开始。
当实现成本下降，真正稀缺的东西会浮出来：判断、边界、验证和责任。
二、Vibe Coding 的危险，不是写错，而是"太顺"
很多人讨论 AI 编程风险时，第一反应是"它会写错"。
会，这当然会。
它会误解接口，会编不存在的依赖，会把一个边界条件处理得很潦草。但这些错误反而不是最危险的。明显的错，通常还能被看见；真正麻烦的是那些"看起来没问题"的代码。
页面能点，接口能通，测试过了一条 happy path，演示时也没翻车。于是我们很自然地接受了它。
需求里的歧义没有被澄清，权限边界没有被追问，异常路径没有被走一遍，日志、监控、回滚、审计也都先放一放。
团队得到了一种进度感，却不一定得到一个可交付的系统。
这才是 Vibe Coding 之后最值得警惕的变化：代码生成的速度变快了，人类接受"能跑"的速度也变快了。
Karpathy 在对话里还举了一个很典型的例子。他做一个菜单应用时，用户登录用的是 Google 账号，购买点数用的是 Stripe 账号，两边都有 email。结果 Agent 曾试图用 email 去关联资金账户。
这在人类工程师看来很危险：用户完全可能用不同邮箱登录和支付，资金账户不能靠 email 这种可变字段来绑定。
这个例子非常好，因为它不是语法错误。
它是工程常识错误。
代码可能能跑，流程可能能通，但底层身份模型是错的。
这就是 Vibe Coding 时代真正要警惕的地方：模型写出的不是"明显坏代码"，而是"局部合理但工程上荒唐的代码"。
三、Agentic Engineering 不是提示词技巧，而是质量线
资料来源：Andrej Karpathy 在 Sequoia AI Ascent 炉边对话中的公开讨论。
Karpathy 对 Agentic Engineering 的定义，核心不是"让 Agent 写更多代码"。
他的重点是：这些 Agent 很强，但也很尖锐、随机、局部能力极高。问题是，如何协调它们，让速度上去，同时不牺牲专业软件的质量线。
这句话把讨论从"提示词"拉回了"工程"。
提示词当然有用，但它不是护城河。真正的护城河是：你能不能定义目标，写清约束，拆出边界，设计验证，审计结果，并承担最终责任。
换句话说，AI 越会写代码，工程师越要把注意力从代码本身，移到代码周围的工程系统上。
你要补的不是更多模板，而是三种治理动作。
第一，Spec-first。
先写清楚"什么算做完"。一个好的规格，不只是功能描述，还要说明目标、非目标、不变量、失败模式和验收标准。你不写，模型就会替你默认。每一个默认值都可能变成未来的技术债。
第二，Evidence-first。
别问"做完了吗"，要看证据。改了哪些文件，跑了哪些测试，哪些路径覆盖了，哪些没有覆盖，日志和监控看到了什么，安全边界有没有变化。没有证据的完成，只是一个态度；有证据的完成，才是工程状态。
第三，Adversarial Validation。
不要只证明它能跑，还要主动证明它哪里会坏。脏数据、并发请求、权限绕过、重复提交、旧版本迁移、异常回滚，这些都要提前被拉到桌面上。
AI 让 happy path 更容易出现，工程师就更要负责 unhappy path。
四、Karpathy 真正强调的人类能力
主持人问 Karpathy：当 Agent 做得越来越多，什么人类技能会更值钱？
他的回答不是"写代码速度"。
而是 aesthetics、judgment、taste，以及 oversight。
换成中文，就是审美、判断、品味和监督。
这几个词听起来很软，但落到工程里其实很硬。
审美不是代码漂不漂亮，而是你能不能闻到复杂度的坏味道。
判断不是拍脑袋，而是你能不能区分哪些决策可逆，哪些决策不能随便交给模型。
品味不是风格偏好，而是你能不能看出一个抽象是不是过早，一个边界是不是稳定，一个方案是不是用局部简单换来了全局复杂。
监督也不是盯着模型干活，而是让它的产出进入一套可验证的系统。
这才是 Agentic Engineering 的核心。
它不要求工程师亲手敲每一行代码，但要求工程师更懂什么是好系统。
五、可以外包思考，不能外包理解
这场对话最后，Karpathy 提到一句他很喜欢的话：你可以外包 thinking，但不能外包 understanding。
这句话几乎可以作为整个 Agentic Engineering 的底线。
你可以让工具帮你生成方案、实现功能、解释报错、写测试、跑实验。
但你不能不知道自己在建什么，为什么值得建，边界在哪里，风险在哪里，什么情况下应该停下来。
如果你不理解系统，你就无法指挥 Agent。
如果你无法指挥 Agent，速度越快，风险越大。
这也是为什么工程师的价值不会因为代码生成变快而消失。它只是换了位置。
以前，你主要负责把逻辑敲进编辑器。
现在，你更像一条软件生产线的总架构师：决定什么进入生产线，什么被挡在门外，什么必须重新做，什么可以发布。
结尾
Karpathy 这场对话真正值得记住的，不是又出现了一个新名词。
而是他把 Vibe Coding 和 Agentic Engineering 的边界划得很清楚：前者提高下限，后者守住质量线。
Vibe Coding 不会消失，也不应该被嘲笑。它确实让创造变轻了，让很多想法更快落地。
问题是，原型跑起来，不等于系统可交付；功能出现了，不等于责任完成了。
接下来更成熟的工作方式，应该从"让模型多写一点"转向"让工程更可信一点"。
Spec-first 让目标和边界先于代码出现；Evidence-first 让完成必须带着证据；Adversarial Validation 则提醒我们，不要只验证系统怎样能跑，还要主动寻找它怎样会坏。
提示词能让你更快得到代码。
工程治理才决定你敢不敢把它交出去。