Karpathy@Sequoia Ascent 2026：Software 3.0 来了，程序员变成 Agent 编排者

Sequoia Ascent 2026 上的 Karpathy：Software 3.0 元年

2026 年 4 月 30 日，Karpathy 在 Sequoia Ascent 2026 跟 Stephanie Zhan 做了一场炉边对话。视频在 YouTube 已经 372K views，Karpathy 自己用 Codex 5.5 把 transcript 清洗后做了一篇 blog 总结——既给读者看，也给 LLM 喂。

这篇 blog 是 Karpathy 自己审过的，他说「reads ok without glaring mistakes」。我们以下基于这篇做精读。

一、2025 年 12 月：agentic 拐点

Karpathy 说他最近从未感觉自己作为程序员这么「掉队」。不是编程变难了，是默认 workflow 变了。

• 2025 年大半年时间，Claude Code、Codex、Cursor 这些工具有用但还要频繁纠错
• 2026 年 12 月左右开始，他感到 step change：生成的代码块更大、更连贯、更可靠
• 「我开始把更多工作交给 agent」

编程的最小单位从「敲代码」变成了「委托宏指令」：

Implement this feature. Refactor this subsystem. Research this library. Set up this service. Write tests, run them, and fix failures. Compare approaches and propose a plan.

程序员的角色被重写——从代码作者变成 agent 编排者。

二、Software 3.0：上下文窗口就是新的程序

Karpathy 把演化序列写清楚：

• Software 1.0：人写显式代码
• Software 2.0：人造数据集 + 目标 + 神经网络，程序学进权重
• Software 3.0：人通过 prompt、context、tools、examples、memory、instructions 编程 LLM

LLM 是上下文之上的「解释器」，对数字信息做计算。

他举的最直观例子：安装。 旧世界要写一个 brittle shell script 处理各种环境差异；Software 3.0 时代，installer 是一段你贴给 agent 的说明文字——agent 读环境、debug、适配、装完。

这是另一种程序：没那么精确，但更适应。

三、MenuGen 案例：有些 app 应该不再作为 app 存在

Karpathy 用 MenuGen 讲了更深的转变。

MenuGen 原本是一个传统 web app：拍菜单 → OCR 出菜名 → 生成图 → 渲染 UI。需要前端、API、图像生成、部署、auth、payment、secret、infrastructure。

但 Software 3.0 版本是：拍菜单 → 给多模态模型 → 让它直接在菜单图上画出菜品。

In that version, much of the app disappears.

原本的 software stack 是给「现在模型能直接做的事」搭的脚手架。这是给 founder 最重要的提醒：AI 不只是更快做老 app，有些 app 应该不再存在为 app。

四、新机会不是「更快编程」

更广的转变在「LLM 自动化以前不能编程的信息处理」。

他自己的 LLM Wiki pattern 是最清晰的例子：传统 RAG 是每次查问题都从原始 doc 里检索；他做的是 agent 增量地把原始材料编译成持久 markdown wiki——summary、entity 页、concept 页、矛盾点、cross-link、log、不断演化的综合。

No classical program could robustly maintain that kind of knowledge base across messy human documents. But an LLM can.

问题不只是「哪个 workflow 能 AI 加速」，更要问「哪个信息转换以前不可能、现在自然了」。

五、Verifiability 决定 AI 在哪里飞

Karpathy 的核心自动化框架：

• 传统软件自动化能 specify 的事
• LLM + RL 自动化能 verify 的事

如果一个任务有自动 reward 或 success 信号，模型就能 practice。这就是数学、编程、benchmark、游戏、很多工程任务进步飞快的原因——它们 resettable、repeatable、rewardable。

这也解释为什么 coding agent 体感比一般 chatbot 强很多——coding 给模型反馈：test 过没过、程序跑没跑、diff 能不能看、benchmark 能不能测。

六、Jagged Intelligence：两个轴

Karpathy 在这次访谈中给 verifiability 论加了一层补丁：

模型能力不仅取决于任务能不能 verify，还取决于这个任务在 lab 里被多用心训练。

粗略公式：

``` capability spike ≈ verifiability × 训练关注度 × 数据覆盖 × 经济价值 ```

国际象棋是好例子。GPT-4 在棋上的提升，未必是「智能均匀提升了」，而可能是「训练数据里塞了更多棋」。

这意味着——前沿模型没有 manual。 它们是 pretraining 配方、RL 环境、benchmark 压力、产品优先级、经济激励的产物。它们在某些领域 spike，在另一些领域奇怪地烂。

创始人的实操问题是：Are you on the model's rails？

• 如果你的任务在「verifiable + 高训练关注度」区间，模型可能飞起来
• 如果不在，它可能在意想不到的简单事上失败
• 这种情况你需要更好的 context、tool、fine-tuning、自己的 eval、自己的 RL 环境

七、Vibe coding vs Agentic Engineering

Karpathy 划了清楚的边界：

• Vibe coding 抬地板——让几乎所有人都能描述自己想要什么然后造出来
• Agentic engineering 提天花板——是协调 fallible agent 同时保留 correctness/security/taste/maintainability 的专业纪律

Vibe coding 适合原型和个人工具；agentic engineering 是 serious team 需要的。

Agentic engineer 不会盲目接受 generated code。 他们写 spec、监督 plan、查 diff、写 test、造 eval loop、管权限、隔离 worktree、保质量。

MenuGen 的支付 bug 是反例：agent 用 email 来 match Stripe 购买和 Google 登录。代码看起来 plausible，但系统设计差——Stripe 邮箱和 Google 邮箱可能不同。人需要足够的产品和工程判断力，坚持用持久 user id。

前沿技能不是记每个 API 细节（agent 自己记 dim/axis/keepdim/reshape/permute）。人还需要懂 storage、view、memory copy、invariant、identity、security boundary 这些底层概念。

八、招聘应该改变

传统 coding puzzle 越来越不匹配。

更好的面试是：用 agent 造一个 substantial 项目，部署、加固，然后让 adversarial agent 试图攻破。

这真正测试的是：

• 候选人能不能把工作分解给 agent？
• 能不能写有用的 spec？
• 能不能保持质量同时高速？
• 能不能 review 生成的工作？
• 能不能加固系统？
• 能不能把 agent 当杠杆而不是产生 slop？

The old "10x engineer" idea may become much more extreme.

掌握 agentic workflow 的人，可能远不止 10x outperformance。

九、创业 wedge：找有价值的 verifiable 环境

创业者最重要的机会，是找「价值高 + verifiable + lab 训练不够」的领域。

如果你能给某个垂直领域造一个 environment——模型能 try action、得到可靠 reward——你就能用 fine-tuning 或 RL 提升性能，即使 base model 在这领域不出色。

最显眼的领域（coding/数学）已经被 lab 重投。但很多经济上重要的领域有潜在的 verifiable 结构未被开发。

这就是 startup wedge。

十、Agent-native 基础设施

大部分软件还是给「人点屏幕」造的。Doc 说「打开这个 URL，点这个按钮，开这个设置面板」。

但 user 越来越不是直接的人——是人的 agent。

产品需要 agent-native surface：

• Markdown 文档
• CLI
• API
• MCP server
• 结构化 log
• 机器可读 schema
• 可粘贴的 agent 指令
• 安全权限
• 可审计的 action
• Headless setup

Karpathy 用 sensors / actuators 框架思考：sensor 把世界状态变成数字信息；actuator 让 agent 改变某个东西。未来的 stack 是 agent 代表人和组织使用 sensor 和 actuator。

MenuGen 的部署故事是 benchmark：写代码容易，配 Vercel/auth/payment/DNS/secret 痛苦。成熟的 agent-native 世界里，应该可以说「build MenuGen」然后 agent 自己部署完整。

十一、Ghosts，不是 Animals

Karpathy 反复强调：LLM 不是动物。 它没有生物驱动、具身生存压力、好奇心、玩耍、内在动机。它是人类制品的统计模拟，被 pretraining、post-training、RL、产品反馈、经济激励塑造。

这意味着——拟人化预期会误导我们。这些系统一刻聪明、一刻蠢得离谱。 它们不是平滑的人类心智，是 jagged 的、外星的工具。

正确的姿势既不是 dismiss 也不是盲信——是 empirical familiarity：知道它们在哪儿能 work、在哪儿失败、训练里都有什么、怎么搭 guardrail。

十二、教育：可以外包思考，不能外包理解

Karpathy 反复回到一句：

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

哪怕 agent 做更多事，人还需要 understanding 来 direct——你需要知道什么值得造、什么问题重要、什么结果可疑、什么 trade-off 可以接受。

他对自己的 LLM Wiki 工具尤其热情：「每次我看到对信息的不同投影，就感到获得了 insight。这是对固定数据做合成数据生成。我读文章时，我的 wiki 在自动构建——我喜欢对它问问题。」

Tools that enhance understanding are incredibly interesting and exciting. Understanding is still the bottleneck because you cannot be a good director if you do not understand.