Karpathy 最新判断：Vibe Coding 没死，Software 3.0 正在分出 Agentic Engineering

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 167 篇，AI 编程最佳实战「2026」系列第 53 篇 大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。 我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！ Talk is cheap, let's explore。无界探索，有术而行。

Karpathy 与 Software 3.0、Vibe Coding、Agentic Engineering 关系图

2025 年 2 月，Karpathy 给 Vibe Coding 起了名字。2025 年 6 月，他系统阐述 Software 3.0。到了 2026 年，他又用 Agentic Engineering 指代专业开发中的另一套纪律。

三者并非互相替代的新名词。Software 3.0 是编程范式，Vibe Coding 是低门槛、低监督的特殊工作方式，Agentic Engineering 则是在这套范式中交付专业软件的工程纪律。理解 Karpathy 近期的判断，得先看清这条关系。

1. Karpathy 为什么此时值得听

先把容易传播错的时间线理顺。

Sequoia AI Ascent 举办于 2026 年 4 月 20 日。Karpathy 在那场对话中重述了 Software 3.0，也划清了 Vibe Coding 与 Agentic Engineering 的边界。

一个月后的 5 月 19 日，他才宣布加入 Anthropic。那场对话发生在入职前，后来因为职业动态再次受到关注。

公开信息显示，他加入 Anthropic 的预训练团队，并将组建一个用 Claude 加速预训练研究的小组。

现有资料不足以支持他领导整个预训练团队，更不能外推成由他决定下一代 Claude 的方向。

这个动态仍有信号价值。Karpathy 参与过 OpenAI 的早期研究，也曾负责 Tesla 的 AI 工作。后来，他持续通过演讲、课程和个人文章解释 LLM。

他长期穿梭于研究、教育和实际开发，讨论 AI 编程时自然多了一层现场感。

更关键的是，他的判断有一条连续的事实链。2017 年提出 Software 2.0，2025 年命名 Vibe Coding、阐述 Software 3.0，2026 年又把专业开发从原始 Vibe Coding 中单独拎出，暂称 Agentic Engineering。

这条概念线一直在修订同一个问题：模型能力上升后，软件工作该怎样分层。

来源：

• Sequoia AI Ascent 2026：https://sequoiacap.com/article/ai-ascent-2026
• Karpathy 的 AI Ascent 辅助转录：https://karpathy.bearblog.dev/sequoia-ascent-2026
• Karpathy 加入 Anthropic 的原帖：https://x.com/karpathy/status/2056753169888334312

2. Software 3.0 先换了编程对象

理解这次分叉，得先回到总框架。

Software 1.0 编写明确规则，程序员把逻辑写进代码。Software 2.0 配置数据、目标函数和网络，训练过程把行为压进权重。

Software 3.0 再往前走一步：开发者用 prompt、上下文、示例、工具、记忆和指令去编程一个 LLM。

Karpathy 在 2025 年的 YC 演讲里把 prompt 直接称为程序。2026 年，他又强调 context window 是操纵这个 LLM 解释器的重要杠杆。

换句话说，Software 3.0 的产品对象不再只是页面和业务规则。产品还要决定给模型看什么、允许它调用什么、怎样反馈结果，以及何时把控制权交还给人。

MenuGen 很能说明这次变化。2025 年的版本是一套完整 Web App，原型代码由 Cursor 和 Claude 生成。

到了 2026 年，Karpathy 展示了另一条路线：直接把菜单图片交给多模态模型，让模型在原图上补出菜品图。

对于这个输入到输出的任务，原来的 OCR、页面交互和部分中间服务，更像模型能力成熟前的脚手架。

但 Software 3.0 没有清空前两种范式。身份、支付、权限、账务和审计仍适合确定、可追踪的 Software 1.0；底层模型仍来自 Software 2.0；自然语言交互与 agent 编排才落在 3.0。

产品经理真正要问的是：这项用户任务该落在哪种编程范式里？

来源：

• Software 3.0 演讲：https://www.youtube.com/watch?v=LCEmiRjPEtQ
• MenuGen 复盘：https://karpathy.bearblog.dev/vibe-coding-menugen/

Software 1.0 2.0 3.0 编程范式关系图

图 1：Software 1.0、2.0、3.0 不是替代关系，而是面向不同编程对象的分层组合

3. Vibe Coding 没死，专业开发分出来了

2025 年 2 月 2 日，Karpathy 描述 Vibe Coding 时很具体：用语音下指令，不读 diff，接受 agent 的改动，报错就贴回去，甚至忘掉代码本身。

这套做法服务于一个很窄的待办任务：用很低的启动成本，把一个念头尽快变成能运行的东西。它不负责维护一套可靠系统。

它确实抬高了下限。不会系统编程的人也能做个人工具、演示和一次性脚本；专业开发者则能更便宜地试错。

若需求还在探索期，每次实验都先写完整规格、测试和审查流程，路径就太重。灵感往往先被流程耗掉。

问题出在失败成本变化之后。

MenuGen 的原型很快，接上真实用户后却撞上认证、支付、部署、密钥和生产配置。

一个典型错误是把 Stripe 邮箱与 Google 登录邮箱当成身份关联依据，而没有使用持久用户 ID。代码看起来合理，系统设计却埋了雷。

Karpathy 当时的结论也很克制：对真正重要的 Web App，照原始含义一路 vibe 下去并不是好主意。

于是，2026 年 2 月，他用 Agentic Engineering 暂称专业工作流：agent 承担代码生成，人负责规格、编排、监督、审查和结果。

4 月的 AI Ascent 上，他把差别压缩得很清楚：Vibe Coding 抬高下限；Agentic Engineering 保住专业软件的质量线，并把能力上限继续推高。

这里要划一道事实边界：分叉是基于多处一手材料的解释性概括，并非 Karpathy 的逐字原话。他也没有宣布 Vibe Coding 已死。他做的，是把专业级 AI 编程从原始含义中分离出来。

两条路线的产品取舍也很直白。Vibe Coding 为了速度，牺牲代码理解和过程监督。相较原始 Vibe Coding，Agentic Engineering 把规格、评审和验证接回流程，目标仍是在不牺牲质量的前提下获得速度杠杆。

分界线不只是 Prototype 与 Production 两个标签。维护周期、失败成本、责任归属和风险暴露，才是实际边界。

来源：

• Vibe Coding 原帖：https://x.com/karpathy/status/1886192184808149383
• Agentic Engineering 回顾帖：https://x.com/karpathy/status/2019137879310836075

Vibe Coding 与 Agentic Engineering 风险边界

图 2：失败成本上升时，工作方式从 Vibe Coding 切换到 Agentic Engineering

4. AI 为什么不能一路只管 vibe

这套工程纪律并非源于对 agent 缺乏信心。它源于一个更准确的判断：模型的能力并不平滑。

Karpathy 用过两个互相补充的说法。一个是 Ghost 而非 Animal：前沿 LLM 主要从互联网中的人类文本痕迹学习，像被召唤出的文字幽灵。它并非靠身体、环境和连续经验长大的动物。

另一个是 Jagged Intelligence，也就是锯齿状智能：模型能处理大型代码库或漏洞任务，却会在普通常识上犯低级错误。

AI Ascent 的洗车例子很扎眼。模型可以在复杂编码任务上表现出很强的能力，却建议用户步行去 50 米外的洗车店。它忽略了用户去洗车本来就要把车开过去。

问题不只是能力不足。模型能力不会像人的常识那样平滑迁移。

这对产品设计有一个直接后果：不能按模型表现好的任务，推断它在相邻任务上也可靠。

写出认证代码，不等于理解身份系统；生成支付接入，不等于理解退款、争议和资金责任；完成界面，也不等于知道真实用户会怎样误操作。

Vibe Coding 在低风险场景里可以容忍这种锯齿，因为产物能抛弃。

Agentic Engineering 面对的是另一张损失函数：漏洞、错账、数据泄露和错误决策，都可能由真实用户承担。监督因而成了产品责任的一部分。

来源：

• Animals vs Ghosts：https://karpathy.bearblog.dev/animals-vs-ghosts/
• Jagged Intelligence 原帖：https://x.com/karpathy/status/1816531576228053133

5. 可验证性只是支撑，不是主命题

Agentic Engineering 要保住质量，当然需要测试、审查和反馈回路。

Evals 或黄金任务集可以放进这里，但它们只是工程纪律中的一件工具，不是 Software 3.0 的全部，更不是 Karpathy 这轮判断的主命题。

可验证性解释的是：哪些任务适合给 agent 更高自主度。代码能编译，测试能运行，环境能重置，结果能比较，模型就有机会多轮尝试并修正。

反过来，品牌判断、伦理取舍、隐含业务状态和开放式策略很难得到快速而可靠的反馈。此时，人就该缩短委托链路，增加检查点。

不过，把 verifiability 写成决定能力边界的单一变量，也会失真。Karpathy 在 2026 年的表述里补充了另外几项：实验室是否投入训练、数据是否覆盖，以及任务有没有足够的经济激励。

一个任务即便容易验收，如果训练体系从未认真覆盖，模型也未必擅长。一个任务很有价值，但结果难反馈，同样不适合贸然放权。

对产品经理而言，自主度设置应该看一组条件，不能迷信一套 Eval 看板。结果能否验证、失败是否可逆、模型是否见过相似分布、业务损失有多大、责任由谁承担，这些条件要放在一起看。

验证系统服务于责任分配，不能反过来冒充产品本身。

来源：Karpathy 的 Verifiability 文章：https://karpathy.bearblog.dev/verifiability/

6. 人类能力要从使用力转向理解力

当代码生成越来越便宜，人的价值不会停留在会不会写 prompt。

Karpathy 在 AI Ascent 引用并认同了一句话：

You can outsource your thinking, but you can't outsource your understanding.

这句话不是他的原创名言。他明确说，这是近期看到的一条 tweet。

但他借此点中了 Agentic Engineering 的责任核心：思考过程可以委托，理解不能转交。

理解不要求人把 agent 的每一行代码重新手写一遍。Karpathy 举过 tensor 的例子：具体 API 名称可以忘，storage、copy 与 view 等底层概念仍要懂。

映射到产品工作，也是同一个道理。页面怎么搭、SQL 怎么写，可以交给 agent。

但用户身份如何贯穿系统、资金怎样流动、权限在哪里收口、失败后如何恢复，产品负责人不能只看演示结果。

这会重估三类能力：把模糊意图写成可检查规格，识别业务与技术的硬边界，以及在模型给出流畅答案时继续追问因果。

工具操作会折旧，对用户、系统和失败语义的理解反而更值钱。

7. 产品经理该改哪几件事

Software 3.0 带来的工作变化，不是给原流程加一个 AI 按钮。产品经理至少要重排下面几项优先级。

先判断产品是否还需要存在。面对新的模型能力，需求评审应该增加一个问题：用户雇佣产品完成的是整套流程，还是某个输入到输出的变换？

如果模型能直接完成后者，中间 UI 和服务就该缩减。可身份、支付、权限等确定性模块，别为了 3.0 的叙事硬删。

把 Demo 与可交付状态分开。原型跑通只能说明价值假设有信号，不能代表身份、数据、安全、恢复和维护已经过关。

项目节点至少要写清楚：当前是在验证需求，还是准备让真实用户承担后果。这个默认值不改，Vibe Coding 的速度会被错误记成产品成熟度。

按风险配置 agent 自主度。可重置、可自动验收、失败可逆的任务，可以给更长链路。

涉及资金、隐私、安全或含混业务规则的任务，要缩短步骤并设置人工签字点。Evals 放在这里，作为反馈工具使用。

评审 agent 的工作契约。本文给产品团队的实践建议是：明确输入规格、agent 编排、权限边界、测试反馈、审查和最终责任。

否则，团队只是把不受控的个人 vibe 放大成组织级风险。

这套重流程不适合所有项目。低风险个人工具往往不需要完整评审；高风险原型即使不进生产，也可能需要安全约束。

流程轻重应跟着失败成本走，项目名称说了不算。

Ghost 与 Jagged Intelligence 监督决策图

图 3：模型能力呈锯齿状分布，agent 自主度必须同时服从验证、可逆性、风险与责任

8. 回到 Karpathy 的那条主线

把时间线串起来，Karpathy 的判断其实相当稳定。

Software 3.0 让自然语言、上下文和工具调用成为新的编程材料；Vibe Coding 用这些材料降低软件创作门槛；Agentic Engineering 则把规格、验证、审查和责任重新接回专业开发。

加入 Anthropic，让他从公共解释者回到前沿 R&D，也让这套判断多了一层现实背景。

但能确认的只有：他加入预训练团队，并组建用 Claude 加速预训练研究的小组。至于后续研究会怎样影响模型与工程工作流，还没有公开答案。

眼下更有用的结论很具体：原型阶段可以借 Vibe Coding 换速度。进入真实责任场景后，就要切换到 Agentic Engineering。两者都属于 Software 3.0，却服务于不同的失败成本。

Vibe Coding 没有消失。该消失的，是拿原型速度冒充工程成熟度的侥幸。

说明：本文基于 Andrej Karpathy 的公开演讲、个人文章、社交媒体原帖，以及 Sequoia AI Ascent 和 Anthropic 相关公开信息分析整理，并对参考文章中的时间线、观点归属和概念表述进行了交叉核验。Software 3.0、Vibe Coding 与 Agentic Engineering 仍在快速演进，部分“分叉”表述属于本文依据一手材料作出的解释性概括，并非 Karpathy 的逐字原话。文中的配置模板和参数建议仅供参考，实际效果请以你的业务数据和环境测试结果为准。如果你正在实践 AI 编程工作流，欢迎分享真实经验和不同判断。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！