最近关于 AI 编程的讨论，已经从“会不会写代码”慢慢转向“怎么把一个不稳定的智能体，放进可控的工程系统里”。
Andrej Karpathy 在 Sequoia AI Ascent 的这场对谈，刚好把这个变化讲透了。他这次不是重复去年的 vibe coding，而是在补一条更硬的判断：真正稀缺的，不再是代码本身，关键在于你能不能设计出一套让 agent 持续工作、持续校验、又不把系统搞坏的运行方式。原视频：https://m.youtube.com/watch?v=96jN2OCOfLs&ra=m
这次视频在讲什么
如果只用一句话概括，这场分享讲的是：vibe coding 已经把写代码这件事的门槛压低了，但真正值钱的部分，正在往 agentic engineering 迁移。
Karpathy 把两者区分得很清楚。vibe coding 是抬高下限。不会写太多代码的人，也能借助模型快速做出 demo、脚本和小工具。它像一台能力放大器，把“试试看”的成本打到很低。
但 agentic engineering 抬高的是上限。你不能因为 agent 会写代码，就把质量、安全、架构和边界判断一起外包出去。专业工程还在，只是重心变了。人从“亲手写每一行”变成“设计任务、组织上下文、设置验证、守住质量线”的角色。
这个判断和我之前记录过的一条结论是一致的：vibe coding 提高下限，agentic engineering 提高上限，真正越来越贵的是 understanding，thinking 可以外包，understanding 还不行。
software 3.0 不是更快写代码，是换了编程对象
这期对谈里最有意思的一段，不是泛泛讲 agent，而是 Karpathy 又把 software 1.0、2.0、3.0 这套分法往前推了一步。
software 1.0 是手写规则。software 2.0 是用数据集和训练目标去“编程”神经网络。到了 software 3.0，编程的杠杆变成 prompt 和 context window。你给模型的上下文，本身就是程序的一部分。
他说得很直白：现在很多“程序”其实不应该再长成传统 app。比如安装 OpenClaw 这种事情，旧思路会想写一份越来越复杂的 shell 脚本，覆盖不同操作系统、不同依赖、不同环境差异。新思路是把安装过程写成一段给 agent 的说明文字，让 agent 自己观察环境、调试错误、完成 setup。
这里的变化，不只是“自然语言也能编程”这么浅。更深的一层是：程序不再总是要求你把所有分支条件提前写死。你可以把一部分环境理解和局部决策，下放给模型在运行时处理。
这也解释了为什么很多人还在用旧范式做新东西。表面看是在“用 AI 加速开发”，其实只是让模型帮你更快地生产旧世界的脚手架。Karpathy 想说的是，真正的机会往往在那些过去根本做不出来、或者不值得做的东西上。
MenuGen 例子真正打到的，不是效率，是中间层会消失
视频里最有代表性的例子，是他拿自己做过的 MenuGen 来做对照。
MenuGen 的初版，是一个很典型的软件工程作品：拍一张菜单照片，OCR 识别菜名，再去生成每道菜的大致图片，最后重新渲染一个带图菜单。这套东西能跑，也挺有产品感。
但 Karpathy 后来看到另一种做法：直接把菜单图片交给 Gemini，再让模型把对应菜品图像直接叠到菜单图里。也就是说，输入就是图片，上下文还是图片，输出还是图片，中间那个 app 层几乎被吃掉了。
他被震到的点，不是“模型真强”，只是“我原来那套程序可能根本就不该存在”。
这个例子很关键，因为它不是在鼓吹“少写代码”这么简单，而是在提醒一件更难接受的事：以后会有越来越多过去看起来合理的中间软件层，只是过渡形态。它们曾经存在，是因为模型不够强、输入输出之间需要大量手工搭桥。等模型能直接跨过去，这些桥就会被拆掉。
很多旧式软件，本质是把信息从 A 搬到 B，再在中间做一层固定格式转换。只要模型已经能直接对原材料做重编译、重组织、重投影，中间那层“应用壳”就未必还站得住。
可验证性依然是最硬的现实边界
Karpathy 这几年一直在讲 verifiability，这次也没变，而且讲得更直白了。
他的核心判断还是那个：传统计算机擅长自动化“你能写成代码明确指定的事”；今天的 LLM 更擅长自动化“你能验证对错的事”。代码、数学、部分结构化任务之所以跑得快，不是因为模型天然理解了世界，而是因为这些任务容易形成奖励信号，容易做强化学习，也容易自动判分。
这个判断一直很硬。如果你所在的领域是可验证的，就算大模型厂商没替你把那条赛道做到极致，你自己也有机会通过 RL 环境、数据和微调把它做出来。
反过来，如果一个场景远看像能自动化，近看却没有稳定验证方式，那它就很容易停在 demo 层。它看起来聪明，但不可靠，也就不适合真正托管关键任务。
所以这场视频真正给团队的提醒，不是“赶紧 all in agents”，而是更朴素的一句：先找那些你能验收、能打分、能回滚的环节，把 agent 放进去。别把最模糊、最难定义成功标准的工作，一上来就全压给它。
jagged intelligence 解释了为什么 agent 既神又蠢
Karpathy 还花了不少篇幅解释一件很多人都有直觉、但说不清的事：为什么同一个模型，一会儿像天才，一会儿像傻子。
他现在更喜欢用 jagged intelligence 这个视角来看。模型在某些回路里能力非常突出，尤其是代码、数学、可验证任务；但一旦离开训练重点和奖励重点，能力就会突然塌陷，甚至在很普通的常识问题上出错。
他现场举的例子就很有代表性：模型可以帮你重构超大代码库，甚至找出零日漏洞；但问它“洗车店离我 50 米，我该走路还是开车”，它可能一本正经建议你走过去。
这不是一个搞笑插曲，反而是 agentic engineering 必须面对的前提。只要智能还是锯齿状的，你就不能把模型当成完整、均匀、稳定的通用理性体。你得先承认它有高光区，也有塌陷区，然后围绕这个前提设计系统。
这也是为什么 agentic engineering 不是“会用几个 AI 工具”那么轻。它更像一种防事故工程：你不是假设 agent 全程可靠，而是假设它很强，但会在你想不到的地方突然犯错，于是把验证、隔离、回退和审查都先铺好。
人的角色没有消失，只是从 API 细节转向判断与规格
视频后半段有一段我觉得特别重要。Karpathy 明说，现在越来越多 API 细节他已经懒得记了，比如 keepdim 还是 keepdims、dim 还是 axis、reshape 和 transpose 的细枝末节。这些东西可以交给“实习生级别”的 agent 处理。
但他也同时强调，理解并没有被外包出去。
你还是得知道底层是不是同一块 tensor storage，哪些操作会额外拷贝内存，系统里的唯一用户 ID 应该绑在哪里，为什么 Stripe 邮箱和 Google 邮箱不能拿来当同一个用户身份。这些不是文档细节，而是结构判断。
AI 正在接管大量实现细节，但规格、判断、审美、取舍和最终责任没有消失。恰恰因为执行变便宜了，这些高层能力反而变贵了。
所以未来的强工程师，未必是记得最多 API 的人，而更像是一个高带宽的技术导演：能定义问题、设计 spec、分配上下文、审查产出、把一群不稳定但高能力的 agent 组织成可靠系统。
agent native 世界的真正变化，是文档开始写给 agent 看
这期视频还有一个容易被忽略、但其实很有后劲的判断：未来很多基础设施都要变成 agent native。
Karpathy 吐槽现在的大量文档还是写给人看的。他最烦的一件事，就是文档还在告诉他“你去这个 URL，点那个菜单，再配这个参数”。他的反问很直接：为什么还在告诉我怎么做？我不想做。你直接告诉我，哪段文字该复制给 agent 就行。
这背后其实不是一句玩笑，而是一条产品设计原则在变：过去我们优化的是 human-readable interface，现在开始要优化 agent-readable interface。
如果这条判断成立，很多文档系统、运维系统、SaaS 配置流、权限系统、甚至组织内部协作接口，都会慢慢从“给人看懂”转成“让 agent 能调用、能理解、能执行、能验证”。
这和最近越来越多 agent 系统在做的事情是一致的：重点已经不是堆一个更花哨的聊天界面，而是在把外部资料、历史偏好、当前任务和执行脚本，拼成一个 agent 能持续工作的运行环境。
这次视频对我们的启发
如果把这期视频放回最近这一波 AI 工程演进里看，我觉得至少能收敛出四个判断。
第一，vibe coding 还会继续扩散，但它更像普及层，不是竞争壁垒。让更多人做出东西，会让“会不会做 demo”迅速贬值。
第二，真正值钱的是 agentic engineering：把高能力但锯齿状的模型，装进有验证、有边界、有记忆、有回滚的工程系统里。
第三，软件形态会继续扁平化。一批旧式中间层 app 会被吃掉，新的机会更可能来自“直接围绕模型输入输出重设计流程”，而不是给旧系统再包一层 AI 功能。
第四，理解会继续升值。理解用户、理解任务、理解约束、理解上下文、理解组织目标，这些不会因为模型更强而消失，反而会因为执行成本归零而被重新定价。
我的补充
我觉得这场对谈最值得记住的，不是某个新词，而是它把 AI 编程的分水岭说得更清楚了。
前一阶段，大家最兴奋的是“模型终于能写代码”。下一阶段，更关键的问题会变成：你能不能围绕这类不稳定但高能力的系统，搭出一套长期可用的工程环境。
如果不能，AI 只是帮你更快地产生更多半成品。
如果能，软件团队的组织方式、文档方式、知识方式、验证方式，都会一起改写。
到那时候，代码当然还重要。但它已经不是最稀缺的东西了。