Karpathy Says AI Models Shift Software Development to Context Management

Karpathy：AI模型正将软件开发转向上下文管理 工程师必须从手动编写语法转向指导可能出错的AI智能体，倚重高层次的架构品味与深厚的系统理解，而非日常例行编码。 Andrej Karpathy反思了AI编程工具的快速演进，梳理了从“氛围编码”（vibe coding）向更为规范的“智能体工程”（agentic engineering）的转变。他指出，Software 3.0颠覆了计算架构，将神经网络作为解释上下文的主要宿主进程，而非依赖厚重的传统代码栈。尽管模型能力实现了巨大飞跃，但由于强化学习（RL）验证机制的限制，当前模型表现出极端的“能力参差”（jaggedness），虽擅长复杂的代码重构，却欠缺基础物理直觉。因此Karpathy认为，虽然智能体能够处理机械性的语法和执行，人类开发者仍必须保留核心的概念理解、架构品味与高层次的判断力。 随着模型可靠性在12月迎来关键拐点，多步骤代码生成几乎无需人工干预即可正确运行，Karpathy 的个人工作流也全面转向纯粹的“氛围编程”（vibe coding）。 (0:00) 在“软件 3.0”时代，大语言模型充当可编程计算机，上下文窗口取代传统代码；多模态模型更能直接跳过数据库、OCR 和定制前端，实现从原始输入到目标产物的端到端生成。 (5:00) 由于前沿实验室重度依赖自动化验证奖励进行强化学习（RL），模型表现出极端“参差的智能”——精通复杂代码重构却在常识物理逻辑上翻车；初创公司可通过搭建垂直领域的专用 RL 环境实现 SOTA 表现。 (10:00) Karpathy 强调“Agent 工程化”是比氛围编程更严肃的工程学科，开发者必须对系统安全性与架构负责；同时技术招聘也应从算法题转向考察候选人编排 Agent 构建与防御端到端系统的能力。 (15:00) 大语言模型更像被召唤的“幽灵”而非具有自主动机的动物，尽管思考与生成可外包给 Agent，但架构品味、底层概念理解与系统设计依旧无法被替代。 (25:00)

Andrej Karpathy argues that rapid advances in model reliability have initiated 'Software 3.0,' where natural language and context windows replace traditional code stacks, transforming programming from manual syntax authoring into agentic engineering. Software 3.0 and the Collapse of Traditional Stacks (0:00) Karpathy outlines an evolutionary progression from Software 1.0 (explicit logic) and Software 2.0 (neural weights trained on data) to Software 3.0, where large language models act as programmable computers operated via context windows. Traditional workflows require complex codebases to handle edge cases; for instance, cross-platform software like OpenClaw previously relied on elaborate installation scripts, but can now be packaged as plain text instructions that an autonomous agent reads, adapts, and executes across differing local environments. This paradigm shift fundamentally alters software architecture by bypassing intermediate software layers. When building his restaurant dish visualizer, MenuGen, Karpathy initially assembled a standard web stack—relying on optical character recognition (OCR), image generation APIs, and a custom user interface hosted on Vercel. In contrast, an end-to-end Software 3.0 approach required only a single multimodal prompt to overlay generated dishes onto the original menu photo. Karpathy forecasts that by 2026, neural networks may become the dominant 'host process' of computing, running real-time multimodal feeds and dynamically rendering UIs, while classical CPUs are relegated to handling deterministic edge calculations. Verifiability and the Mechanics of Jagged Intelligence State-of-the-art models exhibit severe 'jaggedness,' excelling in complex domains while failing basic logic. Karpathy attributes this disparity to the frontier labs' reliance on reinforcement learning (RL) guided by automated verification rewards. Where correctness can be programmatically verified—such as in competitive programming, mathematics, and code refactoring—capabilities surge. Outside verifiable environments, performance can stagnate or behave erratically. To illustrate this gap, Karpathy points out that models like Claude 3.7 Opus can refactor 100,000-line codebases or locate zero-day vulnerabilities, yet fail common-sense spatial reasoning by advising someone to walk to a car wash 50 meters away rather than drive. He also notes that specialized capabilities often stem from targeted data inclusion rather than pure scaling, such as OpenAI deliberately injecting chess data to boost GPT-4's performance. For startup founders, Karpathy recommends identifying vertical domains with verifiable outcomes and constructing proprietary RL environments to train specialized, state-of-the-art agents. Vibe Coding Versus Agentic Engineering and Hiring (15:00) Karpathy differentiates between 'vibe coding' and 'agentic engineering.' While vibe coding lowers barriers so casual creators can generate functional software through loose prompting, agentic engineering is a disciplined practice where professional developers manage fallible, stochastic agents while remaining accountable for security, architecture, and system reliability. Karpathy argues that the concept of a '10x engineer' is now an underestimate for practitioners who master high-leverage agent coordination. Because traditional coding benchmarks no longer reflect actual productivity, Karpathy asserts that technical hiring must be overhauled. Testing candidates on isolated LeetCode algorithmic puzzles evaluates an obsolete skill set. Instead, companies should assess how engineers orchestrate agents across complex, end-to-end assignments. For example, hiring processes could require candidates to construct an entire application—such as a secure social platform—and then test its resilience by unleashing multiple automated instances of models like Codex to actively probe and attack the architecture. The Limits of RL and the Bottleneck of Taste (20:00) Despite rapid capability gains, agents continue to struggle with architectural coherence, edge cases, and code elegance. Karpathy highlights an incident in which an agent attempted to reconcile Stripe payments with user accounts using raw email strings instead of persistent user identifiers, causing payments to fail. Furthermore, because reinforcement learning frameworks reward task completion rather than clean abstraction, agents frequently produce bloated, copy-pasted code. During his 'microGPT' project, Karpathy found that prompting models to simplify training code failed because aesthetic restraint falls outside existing RL reward loops. Characterizing LLMs as 'summoned ghosts' rather than self-motivated entities, Karpathy stresses that software documentation and infrastructure must transition from human-centric menus to agent-native interfaces. Although engineers no longer need to memorize mundane framework syntax, they must retain deep conceptual understanding of memory management, tensor views, and system design. Karpathy notes that while thinking and generation can be delegated to agents, architectural judgment, taste, and ultimate comprehension remain an inherently human bottleneck. Karpathy concludes that the expansion of Software 3.0 will collapse traditional software layers and shift developer workflows toward supervising stochastic models. However, because reinforcement learning does not inherently cultivate taste, code simplicity, or physical common sense, professional engineering will continue to depend on human architectural oversight and rigorous conceptual understanding.

OpenAI 联合创始人兼特斯拉前 Autopilot 负责人 Andrej Karpathy 指出，模型能力的突变正将软件开发从早期的“氛围编码”（vibe coding）推向“软件 3.0”与严肃的“智能体工程”（agentic engineering）。在此变革下，开发者的核心价值由编写语法细节转向架构设计、审美把控与智能体系统的综合调度。 软件 3.0 与计算堆栈的范式颠覆 (0:00) Karpathy 认为，软件开发经历了人工编写规则的 1.0 时代和以数据集、损失函数驱动的 2.0 时代，目前正迈入大语言模型充当通用计算机的“软件 3.0”时代。在这一阶段，上下文窗口成为用户控制解释器的核心接口，提示词与上下文管理替代了传统代码。以跨平台工具 OpenClaw 为例，过去需要编写庞大且脆弱的 Bash 脚本来兼容各操作系统边界，如今仅需将纯文本指令直接输入智能体，由其自主检测运行环境并完成部署调试。Karpathy 进一步推测，到 2026 年及以后，神经网络或将反客为主成为主导的“宿主进程”，使传统 CPU 降级为处理确定性任务的协处理器，未来软件系统甚至可能由连续的音视频流输入和实时扩散模型构成的动态界面驱动。 他在开发菜单识别应用 MenuGen 的经历印证了这种架构重塑。传统开发方式需搭建包含图片上传、OCR 文本识别、生图 API 调用及前端界面的完整 Web 堆栈；但在纯正的软件 3.0 模式下，用户直接向多模态模型（如搭载 Nano Banana 的 Gemini）输入菜单原图，模型便能在原始图像上直接渲染生成的菜品图。传统的数据库、解析管道与前端界面在此过程中被彻底绕过，实现了端到端的计算简化。 智能的锯齿化与强化学习的验证边界 Karpathy 指出，当前前沿人工智能展现出极端的“锯齿化”（jaggedness）特征，即在复杂任务上表现惊人，却在常识逻辑上频频失误。例如，尖端模型（如 Claude 3.7 Opus）能够重构包含 10 万行代码的大型项目或探测零日安全漏洞，但在被问及“我要去 50 米外的洗车店，该开车还是步行”时，却会荒谬地建议用户步行过去。类似地，早期模型因分词机制与缺乏针对性验证，无法正确数出“strawberry”中的字母“r”。 这种不均衡源于前沿实验室过度依赖带有自动化验证奖励的强化学习（RL）。在数学、编程竞赛等具有明确可验证指标的领域，模型进化极其迅速；但在缺乏形式化验证标准的通用认知领域，能力极易出现滞后。此外，某些专项突破往往源自实验室数据配比的人为干预，如 GPT-4 象棋水平的跃升主要归因于工程师向预训练集注入了海量对局数据。Karpathy 建议，创业团队若能在特定垂直领域搭建专有的可验证环境与微调流水线，即便通用实验室尚未涉足，也能在该领域建立壁垒。 从氛围编码到智能体工程与人才评估转型 (15:00) Karpathy 对“氛围编码”与“智能体工程”作出了明确界定。尽管氛围编码通过极低门槛让大众能够随性构建项目，但工业级应用必须依赖严谨的智能体工程。在该体系下，工程师虽然借助具备随机性与不确定性的人工智能代理来倍增产出，但仍须对系统的底层架构、安全漏洞与长期可靠性承担全部责任。Karpathy 强调，熟练掌握多智能体协作的专业工程师，其生产力提升幅度已远远超过传统意义上的“十倍工程师”。 伴随工程范式的演进，现行的技术面试体系已严重滞后。Karpathy 批评基于 LeetCode 的孤立算法考核属于旧时代产物，已无法有效衡量实际生产力。他提出，未来的工程评估应当要求候选人限时从零构建端到端的大型工程（如包含智能体交互行为的高并发安全推特克隆），随后派遣数十个高强度运行的自动化智能体（如并发运行的 Codex 实例）对系统实施压力测试与渗透攻击，以此考察开发者的防御性设计、复杂系统组织力与故障排查能力。 人类审美品味与智能体原生生态 (20:00) 面对智能体的高速生成能力，Karpathy 强调人类必须对产品规格、全局架构与审美判断行使绝对控制权。当前基于强化学习的模型缺乏针对代码整洁度与抽象优雅度的奖励机制，极易输出结构臃肿、拼凑痕迹明显的低质代码。在尝试极简大模型训练框架“microGPT”时，提示模型进一步简化代码的尝试均告失败，证明审美精炼目前仍处于强化学习的奖励回路之外。此外，智能体缺乏对现实实体关系的直觉，例如在处理账户与 Stripe 支付关联时，智能体会错误地使用裸邮箱字符串匹配而非持久化唯一 ID，导致不同邮箱支付失败。工程师虽无需记忆微观 API 参数，但必须透彻掌握底层张量视图与内存分配机制，方能纠正此类偏离。 针对基础设施演进，Karpathy 提出了“召唤幽灵而非培育动物”的比喻，强调语言模型是缺乏内在生物动机或进化驱动力的统计模拟回路。为此，未来的开发基建必须彻底走向“智能体原生”（agent-native），淘汰仅适配人类肉眼阅读的文档与复杂的控制台菜单，转为提供机器可解析的数据结构与无缝的智能体交互协议。他总结道，工程师“可以外包思考，但不能外包理解”，人类在把握技术原理与确立系统价值层面的深度认知，仍是技术演进中不可替代的核心节点。 Karpathy 认为，大模型虽大幅降低了软件开发的代码输入成本，但对架构规范、系统安全性与代码审美提出了更严苛的人类审视要求。未来工程生态的重心将转向构建智能体原生的开发基建，并探索如何利用强化学习解决代码优雅度缺失及智能锯齿化等深层挑战。

## Background 本期节目由红杉资本（Sequoia Capital）于 2026 年 4 月 30 日通过网络及播客渠道发布，记录了红杉合伙人 Stephanie Zhan 在 AI Ascent 2026 峰会上与 OpenAI 联合创始人兼 Eureka Labs 创始人 Andrej Karpathy 的深度对话。节目围绕 Karpathy 提出“Vibe Coding”一年后的技术剧变展开，探讨了他作为程序员为何反常地倍感落后、智能体工程（Agentic Engineering）的兴起、LLM 独特的“锯齿状幽灵”本质，以及在计算架构颠覆期人类不可外包的理解力与品味。 ## TL;DR Karpathy 剖析了编程范式从手写规则的 Software 1.0 到以提示词和上下文为核心杠杆的 Software 3.0 的范式跃迁，预言未来神经网络将作为主系统，而经典 CPU 将沦为处理确定性任务的协处理器。他严肃区分了降低大众门槛的 Vibe Coding 与捍卫专业质量上限的“智能体工程”，指出当前前沿模型是在特定可验证奖励驱动下的“统计幽灵”，虽能在数万行代码中挖掘漏洞，却可能在常识逻辑上滑稽翻车。在工程实践中，虽然 API 记忆与机械编码可完全外包给智能体，但架构设计、技术规范与底层机制的“不可替代的理解力”仍必须由人类严密掌控。 ## Atmosphere & style 整场对话充满极客式的真诚坦率与深邃的哲学思辨，Karpathy 毫不掩饰自己在前沿模型突变面前“冰火两重天”的震撼与被抛下的危机感。两人的交锋节奏紧凑且信息密度极高，将诸如“步行去洗车悖论”、“拔牙般的 microGPT 极简化”等生动隐喻与严谨的系统认知无缝交融。现场不仅洋溢着见证历史转折点的兴奋与紧迫感，更在幽默诙谐的反思中透出一种属于顶尖系统架构师的清醒与审慎。 ## Bulletin - `00:00` 前沿模型在自主 Agent 工作流上跨过可用性阈值，Karpathy 表示编程已从对手工生成代码修修补补演进为完全信任的 Vibe Coding，软件演进正式迈向由 Prompt 与 Context 驱动的 Software 3.0 阶段。 - `06:40` 未来的计算范式可能发生彻底反转：端到端神经网络将成为系统的主进程（Host Process），而传统 CPU 与确定性代码调用则退化为仅负责打杂的协处理器。 - `15:00` Karpathy 区分了 Vibe Coding 与 Agentic Engineering（智能体工程）：前者是降低门槛拉高大众下限，而后者是专业工程师编排随机性实体、捍卫工业级质量底线并实现远超 10 倍生产力跃升的严肃学科。 - `23:45` LLM 本质上不是具备内在动机与生存直觉的动物，而是基于海量统计并被人工奖励函数强行嫁接能力的“幽灵”，展现出超高难度推理与基础常识断层并存的“锯齿状智能”。 - `27:35` 面对零边际成本的智能，工程师的护城河在于“可以外包思考，但绝不能外包理解”：具体的代码与推演可委托给 Agent，但架构品味、系统规范设计以及对问题本质的深度理解依然必须由人类掌控。 ## Key takeaways - `00:00` 模型生成代码在连贯执行与闭环自主修复上迎来断层跃升，彻底颠覆了开发者频繁手动介入的旧习惯。 - `03:02` Software 3.0 正在将 Context Window 转化为核心操作杆，Prompt 即源代码，大模型作为通用的神经解释器直接闭环执行任务。 - `04:47` 多模态端到端处理直接侵蚀了由 OCR、API 胶水层及前端渲染搭建的传统应用层，大量经典 App 架构在神经计算下失去存在必要。 - `06:40` 计算架构终局将走向全神经网络计算机，通过瞬时扩散模型动态渲染单次专属 UI，经典 CPU 沦为确定性任务的辅助部件。 - `10:00` LLM 的能力边界由“可验证性”和强化学习奖励决定，导致其在数学与代码等领域登峰造极，在缺乏验证机制的常识场景却频现“洗车悖论”等认知割裂。 - `12:30` 前沿模型能力的爆发高度依赖实验室的数据灌入偏好；创业者突围的关键在于切入具备明确规则与 RL 验证环境的垂直赛道，自主拉动微调杠杆。 - `15:00` Agentic Engineering 是对 Vibe Coding 的工程化升华，旨在驾驭脆弱且具随机性的 Agent，严守工业级软件的可靠性、安全性与架构标准。 - `17:30` 传统手撕算法的面试机制已全面落伍，新型招聘应聚焦考察候选人借助 Agent 交付高健壮性复杂系统的能力，并引入多模型红队对抗测试。 - `20:00` Agent 极易在系统设计上走危险捷径（如用邮箱匹配账户），人类必须负责定义全局规范（Spec）与持久化架构约束，仅将 API 细节召回外包。 - `22:15` 当前的 RL 训练只奖励功能通过率而忽视精简美学，导致 Agent 倾向于生成臃肿脆弱的冗余代码，极简抽象与架构品味依然依赖人类介入。 - `23:45` 大模型是在海量统计数据上通过人工附肢嫁接能力的“幽灵”而非动物，缺乏具身生存动机，面对它们时工程师应保持审慎的怀疑而非拟人化共情。 - `25:20` 现存数字基础设施充斥着反直觉的人类导向设计与复杂仪表盘，亟需重构为面向 Agent 的“传感器”与“执行器”，并以文本化自描述指令替代图形操作。 - `27:35` 你可以外包思考，但绝不能外包理解；人类作为系统的总导演，一旦丧失对构建目标与底层机理的深刻理解，就会退化为智能化系统的核心瓶颈。 - `27:35` 构建个人专有知识库并通过大模型进行多维透视与合成数据生成，是人类在廉价智能时代高效扩展认知带宽与深化理解力的关键途径。 ## Detailed walkthrough ### `00:00` “我从未觉得自己作为程序员如此落后”：从 Vibe Coding 到 Agent 质变 红杉资本合伙人 Stephanie Zhan 在开场中隆重介绍了 Andrej Karpathy。作为 OpenAI 的联合创始人（当年正是在如今会场所在的办公区内创立）、前特斯拉 Autopilot 负责人以及 Eureka Labs 创始人，Karpathy 去年创造了“Vibe Coding”（氛围编码/感性编码）这一风靡技术圈的术语。然而就在几个月前，Karpathy 却说出了一句更令人心惊的话：“作为一名程序员，我从未感到自己像现在这样落后。”当被问及这种感受究竟是令人兴奋还是令人不安时，Karpathy 坦言：“两者兼有，绝对是一场冰火两重天的体验。” Karpathy 解释了这种心境剧变的由来。在过去一年多里，他和很多人一样，一直在尝试各种 agent 编码工具和代码生成软件。起初，这些工具确实擅长生成小块代码，但经常漏洞百出，开发者不得不频繁停下来手动修正，它更像是一个“还算顺手的小帮手”。然而关键的质变发生在刚刚过去的 12 月——当时他正值假期，有了整块充裕的时间进行密集测试。他震惊地发现，最新一代前沿模型的表现发生了断层式的跃升：模型生成的大段代码几乎总是直接可用；他试着提出越来越长、越来越复杂的开发需求，产出的结果依旧完美无瑕；到最后，他甚至“记不起上一次手动改代码是什么时候了”。 伴随着对系统信任度的迅速建立，他彻底进入了深度的 Vibe Coding 状态。Karpathy 在社交平台 X 上反复呼吁大家必须重新审视 AI 的现状：“很多人对 AI 的认知还停留在去年 ChatGPT 那种‘生成一段 JSON 或回答几个问题’的阶段，但大家必须以 12 月为基准重新看一次。”因为从那个节点起，具备连贯执行力、自主闭环的 Agent 工作流才真正宣告成熟。这种认知彻底颠覆了他的开发习惯，直接让他陷入了一个疯狂开坑的兔子洞中——他的本地磁盘里堆满了各种稀奇古怪、无限膨胀的 Side Projects，每天都在全天候地进行 Vibe Coding。 - **心理转折点**：从过去对 AI 生成代码修修补补的“辅助感”，骤变为“完全记不起上次手动纠错时间”的绝对信任。 - **关键时间窗口**：12 月的最新模型让 Agent 的连贯执行工作流（coherent workflow）跨过了可用性阈值，带来了质的断层升级。 ```mermaid flowchart TD accTitle: 编程范式的代际演进与控制方式对比 subgraph S1["Software 1.0 (经典计算)"] A["人类程序员"] -->|"编写确定性逻辑与规则"| B["源代码 / Shell 脚本"] B -->|"CPU 执行"| C["精确输出"] end subgraph S2["Software 2.0 (深度学习)"] D["算法工程师"] -->|"清洗整理数据与设计损失函数"| E["神经网络训练"] E -->|"梯度下降优化"| F["模型权重 Weights"] end subgraph S3["Software 3.0 (神经解释器)"] G["人类指挥者"] -->|"Prompt / 上下文提示"| H["LLM 神经解释器"] H -->|"自主推断与工具调用闭环"| I["计算与任务交付"] end ``` ### `03:02` Software 3.0 范式转移：从编写规则到将上下文作为操作杆 随着大语言模型（LLM）不仅作为更好的软件、而是作为一种全新“计算机架构”的讨论升温，Stephanie 追问：如果这是真的，那些真正相信这一点的团队在做事方式上会有何根本不同？Karpathy 从经典的软件演进框架切入展开剖析：在 Software 1.0 时代，程序员的核心工作是亲手手写一行行显式的规则与代码；到了 Software 2.0 时代，编程变成了通过构建数据集、调整目标损失函数与神经网络架构来训练模型，编程的产物不再是规则，而是模型学到的权重；而如今正在发生的 Software 3.0 跃迁，核心则在于“训练过程将互联网上近乎所有的多任务隐式压缩到了模型中”，这使得 LLM 本身变成了一台可以通过自然语言编程的虚拟计算机。 在 Software 3.0 的定义下，“编程”这一动作已经彻底蜕变成了“编写 Prompt（提示词）”。用户塞入 Context Window（上下文窗口）的内容，就是操控这台底层 LLM 解释器的杠杆，由大模型在数字信息空间中去解释意图并完成计算。为了具象化这种剧变，Karpathy 举了开源项目 OpenClaw 的安装方式作为例子：在 Software 1.0 的世界里，想要让软件安装在成百上千种不同硬件、不同操作系统的计算机上，传统的做法是编写极度冗长、分支极多、动辄发生莫名报错的 Shell 脚本（Bash Script），试图用确定性的代码穷尽所有边缘情况。 然而 OpenClaw 的实际安装指引却颠覆了这一逻辑——它甚至不是一个脚本，而是一段纯文本 prompt，指引用户“直接将这段文字复制粘贴给你的 Agent”。在 Software 3.0 体系中，开发者无需穷尽所有底层安装细节，因为 Agent 本身就封装了环境理解与调试的智能：它会自动嗅探宿主计算机的环境依赖，自主执行操作，遇到报错在闭环内自行排查修复。“这就是现在的编程范式：寻找那段最适合复制粘贴给 Agent 的核心文本指令。” - **Software 1.0**：程序员手写显式逻辑分支与规则。 - **Software 2.0**：程序员构建数据集并训练神经网络，通过反向传播习得参数权重。 - **Software 3.0**：Prompt 成为源代码，Context Window 成为核心杠杆，LLM 自身作为具备自主解决与排错能力的“执行解释器”。 ### `04:47` MenuGen 的顿悟与通用信息处理：应用层为何正在被神经计算吞噬 为了说明这种思维惯性有多深，Karpathy 分享了自己亲身经历的一次荒诞顿悟。他曾经 Vibe-code 过一个名为“MenuGen”的个人项目：在日常下馆子时，餐厅菜单往往密密麻麻全是菜名却没有配图，常常有 30% 到 50% 的菜品让人完全摸不着头脑。于是他写了一套完整的应用系统：用户拍下菜单照片上传，应用部署在 Vercel 上，后台管线首先通过 OCR 识别所有菜名文本，然后调用图像生成模型逐一绘制对应的菜品插图，最后重新渲染并生成一份图文并茂的数字化交互菜单。 然而不久之后，他见识到了基于 Software 3.0 思维打造的同款功能，其实现方式直接让他“CPU 烧焦”：对方根本没有写任何应用代码，只是把菜单照片直接喂给多模态大模型 Gemini，并给出一段提示词（调用如 Nano Banana 之类的能力模块），要求它直接将绘制好的菜品图像贴回到原本的菜单中。模型直接在像素层面上重构了照片，返回的就是原本那张带图的全新菜单图像。Karpathy 感叹道，这种降维打击让他意识到，自己辛辛苦苦用传统架构搭建的 MenuGen 充斥着毫无必要的“冗余胶水逻辑”（spurious code），“这个 App 根本就不应该存在！”在 Software 3.0 时代，端到端神经网络吞噬了中间所有环节：输入是图像，输出是图像，中间的传统应用层完全消融。 Karpathy 借此进一步推演：将 AI 仅仅看作“让编程变得更快”本身就是一种落后思维。真正的跃迁在于“通用信息处理能力的自动化”，它涵盖了大量过去根本无法被代码化的非结构化场景。比如他的个人实验项目“LLM Knowledge Bases”（LLM 知识库系统），让模型为个人或组织自动从事实碎片中编译生成体系化的 Wiki 知识架构。在此之前，人类没有任何一套 Software 1.0 算法能够“基于一堆零散文档自主推敲出百科知识库”。人们不应该仅着眼于旧事物如何加速，而应该去寻找那些在过去计算范式下完全不可能存在的全新能力。 - **MenuGen 的反差**：传统架构需要 OCR、文字解析、文生图 API、前端渲染多层胶水代码；新范式直接利用多模态网络实现“端到端像素重构”，中间的应用代码全部沦为多余。 - **超越代码处理**：传统软件必须建立在结构化数据之上；Software 3.0 允许直接在海量非结构化知识上执行重组、编译与重塑。 ### `06:40` 走向神经计算机：当神经网络反客为主，CPU 沦为协处理器 Stephanie 顺着 Karpathy 编程范式的演进轨迹提问：如果从当下的突破进一步向后推演，到 2026 年甚至更远的未来，什么事情会像当年的 90 年代建网页、2010 年代做移动 App、上个云计算时代的 SaaS 一样，在事后看来理所当然，而今天却绝大多数人尚未构建？ Karpathy 给出了一个极具颠覆性的预言：“完全由神经网络构成的计算机”（Completely Neural Computers）。他设想未来的计算终端形态可能会极其奇特且陌生：输入端直接持续摄入纯原始的视频流或音频流，进入底层的神经网络；系统通过扩散模型（Diffusion）在毫秒级内直接渲染出“仅针对当前那一瞬间所独有的用户界面（UI）”，不再有固定的窗口、按钮或静态代码。 Karpathy 回顾了计算机科学的源头：在 20 世纪 50 和 60 年代，早期先驱们其实非常纠结未来的计算机究竟应该长得像“算盘/计算器”，还是长得像“神经网络”。历史最终走向了由逻辑门和 CPU 构成的确定性经典计算路线，而神经网络在过去几十年中不过是虚拟化运行在传统计算架构之上的副产物。但眼下，整个力量对比正在发生根本性的倒转： “你可以想象这套体系完全颠倒过来——神经网络成为宿主主进程（Host Process），而 CPU 则反过来沦为为某些确定性任务打杂的协处理器（Co-processor）。” 随着全球计算算力（FLOPs）的绝对重心全盘向智能计算倾斜，确定性的代码工具调用（Tool Use）终将沦为历史残留的附庸，真正运行全场、主导系统的将是由神经网络深度互联构成的全新计算形态。尽管通往这一终局的发展路径仍需一步步验证（TBD），但这一向异质外星算力进化的趋势已不可逆转。随后，对话切入到了实现这一愿景的核心制约逻辑——“任务可验证性”（Verifiability）对各行各业自动化速率的分野。 - **计算史的反思**：50-60 年代计算形态曾面临“计算器模型”与“神经网络模型”的分岔路，经典计算主导了前几十年，但逆转已经发生。 - **主客倒置预言**：未来的计算形态中，神经网络是掌控一切的主操作系统，经典 CPU/GPU 架构与代码调用仅作为处理确定性逻辑的“外部挂件”。 ### `10:00` 锯齿状智能与可验证性的本质 传统计算机能够轻松实现代码中明确指定逻辑的自动化，而最新一代的大语言模型（LLM）从本质上讲，则是将“人类能够验证”（what you can verify）的一切进行自动化。前沿实验室在训练这些前沿模型时，构建了极其庞大的强化学习（RL）环境，并向模型提供明确的验证奖励（verification rewards）。这种训练范式直接造就了模型极其独特的“锯齿状实体”（jagged entities）特质：在数学、编程等高度可验证的领域，模型的能力直接飙升至不可思议的高峰；而在缺乏明确验证反馈机制或处于数据分布边缘的领域，其表现则停滞不前、粗糙且漏洞百出。这并非单纯由技术架构决定，很大程度上取决于前沿实验室的商业重心与投入在训练集中的数据分布——代码因其巨大的经济价值而获得了大量构建 RL 环境的倾斜，而许多同样具备高度可验证性的领域仅仅因为经济价值不高，便未被纳入训练配方中。 这种“锯齿状”能力造成了许多令人啼笑皆非的反差。过去人们津津乐道的一个经典例子是询问模型“strawberry（草莓）一词里有几个字母 r”，早期的 LLM 几乎全军覆没（尽管现在各大实验室已将其打上补丁）。卡帕西指出了当下最新的荒谬对比案例：“我想去 50 米外的洗车店洗车，我应该开车去还是步行去？”现如今业界最顶尖的模型竟会信誓旦旦地建议你“步行过去，因为距离太近了”。这种认知割裂让卡帕西直呼“太疯狂了”——像顶尖的 Opus 4.7 这类前沿模型，一边能够重构拥有 10 万行代码的大型代码库，甚至挖掘出极其隐秘的零日漏洞（Zero-day vulnerabilities），另一边却会建议你走路去洗车。只要这种锯齿状的认知落差依然存在，就意味着我们必须深刻意识到：要么底层仍有某些系统性缺陷，要么人类必须始终保持在控制闭环中（in-the-loop），将其视为工具并密切监视其行为。 - **传统计算 vs. LLM 自动化**：传统程序自动化的是“可编码定义规则”的任务；前沿强化学习驱动的模型自动化的是“结果可被验证”的任务。 - **锯齿状智能的核心成因**：前沿实验室的强化学习奖励机制 + 对特定高经济价值领域（如编程和数学）的集中资源倾斜。 - **洗车悖论（Car Wash Paradox）**：顶尖模型一方面能审查数十万行代码并修补高危安全漏洞，另一方面却因字面距离近而建议人类“步行去洗车店洗车”。 --- ### `12:30` 实验室的数据偏好、国际象棋跃迁与创业者突围 在模型能力演进的表象背后，开发者往往处于前沿实验室决策的“支配”之下。从 GPT-3 到 GPT-4 的跃升期间，大众惊讶地发现模型的国际象棋水平突飞猛进，许多人误以为这是模型推理能力自然涌现的结果。但实情并非如此神秘：根据公开信息，当时是 OpenAI 的某位研究人员将海量的国际象棋对局数据灌入了预训练数据集中。仅仅因为这个领域被主动纳入了数据分布，其能力就出现了非线性的暴涨。这揭示了一个残酷的现实：开发者面对的是一个完全没有使用说明书的黑箱黑盒；如果你的应用恰好踩在实验室投入重兵做 RL 强化的“回路”上，模型就会如虎添翼、一日千里；一旦偏离了该回路，模型就会举步维艰。此时开发者不能寄希望于 LLM 开箱即用，必须依靠微调（Fine-tuning）和自建流程来补足短板。 针对现场创业者的困惑——面对前沿实验室在数学、编程等显而易见的赛道已达到逃逸速度（escape velocity），新创企业该如何立足？卡帕西给出的建议是回归“可验证性”的第一性原理。可验证性之所以在当下的技术范式中行之有效，是因为它允许开发者向系统注入海量的强化学习计算。即便前沿实验室没有聚焦于某一垂直领域，该规律依然成立。如果创业者身处一个能够构建明确可验证规则与丰富 RL 环境的特定垂直赛道，只要掌握多样化的数据集和强化学习环境，就能借助现有的微调框架“拉动杠杆”，训练出表现极其优异的专用模型。卡帕西在台上神秘地保留了一个尚未被前沿实验室涉足、但极具商业潜力的 RL 环境构想，笑称自己不想在舞台上“语意模糊地吊胃口”（vague post on the stage），但这确实是极具确定性的技术切入点。 ```mermaid flowchart TD accTitle: 可验证性与模型能力的因果链路 accDescr: 展示从前沿实验室数据偏好与强化学习奖励到模型锯齿状能力的传导过程 subgraph LabFocus["前沿实验室范式"] A["高商业价值 / 可定义环境<br/>（如编程、数学）"] --> B["大规模强化学习奖励<br/>（Verification Rewards）"] C["特定数据注入<br/>（如 GPT-4 棋谱数据）"] --> D["预训练分布倾斜"] end subgraph JaggedCapability["锯齿状智能表现"] B --> E["超强能力尖峰<br/>（重构大型代码库、挖零日漏洞）"] D --> E F["非重点 / 未验证长尾场景"] --> G["能力洼地 / 常识断层<br/>（'步行去洗车'悖论）"] end subgraph FounderStrategy["创业者破局路径"] H["寻找垂直可验证领域"] --> I["构建专属 RL 环境与评测集"] I --> J["自主拉动微调杠杆<br/>（Fine-tuning Lever）"] end ``` --- ### `15:00` 从 Vibe Coding 进化到“智能体工程”（Agentic Engineering） 针对“是否存在某些领域只是远看可被自动化、实则无法攻克”的问题，卡帕西持极其乐观的态度。他认为从长远来看，几乎世间的一切最终都可以在某种程度上被转化为“可验证”的形式——即便是写作等主观性极强的艺术创作，未来也可以通过组建“LLM 裁判团”（a council of LLM judges）等机制来建立评估基准。因此，本质上只是实现难度的高低与先后次序问题，最终“万物皆可被自动化”。 谈及一年前他亲手创造的流行词“Vibe Coding”（氛围编码/凭感觉编程）与当下技术态势的区别，卡帕西划清了一条严肃的界线。他指出，Vibe Coding 的价值在于“拉高全民的下限”（raising the floor），让哪怕毫无编码背景的普通人也能凭借直觉做出应用；而如今正在成型的严肃技术范式则是“智能体工程”（Agentic Engineering），它的核心使命是“捍卫专业软件既有的质量上限与规范”（preserving the quality bar）。在工程级系统中，工程师绝不能容忍因凭借感觉写代码而引入系统漏洞或安全隐患，开发者依然要对交付的软件负全责。 | 维度 | Vibe Coding（凭感觉编码） | Agentic Engineering（智能体工程） | |:--- |:--- |:--- | | **核心定位** | 拉高大众下限（Raising the floor） | 拔高专业上限（Extrapolating / Raising the ceiling） | | **目标受众** | 所有人、业余爱好者、快速原型开发者 | 专业软件工程师、系统架构师 | | **质量责任** | 依赖运气和感觉，容忍瑕疵与不可控漏洞 | 严格守住工业级质量底线，对安全性与健壮性负全责 | | **交互模式** | 人类发出模糊指令，顺其自然接收生成代码 | 人类作为总指挥，工程化编排具备随机性与尖锐特质的多个智能体 | | **杠杆效应** | 让不会写代码的人拥有构建简单软件的能力 | 将优秀工程师的生产力乘数从过去的 10x 放大到远超 10x 的巅峰 | 智能体工程本质上是一门严苛的工程学科。智能体是极其强大、却又高度脆弱且带有随机性（stochastic）的“尖刺状实体”（spiky entities）。如何严密地协调、调度这些智能体，在丝毫不牺牲系统质量标准的前提下实现前所未有的开发速度，正是智能体工程的核心所在。过去硅谷推崇“10倍工程师”（10x engineer），而在卡帕西看来，如今顶尖智能体工程师所能达到的生产力倍率已远远凌驾于 10 倍之上。 --- ### `17:30` 全新的人才招聘范式与不可替代的人类品味 随着编程工具链的彻底演变，人类工程师的分野逐渐显现。对比传统模式与真正的“AI 原生代”，两者的差距在于是否深度调动了所有现成工具的高级功能，并全力投资打磨专属的开发工作流环境——正如过去硬核程序员钻研 Vim 或 VS Code 一样，如今的 AI 原生开发者深入定制着 Claude Code、Codex 等新一代智能体工具。 卡帕西尖锐地指出，目前绝大多数科技公司的工程招聘流程完全落伍，仍然停留在让候选人手撕 LeetCode 算法谜题的旧时代。真正的智能体工程招聘应当彻底重构： - **大体量实战考核**：扔给候选人一个极其庞大且复杂的项目（例如“为 AI 智能体编写一个全功能的推特克隆版”），考察候选人如何在智能体协助下从零完整交付； - **真实功能与安全性闭环**：该项目必须具备极高的健壮性与严密的安全防御机制，并能让一批模拟智能体在上面产生真实的交互活动； - **智能体红蓝对抗（Red Teaming）**：招聘方随后调动多达 10 个高规格的前沿模型实例（例如 Codex 5.4x High）作为红队攻击者，对候选人部署的网站发起全方位、不择手段的渗透攻击，系统必须能够抗住这波智能体攻击而不被攻破。 在这种新型开发图景中，智能体更像是心智尚不健全的“实习生实体”（intern entities）。随着底层繁重的工作被接管，真正变得弥足珍贵、无法被取代的人类核心能力，反而是审美（aesthetics）、判断力（judgment）、工程品味（taste）以及高层级的全局审查视线。卡帕西以 Eureka Labs 正在开发的项目 Menugen 中的奇葩 Bug 为例展开趣闻——在设计通过 Google 账号登录的流程时，智能体生成的逻辑往往暴露出意想不到的认知脱线与荒谬细节，再次凸显出缺乏人类审美与判断力时，再高效的智能体也无法独自构成健全可靠的产品。 ### `20:00` 规范设计与底层理解：从 Stripe 账户 Bug 到 API 细节的剥离 Andrej Karpathy 举了一个自己在构建 Agent 时遇到的典型翻车案例：用户通过 Stripe 账户购买积分，系统同时存在 Google 账号和 Stripe 账号，两者都有邮箱地址。然而，他的 Agent 在编写积分充值逻辑时，竟然试图直接通过比对 Stripe 提供的邮箱和 Google 邮箱来进行对账发放，而没有设计全局唯一的持久化用户 ID（persistent user ID）。一旦用户在 Stripe 付款时填写的邮箱与 Google 账号邮箱不一致，资金就彻底对不上账。Karpathy 哭笑不得地吐槽："为什么会想到用邮箱地址去跨平台匹配资金？邮箱本来就是随意的、可以不同的，这种做法简直太诡异了。" 这类结构性低级错误生动地证明：人类必须牢牢掌控系统规范（Spec）与架构蓝图的制定。尽管市面上各种工具的 Plan 模式很有用，但他更倾向于一种更普适的协作范式——人类与 Agent 密切配合，先打磨出一份极度详尽的技术规范（其本质就是架构文档），再交给 Agent 去编写具体实现代码；人类负责顶层把控和结构拆解，Agent 负责底层搬砖。 这种分工也彻底改变了程序员与技术细节的交互方式。以神经网络开发中的张量（Tensor）操作为例，PyTorch、NumPy、Pandas 之间充斥着大量碎屑般的 API 差异。Karpathy 坦言，自己现在早就记不清也不打算去记诸如 `keepdims` 还是 `keepdim`、参数名叫 `dim` 还是 `axis`、该用 `reshape`、`permute` 还是 `transpose` 这些细节了，"我已经不记得这些东西了，因为你根本没必要记"。这类细枝末节完全可以交给像“拥有超强瞬时记忆的实习生”一样的 Agent 去处理。但作为工程师，核心认知门槛并没有消失：你依然必须深刻理解底层的张量机制——明白什么是底层存储（Storage）、什么是视图（View），何时是在操作同一个内存切片，何时会触发不必要的内存复制导致性能崩盘。人类掌握工程品味、系统设计与底层原理，确保系统要求明确（例如必须绑定唯一的 User ID），而工程实现层面的“填空题”则全盘交给模型。 ```mermaid flowchart TD accTitle: 人类工程师与 Agent 的协作分工模型 accDescr: 展示人类主导规范设计、底层认知与品味把控，Agent 负责 API 召回与代码填充的分工结构 subgraph Human["人类工程师：架构与品味"] H1["物理与系统本质理解\n(内存视图 / Storage / 资源开销)"] H2["详尽技术规范 (Spec) 设计\n(唯一 ID / 数据流边界)"] H3["审美与架构审查\n(消除臃肿 / 纠正反模式)"] end subgraph Agent["AI Agent：实现与执行"] A1["精确细节召回\n(PyTorch / NumPy API 差异)"] A2["样板代码与逻辑填充"] A3["自动化重构与单测验证"] end H1 --> H2 H2 --> A2 A1 --> A2 A2 --> H3 H3 -.->|"迭代修正"| A2 A2 --> A3 ``` - **持久化用户标识的重要性**：Agent 倾向于走快捷方式（如基于邮箱字符串匹配），容易在支付与身份认证模块埋下灾难性漏洞，必须由人类在 Spec 中强制规定唯一实体 ID。 - **底层原理 vs API 语法**：虽然 API 语法记忆可以完全外包给 Agent，但对内存布局、张量 Storage/View 映射、计算复杂度的底层认知，依然是区分工程师与普通操作者的核心护城河。 --- ### `22:15` 强化学习缺失的品味成本：微小化 microGPT 的无力感 当 Stephanie Zhan 追问代码品味（taste）与判断力未来是否会随着模型进化而变得无关紧要时，Karpathy 坦诚地表示，虽然他极度希望模型能够自动进化出品味，但现状却常常让他“心脏骤停（get a little bit of a heart attack）”。每当你翻开 Agent 实际生成的代码库，往往会发现代码质量远谈不上优雅：里面充斥着大量冗余臃肿的逻辑（bloaty）、肆无忌惮的复制代码，以及极度脆弱尴尬的抽象设计，"它确实能跑，但看起来恶心极了（it works, but it's just really gross）"。 Karpathy 分析认为，这种审美缺陷的根源在于当下的强化学习（RL）训练机制。目前的 RL 奖励函数通常只奖励“测试通过”或“功能实现”，根本没有引入所谓“代码美学成本（aesthetics cost or reward）”或者美学评估指标还不够灵敏。他分享了自己在开发 microGPT 时的痛苦经历：当时他试图将 LLM 的训练过程简化到物理极限的极简程度，然而模型对此极其排斥。"我不断给它发 Prompt，要求它‘再简化一点、再精炼一点’，它就是做不到。你会感觉自己完全被甩出了强化学习的电路之外，每推进一步都像是‘在生拔牙（pulling teeth）’一样艰难，完全丧失了那种行云流水的顺畅感。" 这表明，当前的端到端训练还没有真正覆盖到抽象精简和代码美感，极简化与架构品味依然牢牢依赖人类把关。 - **代码臃肿与脆弱抽象**：Agent 代码呈现典型的局部可用但全局丑陋的特征，过度嵌套与缺乏 DRY（Don't Repeat Yourself）原则是普遍现象。 - **强化学习的盲区**：目前主流 Post-training/RL 主要优化可验证的任务通过率，代码精炼度、可维护性与极简美学缺乏明确可量化的奖励标量。 - **microGPT 实验警示**：让模型主动做减法、剥离冗余概念远比让模型堆砌功能困难得多。 --- ### `23:45` 并非制造动物，而是召唤幽灵：统计模拟与锯齿状智能 两人的讨论转向了 Karpathy 近期引发技术圈广泛共鸣的哲学观点——“我们制造的不是动物，而是在召唤幽灵（We are summoning ghosts）”。Stephanie 提到，真实的动物智能是数十亿年进化筛选出的产物，拥有内在动机、好奇心、快乐追求以及自主生存掌控力；而当今的大模型则是被数据和奖励函数塑造出的“锯齿状智能（jagged forms of intelligence）”。Karpathy 阐述了他写下这一比喻的心路历程：他并不是在纯粹空谈哲学，而是试图为开发者构建一个准确的心智模型（mental model），因为只有搞清楚这些系统的本质，使用时才会更具掌控力。 Karpathy 直言，必须清醒地认识到这些系统绝非动物神经系统，"你如果冲着它大吼大叫，它既不会变得更好，也不会变得更糟，这不会产生任何影响。" LLM 的本质是一套基于统计的模拟电路，其基底由预训练阶段海量语料统计规律构建，随后的强化学习则像是在这团统计幽灵上强行嫁接的一系列“附肢（appendages）”。因为缺乏生物进化的统一具身与连续生存目标，它们的能力表现必然是极度参差不齐的“锯齿状”——在某些高难度推理上展现出超人天赋，却在常识性逻辑或简单直觉上意外摔跟头。在面对这样的幽灵系统时，工程师最重要的素养不是盲目信任，而是始终保持一种审慎的怀疑态度（suspicious），在实践摸索中不断探明其能力槽位与断裂带。 - **动物智能 vs 幽灵智能**： - **动物智能**：源于自然选择与具身进化，具有连续的生存本能、内在探索欲望、好奇心与自我激励机制。 - **幽灵智能**：以无目标的统计预测（Pre-training）为底座，通过人工定义的奖励函数（RL）嫁接功能，缺乏内在统一的目标和直觉连贯性。 - **无情感反馈回路**：拟人化的情绪施压（如恐吓、催促或鼓励）在面对底层统计模拟电路时没有任何生理学意义上的激励效果。 --- ### `25:20` 原生 Agent 环境重构：从反人性的文档到传感器与执行器 随着 Agent 逐渐走出对话框，获得本地环境的读写权限并开始代替人类执行真实操作，软件世界的整体形态正面临剧烈重构。Karpathy 指出，当前整个数字基础设施最反直觉的地方在于，所有软件仍然是彻底“为人类设计的”，这构成了 Agent 发挥潜力的最大摩擦。他甚至半开玩笑地透露了自己最大的“眼中钉（pet peeve）”：现在各大框架、库和服务的官方文档依然在执拗地教人类该怎么点击和操作。"为什么还在告诉我该怎么做？我根本什么都不想做！请直接告诉我应该把哪段文字复制粘贴给我的 Agent！" 每次文档跳出来提示“请访问该 URL 手动配置”时，都让他感到极度低效和痛苦。 Karpathy 提出了构建“Agent 原生（Agent-native）”基础设施的核心主张：未来的软件负载应当被彻底解构为面向物理或数字世界的“传感器（sensors）”与“执行器（actuators）”，文档与 API 首先应当对 LLM 极其清晰可读。他以自己之前开发 MenuGen 的经历为例吐槽道，写出 MenuGen 的业务代码根本没费多少工夫，真正的折磨全在部署到 Vercel 的过程——他不得不手动穿梭于各种第三方服务之间，逐个进入仪表盘、调整繁琐的设置菜单、手动配置 DNS 解析。在一个理想的 Agent 原生时代，人类应该只需给出一条 Prompt："帮我构建 MenuGen 并上线发布"，Agent 即可自动端到端调用接口完成部署，人类连一个网页菜单都不需要触碰。此外，未来必定走向每个人、每个组织都拥有专属 Agent 代表的形态，会议时间协调等琐事将完全演变成“我的 Agent 去找你的 Agent 自主谈判协商”。 - **基础设施的 Agent-native 改造**：从图形化菜单与人类阅读型文档，转向面向模型的结构化数据接口、机器自描述规范及自动化权限通道。 - **MenuGen 部署痛点**：当前云原生部署依然充斥着割裂的人工控制台操作（DNS、密钥关联、环境配置），成为制约自主系统的最大瓶颈。 - **系统接口的抽象转变**：业务交互界面退化，软件能力被拆分为感知外部状态的传感器（Sensors）与改变外部状态的执行器（Actuators）。 --- ### `27:35` 外包思考却不可外包理解：在廉价智能时代的个人知识底座 在访谈尾声，Stephanie 邀请 Karpathy 探讨在 AI 让智能成本急剧趋近于零的时代，人类教育究竟该何去何从、还有什么是值得人类去“深度学习”的。Karpathy 分享了一条近期让他大受触动、几乎每隔几天就会在脑海中回响的推文： > "你可以外包你的思考，但绝不能外包你的理解（You can outsource your thinking, but you can't outsource your understanding）。" Karpathy 强调，人类依然是整个智能化闭环中不可替代的控制枢纽。信息最终必须以某种方式进入人类的大脑，因为正是“理解”在制约着核心决策——我们究竟要建造什么？这件事为什么值得做？我们该如何向 Agent 下达正确意图？Agent 极擅长执行具体的思考与逻辑推演，但它们完全不具备深层理解力，因此人类作为发号施令的“导演（director）”，一旦丧失理解力，就彻底失去了导演的资格，进而沦为系统的瓶颈。 为了强化个人的理解力，Karpathy 正在深度依赖基于 LLM 构建的个人知识库。每当阅读完深度文章或学术材料，他会将内容沉淀到个人维基（Wiki）中，通过高频向大模型提问，基于这些特定知识进行“合成数据生成”，从不同的投影视角审视同一批信息，以此不断逼近底层洞见。在他看来，这种工具绝非代替学习，而是给大脑装上了理解力的加速器。访谈在充满科技哲思与幽默的气氛中结束，Karpathy 笑称，非常期待几年后再回到这个舞台，看看届时人类是否已经彻底被自动化“移出了循环”，甚至连“理解”这项最后特权也已经被模型全部接管。 - **核心格言认知**：思考过程（推理步骤、代码撰写、数据整理）可以高度外包，但对问题本质的直觉、目标价值判定与系统理解（Understanding）是不可委托的。 - **人类导演角色**：LLM 缺乏全局意图理解，无法自主确立“造什么”与“为何而造”，人类必须凭借深刻理解力扮演战略指挥者。 - **个人知识合成引擎**：利用大模型对私人文档库进行多维投影视角的问答与合成数据生成，是放大人类理解深度与认知带宽的高效手段。 ## Notable quotes > `00:00` 作为一名程序员，我从未感到自己像现在这样落后。 — Andrej Karpathy > `00:00` 很多人对 AI 的认知还停留在去年 ChatGPT 那种‘生成一段 JSON 或回答几个问题’的阶段，但大家必须以 12 月为基准重新看一次。 — Andrej Karpathy > `03:02` 这就是现在的编程范式：寻找那段最适合复制粘贴给 Agent 的核心文本指令。 — Andrej Karpathy > `04:47` 这个 App 根本就不应该存在！ — Andrej Karpathy > `06:40` 你可以想象这套体系完全颠倒过来——神经网络成为宿主主进程（Host Process），而 CPU 则反过来沦为为某些确定性任务打杂的协处理器（Co-processor）。 — Andrej Karpathy > `10:00` 我想去 50 米外的洗车店洗车，我应该开车去还是步行去？ — Andrej Karpathy > `20:00` 为什么会想到用邮箱地址去跨平台匹配资金？邮箱本来就是随意的、可以不同的，这种做法简直太诡异了。 — Andrej Karpathy > `22:15` 它确实能跑，但看起来恶心极了（it works, but it's just really gross）。 — Andrej Karpathy > `23:45` 我们制造的不是动物，而是在召唤幽灵（We are summoning ghosts）。 — Andrej Karpathy > `25:20` 为什么还在告诉我该怎么做？我根本什么都不想做！请直接告诉我应该把哪段文字复制粘贴给我的 Agent！ — Andrej Karpathy > `27:35` 你可以外包你的思考，但绝不能外包你的理解（You can outsource your thinking, but you can't outsource your understanding）。 — Andrej Karpathy ## Mentioned Andrej Karpathy, Stephanie Zhan, 红杉资本 (Sequoia Capital), OpenAI, Tesla, Eureka Labs, ChatGPT, OpenClaw, MenuGen, Gemini, Nano Banana, Vercel, Opus 4.7, Claude Code, Codex, Codex 5.4x High, LeetCode, Stripe, Google, PyTorch, NumPy, Pandas, microGPT ## Video description Andrej Karpathy (co-founder of OpenAI, former head of AI at Tesla, and now founder of Eureka Labs) talks with Sequoia partner Stephanie Zhan at AI Ascent 2026 about what's changed in the year since he coined "vibe coding." He explains why he's never felt more behind as a programmer, why agentic engineering is the more serious discipline taking shape on top of vibe coding, and why we should think of LLMs not as animals but as ghosts: jagged, statistical, summoned entities that require a new kind of taste and judgment to direct. He also touches on Software 3.0, the limits of verifiability, and why you can outsource your thinking but never your understanding. [Source](https://pscrb.fm/rss/p/traffic.megaphone.fm/CPUAI9375467036.mp3)

[0:00] Andrej Karpathy: 作为一名程序员，我从未感到自己像现在这样落后。 [0:00] Andrej Karpathy: 很多人对 AI 的认知还停留在去年 ChatGPT 那种‘生成一段 JSON 或回答几个问题’的阶段，但大家必须以 12 月为基准重新看一次。 [3:02] Andrej Karpathy: 这就是现在的编程范式：寻找那段最适合复制粘贴给 Agent 的核心文本指令。 [4:47] Andrej Karpathy: 这个 App 根本就不应该存在！ [6:40] Andrej Karpathy: 你可以想象这套体系完全颠倒过来——神经网络成为宿主主进程（Host Process），而 CPU 则反过来沦为为某些确定性任务打杂的协处理器（Co-processor）。 [10:00] Andrej Karpathy: 我想去 50 米外的洗车店洗车，我应该开车去还是步行去？ [20:00] Andrej Karpathy: 为什么会想到用邮箱地址去跨平台匹配资金？邮箱本来就是随意的、可以不同的，这种做法简直太诡异了。 [22:15] Andrej Karpathy: 它确实能跑，但看起来恶心极了（it works, but it's just really gross）。 [23:45] Andrej Karpathy: 我们制造的不是动物，而是在召唤幽灵（We are summoning ghosts）。 [25:20] Andrej Karpathy: 为什么还在告诉我该怎么做？我根本什么都不想做！请直接告诉我应该把哪段文字复制粘贴给我的 Agent！ [27:35] Andrej Karpathy: 你可以外包你的思考，但绝不能外包你的理解（You can outsource your thinking, but you can't outsource your understanding）。

[0:00] Andrej Karpathy: The agent has its own intelligence that it packages up, and then it kind of follows the instructions, and it looks at your environment, your computer, and it kind of performs intelligent actions to make things work... That's the programming paradigm now. [10:00] Andrej Karpathy: How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor 100,000 line code base or find zero-day vulnerabilities and yet tells me to walk to this car wash? This is insane. [10:00] I want to go to a car wash 50 meters away, should I drive or walk? [25:00] You can outsource your thinking, but you can't outsource your understanding.

[0:00] We're so excited for our very first special guest. He has helped build modern AI, then explain modern AI, and then occasionally rename modern AI. He actually helped co-found OpenAI right inside of this office, was the one who actually got autopilot working at Tesla back in the day, and he has a rare gift of making the most complex technical shifts feel both accessible and inevitable. You all know him for having coined the term vibe coding last year, but just in the last few months, he said something even more startling, that he's never felt more behind as a programmer. That's where we're starting today. Thank you, Andre, for joining us. Yeah, hello. Excited to be here and to kick us off. Okay, so just a couple months ago, you said that you've never felt more behind as a programmer. That's startling to hear from you of all people. Can you help us unpack that? Was that feeling exhilarating or unsettling? Yeah, a mixture of both for sure. Well, first of all, I guess like as many of you, I've been using agentic tools like lot code, adjacent things for a while maybe over the last year as it came out And it was very good at chunks of code And sometimes it would mess up and you have to edit them And it was kind of helpful And then I would say December was this clear point where for me I was on a break so I had a bit more time I think many other people are similar. And I just started to notice that with the latest models, the chunks just came out fine. And then I kept asking for more and it just came out fine. And then I can't remember the last time I corrected it. And then I just trusted the system more and more and then I was Vibcoding. And so it was kind of a...I do think that it was a very stark transition. I think that a lot of people actually...I tried to stress this on Twitter and or X because I think a lot of people experienced AI last year as ChatGPT or JSON thing, but you really had to look again and you had to look as of December because things have changed fundamentally and especially on this like agentic coherent workflow that really started to actually work. And so I would say that, yeah, it was just that realization that really had me go down their whole rabbit hole of just, you know, infinity site project. My site project's folder is like extremely full with lots of random things and just by coding all the time. So, yeah, that kind of happened in December, I would say And I was looking at the repercussions of that since Um you talked a lot about this idea of LLMs as a new computer that it isn just better software it a whole new computing paradigm And software 1.0 was explicit rules, software 2.0 was learned weights, software 3.0 is this. If that's actually true, what does a team build differently the day they actually believe this? Right, so, yeah, exactly. So, software 1.0, I'm writing code. Software 2.0, I'm actually programming by creating data sets and training neural networks. So, the programming is kind of like arranging data sets and maybe some objectives and neural network architectures. And then what happened is that basically, if you train one of these GPT models or LLMs on a sufficiently large set of tasks implicitly, because by training on the internet, you have to multitask all the things that are in the data set. These actually become kind of like a programmable computer in a certain sense. So software 3.0 is kind of about your programming now turns to prompting. And what's in the context window is your lever over the interpreter that is the LLM that is kind of like interpreting your context and performing computation in the digital information space. So I guess, yeah, that's kind of the transition. And I think there a few examples of that really drove it home for me and maybe that might instructive So for example when OpenClaw came out when you want to install OpenClaw you would expect that normally this is a bash script like a shell script. So run the shell script to install OpenClaw. But the thing is that in order to target lots of different platforms and lots of different types of computers you might run in OpenClaw, these shell scripts usually balloon up and become extremely complex. But the thing is, you're still stuck in a software 1.0 universe of wanting to write the code. And actually, the OpenClaw installation is a copy-paste of a bunch of text that you're supposed to give to your agent. So basically, it's a little skill of copy-paste this and give it to your agent, and it will install OpenClaw. And the reason this is a lot more powerful is you're working now in the software 3.0 paradigm where you don't have to precisely spell out all the individual details of that setup. The agent has its own intelligence that it packages up, and then it kind of follows the instructions, and it looks at your environment, your computer, and it kind of performs intelligent actions to make things work and debug things in the loop. And it's just like so much more powerful, right? So I think that's a very different kind of like way of thinking about it. It's just like what is the piece of text to copy paste to your agent? That's the programming paradigm now. I think one more maybe example that comes to mind that is even more extreme than that is when I was building Menugen. So Menugen is this idea where you... [5:00] You come to a restaurant, they give you a menu, there's no pictures usually, so I don't know what any of these things are. Usually, like 30% of the things, I have no idea what they are, 50%. So I wanted to take a photo of the restaurant menu and to get pictures of what those things might look like in a generic sense. And so I built, I videcoded this app that basically lets you upload a photo, and it does all this stuff, and it runs on Vercel, and it basically re-renders the menu, and it gives you all the items, and it gives you a picture that it uses an image, generator 4 to basically OCR all the different titles, use the image generator to get pictures of them, and then shows it to you. And then I saw the software 3.0 version of this, which blew my mind, which is literally just take your photo, give it to Gemini, and say, use Nano Banana to overlay the things onto the menu. And Nano Banana basically returned an image that is exactly the picture of the menu that I took, but it actually put into the pixels, it rendered the different things in the menu. And this blew my mind because actually all of my menu gen is spurious. It's working in the old paradigm. That app shouldn't exist. And yeah the software three paradigm is a lot more kind of raw It just your neural network is doing more and more of the work and your prompt or context is just the image and the output is an image and there no need to have any of the app in between So I think that people have to kind of like reframe, you know, not to work in the existing paradigm of what things existed and just think about it as a speed up of what exists. It's actually like new things are available now. And going back to your programming question, it's not even, I think that's also an example of working in the old mindset because it's not just about programming and programming becoming faster. This is more general information processing that is automatable now. So it's not just even about code. So previous code worked over kind of like structured data, right? And you write code over structured data. But like for example, with my LLM knowledge basis project, basically you get LLMs to create wikis for your organization or for you in person, et cetera. This is not even a program. This is not something that could exist before because there was no code that would create a knowledge base based on a bunch of facts. But now you can just take these documents and basically recompile them in a different way and reorder them and create something that is new and interesting as a reframing of the data. And so these are new things that weren possible And so I think this is something that I keep trying to get back to as to not only what can we do that existed that is faster now but I think there new opportunities of just things that couldn be possible before And I almost think that that's more exciting. I love the menu gen progression and dichotomy that you laid out. And I think even I'm sure many folks here followed your own progression of programming from last October to early January, February this year. If you extrapolate that further, what is the 2026 equivalent for building websites in the 90s, building mobile apps in the 2010s, building SaaS in the last cloud era? What will look completely obvious in hindsight that is still mostly unbuilt today? Well, going with the example of Menugen, I guess, so a lot of this code shouldn't exist and it's just neural network doing most of the work. I do think that the extrapolation looks very weird because you could basically imagine... I don't think... Yeah, so you could imagine completely neural computers in a certain sense. You feed raw videos. Like, imagine a device. It takes raw videos or audio into basically what's a neural net and uses diffusion to render a UI that is kind of like, you know, unique for that moment in a certain sense. And I kind of feel like in the early days of computing actually people are a little bit confused as to whether computers would look like calculators or computers would look like neural nets And in the 50s and 60s it was not really obvious which way it would go And, of course, we went down the calculator path and ended up building classical computing. And then neural nets are currently running virtualized on existing computers. But you could imagine, I think, that a lot of this will flip and that the neural net becomes kind of like the host process. And the CPU has become kind of like the co-processor. So we saw the diagram of, you know, intelligence compute is going to, of neural networks is going to take over and become the dominant spend of flops. So you could imagine something really weird and foreign when, where neural nets are doing most of the heavy lifting, they're using tool use as just like, you know, historical appendage for some kinds of like deterministic tasks. But what's really running the show is these neural nets that are networked in a certain way. So you can imagine something extremely foreign as the extrapolation. But I think we're gonna probably get there piece by piece. And that progression is TBD, I would say. I'd love to talk a little bit about this concept of verifiability. The fact that AI will automate faster and more easily domains where the output can be verified. If that framework is right, what work is about to move much faster than people realize? And what professions do we have that people actually think are safe? [10:00] but they're actually highly verifiable. Yeah, so I spent some time writing about verifiability and basically like traditional computers can easily automate what you can specify in code and kind of this latest round of LLMs can easily automate what you can verify in a certain sense. Because the way this works is that when Frontier Labs are training these LLMs, these are giant reinforcement learning environments, so they are given verification rewards. And then because of the way that these models are trained, end up basically progressing and creating these like jagged entities that really peak in capability in kind of like verifiable domains like math and code and adjacent and kind of like stagnate and are a little bit, you know, rough around the edges when things are not kind of like in that space. So I think the reason I wrote about verifiability is I'm trying to understand why these things are so jagged. And some of it has to do with how the labs train the models but I think some of it also has to do with the focus of the labs and what they happen to put into the data distribution. Because some things basically are significantly more valuable in economy and end up creating more environments because the labs wanted to work in those settings. So I think code is a good example of that. There's probably lots of verifiable environments that you could think about that happen not to make it into the mix because they just not that useful to have the capability around But I think to me the big I guess like the big mystery is the favorite example for a while was that how many letters R are in a strawberry and the models would famously get this wrong and it's an example of jackedness. The models now patch this I think but the new one is I want to go to a car wash to wash my car and it's 50 meters away, should I drive or should I walk? And state of the art models today will tell you to walk because it's so close. How is it possible that state of the art Opus 4.7 will simultaneously refactor 100,000 line code base or find zero-day vulnerabilities and yet tells me to walk to this car wash? This is insane. And to whatever extent these models remain jagged, it's an indication that, number one, maybe something slightly off. Or number two, you need to actually be in the loop a bit and you need to treat them as tools and you do have to kind of stay in touch with what they're doing. And so I think all of my writing, long story short about verifiability, just trying to understand why these things are jacked, is there any pattern to it? And I think it some kind of a combination of verifiable plus labs care Maybe one more anecdote that is instructive is from GPT 3 to GPT 4 people noticed that chess improved a lot And I think a lot of people thought oh well it just a progression of the capabilities But actually it more that I think this is public information I think I saw it on the internet. A huge amount of like data of chess made it into the pre-chaining set. And just because it's in the data distribution, basically, the model improved a lot more than it would just by default. So someone at OpenAI decided to add this data and now you have a capability that just peaked a lot more. And so that's why I think I'm stressing this dimension of it as we are slightly at the mercy of whatever the labs are doing, whatever they happen to put into the mix. And you have to actually explore this thing that they give you that has no manual. And it works in certain settings but maybe not in some settings. And you have to kind of explore it a little bit. And if you're in the circuits that were part of the RL, you fly. And if you're in the circuits that are out of the data distribution, you're going to struggle. And you have to kind of figure out which circuits you're in, in your application. And if you're not in the circuits, then you have to really look at fine tuning and doing some of your own work because it's not going to necessarily come out of the LLM, out of the box. I love to come back to the concept of jagged intelligence in a little bit If you were a founder today and thinking about building a company you are trying to solve a problem that you think is tractable something that is a domain that is verifiable But you look around and you think, oh, my gosh, well, the labs have really, really started getting to escape velocity in the ones that seem most obvious, math, coding, and others. What would your advice be to the founders in the audience? So I think maybe that comes to the previous question of, I do think that verifiability because it, let me think, so verifiability makes something tractable in the current paradigm because you can throw a huge amount of RL at it. So maybe one way to see it is that that remains true even if the labs are not focusing on it directly. So if you are in a verifiable setting where you could create these RL environments or examples, then that actually sets your you have to potentially do your own fine tuning and you might benefit from that. But that is fundamentally technology that just works. You can pull a lever. If you have a huge amount of diverse data sets of RL environments, et cetera, you can use your favorite fine tuning framework and pull the lever and get something that actually works pretty well. So I don't know what the examples of this might be. But I do think there are some very valuable reinforcement learning environments that people could think of that I think are not part of [15:00] Yeah, I don't want to give away the answer, but there is one domain that I think is very... Oh, okay, sorry. I don't mean to vague post on the stage, but there are some examples of this. On the flip side, what do you think still feels automatable, only from a distance? I do think that ultimately, almost everything can be made verifiable to some extent. Some things easier than others. Because even for things like writing or so on, You can imagine having a council of LLM judges and probably get something reasonable from this kind of an approach. So it's more about what's easy or hard. So I do think that ultimately, yeah, I think... Everything. Everything is automatable. Amazing. Okay. So last year you coined the term vibe coding, and today we're in a world that feels a little bit more serious, more organic engineering. What do you think is the difference between the two? and what would you actually call what we're in today? Yeah, so I would say VibeCoding is about raising the floor for everyone in terms of what they can do in software. So the floor rises, everyone can VibeCode anything, and that's amazing, incredible. But then I would say agentic engineering is about preserving the quality bar of what existed before in professional software So you not allowed to introduce vulnerabilities due to Vibe coding You are still responsible for your software just as before but can you go faster And spoiler is, you can, but how do you do that properly? And so to me, agentic engineering, I call it that because I do think it's kind of like an engineering discipline. You have these agents, which are these like spiky entities. They're a bit fallible, a little bit stochastic, but they are extremely powerful. and it's how do you coordinate them to go faster without sacrificing your quality bar? And doing that well and correctly is the realm of agentic engineering. So I kind of see them as different. Like one is about maybe raising the floor and the other is about extrapolating. And what I'm seeing, I think, is there is a very high ceiling on agentic engineer capability. And people used to talk about the 10x engineer previously. I think that this has magnified a lot more. 10x is not the speed up you gain. And I think it does seem to me like people who are very good at this peak a lot more than 10x from my perspective right now. I really like that framing. One thing that when Sam Allman came to AI Ascent last year, one memorable thing he said was that people of different generations use ChatGPT differently So if you in your 30s you use it as a Google search replacement But if you in your teens ChatGPT is your gateway to the Internet What is the parallel here in coding today? If we were to watch two people code using open clock, cloud code, codex, one you'd consider mediocre at it and one you would consider fully AI native, how would you describe the difference? I mean, I think it's just trying to get the most out of the tools that are available, utilizing all of their features, investing into your own kind of setup. So just like previously, all the engineers are used to basically getting the most out of the tools you use. Either it's Vim or VS Code or now it's, you know, Clothcode or Codex or so on. So just investing into your setup and utilizing a lot of the, you know, tools that are available to you. And I think it just kind of looks like that. I do think that maybe related thought is a lot of people are maybe hiring for this, right, because they want to hire strong agentic engineers. I do think that what I seeing is that the you know most people are still not refactored their hiring process for agentic engineer capability right Like if you giving out puzzles to solve then this this is still the old paradigm I would say that hiring has to look like give me a really big project and see someone implement that big project. Like let's write, say, a Twitter clone for agents and then make it really good, make it really secure, and then have some agents simulate some activity on this Twitter. And then I'm going to use 10 codecs 5.4x high to try to break your website that you deployed, and they're going to try to basically break it, and they should not be able to break it. And so maybe it looks like that, right? And so, yeah, watching people in that setting and building bigger projects and utilizing the tooling is maybe what I would look at for the most part. And as agents do more, what human skill do you think becomes more valuable, not less? So, yeah, it's a good question. I think, well, right now the answer is that the agents are catalog these intern entities, right? So it's remarkable. You basically still have to be in charge of the aesthetics, the judgment, the taste, and a little bit of oversight. Maybe one of my favorite examples of like the weirdness of agents is for Menugen. You sign up with a Google account, but you [20:00] who purchase credits using a Stripe account, and both of them have email addresses. And my agent actually tries to basically, like when you purchase credits, it assigned it using the email address from Stripe to the Google email address. Like there wasn't a persistent user ID for people. It was trying to match up the email addresses, but you could use different email address for your Stripe and your Google, and basically would not associate the funds. And so this is the kind of thing that these agents still will make mistakes about. It's like, why would you use email addresses to try to cross-correlate the funds? They can be arbitrary. You can use different emails, et cetera. Like, this is such a weird thing to do. So I think people have to be in charge of this spec, this plan. And I actually don't even like the plan mode. I would, I mean, obviously, it's very useful. But I think there's something more general here where you have to work with your agent to design a spec that is very detailed. And maybe it's basically the docs and then get the agents to write them. And you're in charge of the oversight and the top level categories, but the agents are doing a lot of the under the hood. And so I think you're not caring about some of the details. So as an example also with arrays or tensors in neural networks there a ton of details between PyTorch and NumPy and all the different like pandas and so on for all the different little API details And I already forgot about the keep dims versus keep dim or whether it dim or axis or reshape or permute or transpose I don remember this stuff anymore, right? Because you don't have to. This is the kind of details that are handled by the intern because they have very good recall. But you still have to know, for example, that there's underlying tensor, there's an underlying view, and then you can manipulate view of the same storage or you can have different storage which will be less efficient. And so you still have to have an understanding of what this stuff is doing and some of the fundamentals so that you're not copying memory around unnecessarily and so on. But the details of the APIs are not handed off. So you're in charge of the taste, the engineering, the design, and that it makes sense and that you're asking for the right things and that you're saying that, okay, these have to be unique user IDs that we're going to tie everything to. And so you're doing some of the design and development and the engineers are doing the fill in the blanks. And that's currently kind of like where we are. And I think that's what everyone, of course, is seeing, I think, right now. Do you think there's a chance that this taste and judgment matters less over time, or will the ceiling just keep rising? Yeah, it's a good question. I would say I mean I hoping that it improves I think probably the reason it doesn improve right now is again it not part of the RL There probably no aesthetics cost or reward or it not good enough or something like that. I do think that when you actually look at the code, sometimes I get a little bit of a heart attack because it's not like super amazing code necessarily all the time. It's very bloaty and there's a lot of copy-paste and there's awkward abstractions that are brittle and like it works, but it's just really gross. And I do hope that this can improve in future models. A good example also is this micro GPT project, which I was trying to simplify LLM training to be as simple as possible. The models hate this. They can't do it. I tried to, I kept trying to prompt an LLM to simplify more, simplify more, and it just can't. You feel like you're outside of the RL circuits. It feels like you're obviously, you know, you're pulling teeth. It's not like light speed. So I do think that people still remain in charge of this. But I do think that there's nothing fundamental, again, that's preventing it. It's just the labs haven't done it yet, almost. Yeah. So I'd love to come back to this idea of jagged forms of intelligence. You wrote a little bit about this with a very thought provoking piece around animals versus ghosts And the idea is that we not building animals We are summoning ghosts And these are jagged forms of intelligence that are shaped by data and reward functions but not by intrinsic motivation or fun or curiosity or empowerment, things that kind of came about via evolution. Why does that framing matter, and what does it actually change about how you build and deploy and evaluate or even trust them? Yeah, so, yeah, I think the reason I wrote about this is because I'm trying to wrap my head around what these things are, right? Because if you have a good model of what they are or are not, then you're going to be more competent at using them. And I do think that, I don't know if it has, I'm not sure if it actually has like real power. I think it's a little bit of philosophizing. But I do think that, I think it's just coming to terms with the fact that these things are not animal intelligences. Like if you yell at them, they're not going to work better or worse or it doesn't have any impact. And it's all just kind of like these statistical simulation circuits where the substrate is pre-training, so statistics. But then there's RL bolting on top, so it kind of like increases the appendages. [25:00] Maybe it's just kind of like a mindset of what I'm coming into or what's likely to work or not likely to work or how to modify it. But I don't actually, I don't know that I have like, here are the five obvious outcomes of how to make your system better. It's more just being suspicious of it and figuring it out over time. That's where it starts. Okay, so you are so deep in working with agents that don't just chat. They have real permissions. They have local context. They actually take action on your behalf. What does the world look like when we all start to live in that world? Yeah, I think a lot of people probably here are excited about what this native agentic environment looks like. And everything has to be rewritten. Everything is still fundamentally written for humans and has to be moved around. Most of the time when I use different frameworks or libraries or things like that, they still have docs that are fundamentally written for humans. This is my favorite pet peeve. Why are people still telling me what to do? I don't to do anything, what is the thing I should copy paste to my agent? So it's just every time I told go to this URL or something like that it just like oh So everyone is I think excited about how do we decompose the workloads that need to happen into fundamentally sensors over the world actuators over the world How do we make it agent-native? Basically, describe it to agents first. And then have a lot of automation around, you know, the, yeah, around data structures that are very legible to the LLMs. So I think, yeah, I'm hoping that there's a lot of agent-first infrastructure out there And that for Menugen, famously, when I wrote the, I'm not sure how famously, but when I wrote the blog post about Menugen, a lot of the work, a lot of the trouble was not even writing the code for Menugen, it was deploying it on Vercel because I had to work with all these different services and I had to string them up and I had to go to their settings and the menus and configure my DNS and it was just so annoying. And so that's a good example of I would hope that Menugen, that I could give a prompt to an LLM, build Menugen, and then I didn't have to touch anything and it's deployed in that same way on the internet. I think that would be a good kind of a test for whether or not a lot of our infrastructure is becoming more and more agent native. And then ultimately I would say yeah I do think we going towards a world where there agent representation for people and for organizations And I have my agent talk to your agent to figure out some of the details of our meetings or things like that So I do think that that's roughly where things are going. But, yeah, I think everyone here is excited about that. I really like the visual analogy of sensors and actuators. I actually hadn't thought about that. It's super interesting. Right. Okay, I think we have to end on a question about education. because you are probably one of the very best in the world at making complex technical concepts simple and deeply thoughtful about how we design education around it. What still remains worth learning deeply when intelligence gets cheap as we move into the next era of AI? Yeah. There was a tweet that blew my mind recently, and I keep thinking about it like every other day. It was something along the lines of you can outsource your thinking, but you can't outsource your understanding. And... I think that's really nicely put. So, yeah, because I still...I'm still part of the system and I still have to...somehow information still has to make it into my brain. And I feel like I'm becoming a bottleneck of just even knowing what are we trying to build why is it worth doing how do I direct my agents and so on So I do still think that ultimately something has to direct the thinking and the processing and so on And that still kind of fundamentally constrained somehow by understanding. And this is one reason I also was very excited about all the LLM knowledge bases. Because I feel like that's a way for me to process information. And any time I see a different projection onto information, I always feel like I gain insight. So it's really just a lot of prompts for me to do synthetic data generation kind of over some fixed data. So I really enjoy, whenever I read an article, I have my wiki that's being built up from these articles, and I love asking questions about things. And I think that ultimately these are tools to enhance understanding in a certain way. And this is still kind of like a bit of a bottleneck because then you can't direct the, you can't be a good director if you still, because the LLNs certainly don't excel at understanding. You still are uniquely in charge of that. So yeah, I think tools to that effect, I think, are incredibly interesting and exciting. I'm excited to be back here in a couple of years and to see if we've been fully automated out of the loop. And they actually take care of understanding as well. Thank you so much for joining us, Andre. I really appreciate it.