Factory Chief Predicts Open AI Models Will Win Most Enterprise Software Code

Factory负责人预测开放AI模型将赢得大部分企业软件代码 随着开放权重模型以极低成本达到上一代性能，异步编程智能体将处理90%的开发Token。 Matan Grinberg详细讲述了Factory的发展历程：从早期的“沙漠之旅”——包括退还200万美元收入以专注于真正产品质量的激进决定——到发布其Droid CLI。他指出，与模型无关的多模型接入架构能防止过拟合和供应商锁定，并预测随着企业推行成本合理化与动态提示词路由，像GLM这样的开放权重模型将占据大部分Token份额。最终，Grinberg描绘了这样一个未来：90%的软件生成将在自主运行的“黑灯工厂”中异步进行，从而让人类工程人才得以重新调配去解决具有高影响力的现实世界问题。 Factory 视客户痴迷为输入指标而非终极目标，其真正目标是打造一款足够优秀、能让客户主动为其痴迷的产品。 (0:00) 企业客户强烈抵制模型厂商锁定与单点故障风险，促成了对支持热插拔前沿模型与开源权重的模型无关 Harness 架构的需求。 (0:00) 意识到早期近 200 万美元的营收依赖于销售愿景而非产品驱动后，Factory 主动退还全部收入以化解客户流失的“定时炸弹”，并在 2025 年 9 月推出深入终端工作流的 Droid CLI 走出低谷。 (5:00) Factory Router 支持基于角色、旧系统架构及多模型验证策略的动态 Prompt 路由，有效解决了企业从“疯狂刷 Token”向成本合理化转型的浪费难题。 (25:00) 随着 GLM 等开源权重模型以极低成本达到“前沿减一”性能，其 Token 消耗占比已进入双位数并预计将占据绝大多数规模，同时未来 90% 的编程 Token 将在全自动的“黑灯工厂”中异步运行。 (30:00)

Matan Grinberg, co-founder and CEO of Factory, argues that software engineering is transitioning from prompt-driven coding assistance to autonomous, multi-model 'dark factories' that execute workflows independently without lock-in to single frontier model providers. Avoiding Vendor Lock-in with Model-Agnostic Harnesses (0:00) Enterprises adopting AI coding agents resist single-provider dependence, having learned from cloud platform pricing hikes driven by data gravity. According to Grinberg, frequent leadership turmoil and public conflicts at frontier model laboratories make engineering leaders favor hot-swappable, modular architectures over proprietary platforms. To alleviate customer concerns about replacing frontier provider lock-in with platform lock-in, Factory keeps skills registries, automations, and tribal artifacts directly inside customer repositories. Early Product Pitfalls and the Shift to CLI (5:00) Factory initially struggled by offering fully autonomous agents in April 2023, well before developers or enterprise workflows were ready for unassisted code generation. Although enterprise sales expanded to nearly $2 million, product adoption fell short of creating genuine developer obsession. Recognizing the risk of impending customer churn, Grinberg decided to return roughly $2 million in revenue to enterprise clients, reset company revenue to zero, and retain his 20-person team through the downturn. Multi-Model Harnesses and Dynamic Token Routing (20:00) Grinberg disputes the notion that co-designing models and harnesses produces better agents, asserting that exposing harnesses to multiple model families prevents provider-specific overfitting. In benchmark tests such as TerminalBench, model families exhibit distinct behavioral quirks: Claude Code models often require explicit tracking lists to prevent drift, whereas Codex models show natural persistence. Factory utilizes this variation through the Factory Router, which dynamically steers prompts by task complexity, compliance policies, or model efficiency. Changing Token Economics and the Rise of Open Weights (30:00) Enterprise consumption of open-weight models grew from single digits in early 2026 into double digits, with Factory routing approximately half its internal tokens to models like GLM 5.2. Grinberg expects open models to capture the vast majority of routine implementation tasks, while frontier models handle a high-leverage tier representing roughly 1% of tokens. He advises enterprises against training in-house coding models, emphasizing that capital is better deployed buying specialized infrastructure and treating token budgets like targeted departmental headcount. The Dark Factory and Industrialized Software Assembly Over the next 12 to 24 months, Grinberg anticipates AI development will shift from human-initiated synchronous prompting to roughly 90% asynchronous execution. Modeled after automated manufacturing, these 'dark factories' will deploy agents to autonomously process user feedback, patch issues, and assemble software updates without live manual oversight. He contends that while AI automation will trigger short-term workforce friction, codifying enterprise workflows will ultimately redirect engineering talent toward high-impact domains like public sector systems and pharmaceutical research. Grinberg acknowledges that shifting enterprise software production to autonomous workflows will introduce near-term labor market disruption, placing the burden on AI leaders to compress this transition smoothly while enterprises develop rigorous automated validation tests to govern autonomous agents.

Factory 联合创始人兼首席执行官 Matan Grinberg 认为，软件工程正从人类驱动的同步对话转向全自动化的“黑灯工厂”模式；在此演进中，企业唯有摆脱对单一前沿大模型的锁定，借助模块化底座与动态路由，才能在控制成本的同时实现软件研发的工业化交付。 从极早期挫折到落地终端的工作流转向 (0:00) Factory 于 2023 年 4 月开始研发用于软件开发的全自主智能体“Droids”，但在早期遭遇了开发者习惯和企业采购的现实脱节。Grinberg 回忆，当时过早押注全自主架构相当于“过早即是错误”，尽管团队一度将销售额推至近 200 万美元，但由于产品未能真正激发开发者的使用热情，公司主动向客户退还了几乎全部款项并重置收入至零。这一激进决策在维持团队信用的同时，逼迫团队重构产品交互路线。2025 年 9 月 26 日，Factory 推出了 Droid CLI，不再强求开发者瞬间跨越到完全自主的后台运行，而是将模型无关的底座无缝切入工程师现有的命令行终端工作流中，从而平滑了采纳门槛。 多模型底座与防范厂商绑定的架构优势 (20:00) 基于历史上云厂商借助“数据重力”在后期大幅提价的教训，企业如今极度警惕模型厂商的锁定风险以及前沿实验室内部的动荡。Grinberg 指出，Factory 坚持将内部知识库、技能注册表和自动化脚本等资产直接保留在客户自己的代码库中以确保透明度。同时，他反驳了“模型与应用底座必须协同设计”的传统看法，强调统一的底座通过对接多种不同性格的模型（如 Claude 的松散与 GPT 的高执行力），能够有效避免对特定厂商特性的过度拟合。配合提示词缓存（使 Token 成本降至十分之一）和长上下文压缩技术，多模型底座在前沿模型迭代时展现出比单一厂商封闭环境更优越的迁移能力与稳定性。 企业采纳演进与动态路由的经济学 (25:00) 企业引入 AI 编程正经历从早期的质疑、董事会施压，演变到强制指标驱动的“Token 滥用”（例如员工调用顶级模型 Opus 询问天气或简单 Python 知识），并最终迈入成本理性化阶段。为了应对高额账单，Factory 研发了动态路由机制，根据代码库类型、任务复杂度与自然语言策略动态分派模型：例如简单仪表板开发交由 Gemini Flash，传统 COBOL 代码维护路由至专用微调模型，而关键架构任务才分配昂贵的前沿模型。随着开源权重模型（如 GLM 5.2）与上一代前沿基准逼近，企业端开源 Token 消耗占比已从 2026 年初的个位数跃升至两位数。Grinberg 预测，低成本开源模型将占据绝大部分 Token 用量，而顶级前沿模型将退守至约 1% 的高杠杆决策节点。 软件工厂工业化与成果定价的远景 (33:00) 目前大型机构的软件研发仍类似“前工业时代”，数千人协作往往依赖资深老手的默会知识，且难以量化代码与商业回报的关系。Factory 的长远设想是将其转化为如汽车装配线般的规范体系。Grinberg 预计，尽管当前企业仍采用基于 Token 消耗的用量计费，但到 2030 年代商业模式或将转变为成果导向的市场竞价机制：工程师定义严格的任务边界与自动化验证测试套件，由各模型实验室竞价承包并在失败时自负亏损。这种模式将倒逼开发人员编写极高标准的测试规则，彻底杜绝智能体为强行通过检测而恶意删改代码等失控行为。 迈向 90% 异步执行的软件黑灯工厂 受特斯拉自动化制造车间的启发，Grinberg 预测在未来的 12 至 24 个月内，AI 编程将从目前高度依赖人类即时提示词的同步模式，转变为 90% 任务在夜间无人状态下自发完成的“黑灯工厂”。智能体将自主监听并分析用户反馈信号，直接完成代码编写、漏洞修复与初版功能产出。尽管短期内整个行业会经历企业冗员调整与资源重组的阵痛，但从长期来看，AI 释放出的顶级系统工程思维人才将外溢至医药研发、疾病治疗和老旧公共系统现代化等长期被忽视的关键领域，从而大幅扩展软件能够解决的人类现实问题范畴。 Grinberg 总结强调，非科技类企业应专注核心业务，避免耗费巨资自研专用编程智能体，而应直接采购通用底座并通过黑客松与容错文化促进内部采纳。不过，成果导向市场能否完全成熟，仍取决于自动化验证机制是否足够严谨，以及企业能否在组织架构上顺利完成从工时导向到 Token 预算导向的定量权力分配。

## Background 本期节目由红杉资本（Sequoia Capital）于 2026 年 7 月 21 日在音频及网络平台发布，由红杉合伙人 Sonya Huang 与 Pat Grady 共同主持。节目围绕 Factory 联合创始人兼首席执行官 Matan Grinberg 的创业历程展开，深入探讨了 Factory 如何从提前两年的“荒漠跋涉”与退还全部客户营收的至暗时刻中涅槃重生，以及为何模型无关的 Harness 架构、开源模型与 90% 异步运行的“黑灯工厂”将彻底重构软件开发体系。 ## TL;DR Factory 创始人兼 CEO Matan Grinberg 深度复盘了公司从 2023 年过早押注全自主编程智能体、在产品未能让客户痴迷时毅然退还近 200 万美元收入，再到通过终端原生工具 Droid CLI 实现突破的历程。他提出了反直觉的技术主张：相比模型实验室推崇的专有协同设计，模型无关（Model-Agnostic）的 Harness 能在多样化生态中避免过拟合，具备更强的鲁棒性与成本套利优势。此外，他指出企业 AI 采用正从狂热的“Token 卷王”走向理性治理，未来 CIO 衡量 Token 将如衡量员工编制，而整个软件工程将迈入 90% 异步运行的“黑灯工厂”，将人类最优秀的系统思维者解放出来去攻克生物制药等关乎文明命运的重大难题。 ## Atmosphere & style 整场对话兼具硬核的技术思辨深度与毫无保留的创业坦诚感。Matan 用“赛艇运动的纯粹痛苦”与“全员大会上的面色惨白”直面至暗时刻，语言沉着、冷静而极其真诚，与主持人的高频互动碰撞出密集的智力火花。从“爱因斯坦做代数家教”到美剧《广告狂人》式的凭感觉决策，对话中穿插了大量极具洞察力的犀利隐喻，既破除了当下对前沿闭源模型的盲目迷信，又洋溢着对未来软件工业化与智力资源重组的宏大理想主义情怀。 ## Bulletin - `05:00` Factory 创立初期因全自主 Coding Agent 超前于市场且未让开发者产生痴迷，毅然将近 200 万美元的合同收入原路退还客户，团队在经历收入归零的阵痛后全员留任并完成技术重构。 - `18:24` 针对行业推崇的模型与框架协同设计，Factory 提出反直觉论点：适配多模型的模型无关（Model-Agnostic）运行框架因避免了对单一模型的过拟合，其泛化能力与综合基准表现反而超越单一厂商的专有绑定组合。 - `27:30` 开源权重模型（如 GLM 5.2）已稳达“顶尖减一代”（Frontier minus one）水平并承担了 Factory 内部近半数 Token 负载；企业正告别滥用旗舰模型的“Token 卷王”阶段，转向由自然语言策略驱动的动态成本路由。 - `46:09` 当前软件开发工具仍依赖人类主动唤醒的同步模式，Matan Grinberg 预测未来 12 到 24 个月内 90% 的编程 Token 将转为后台自主感知与修复缺陷的异步运行，开启软件自构建的“黑灯工厂”（Dark Factory）。 ## Key takeaways - `00:00` 颠覆亚马逊“以客户为中心”：对客户表面上的痴迷仅是输入指标，企业真正应衡量的是能否造出让客户反过来对产品产生痴迷的“输出指标”。 - `00:46` 企业对模型供应商锁定的防御心理：经历过云计算厂商先补贴后涨价十倍的创伤，企业极度渴求中立、模块化且可热插拔不同底层模型的 Agent 架构，以规避单点故障与治理动荡。 - `05:00` 超前两三年在商业上等同于做错：全自主 Agent 理念在 2023 年严重脱离了开发者心智；Factory 宁可顶着巨大的内部与投资人压力退还 200 万美元营收，也坚决不在未达标准的产品上透支信任。 - `13:46` Droid CLI 的破局路径：2025 年 9 月推出的终端命令行工具迎合了开发者的既有工作流，叠加 Andrej Karpathy 等意见领袖对 Agentic 工作流的公开认可，终于瓦解了工程师群体的心理防线。 - `16:47` 评测基准生命周期的极速缩水：SWE-bench 局限于单文件代码修复，而更具工程实战意义的 TerminalBench 也在 3 到 6 个月内被各大模型刷爆并吸纳进训练集，基准区分度快速衰减。 - `18:24` 优秀 Harness 的核心工程指标：Token 缓存命中率直接决定十倍成本差异，而长上下文压缩与精简时能否像“大海捞针”般无损保留关键架构信息，是衡量运行框架优劣的分水岭。 - `20:00` 打破协同设计（Co-design）迷思：“模型之于 Harness，正如数据之于模型”，暴露给更多异构模型的通用框架能汲取不同模型的优缺点，比针对单一模型过度优化的专有框架更具鲁棒性。 - `23:00` 企业 AI 采用的四个演化阶段：历经怀疑期、董事会施压共识期、CTO 强制纳入绩效的指标期，以及盲目调用高阶模型的“Token 卷王期”，企业算力采购正迎来成本理性化洗牌。 - `25:00` Factory Router 与算力编制化治理：未来 CIO 必须像论证新增员工编制一样严审 Token，利用自然语言规程将原型搭建、遗留系统维护和高可靠流水线精准分流至不同梯度的模型。 - `27:30` “爱因斯坦做代数家教”的智力分配隐喻：开源模型达到“顶尖减一代”水平即可高效低成本搞定绝大多数常规工程，企业无需为了基础代数题而盲目支付前沿旗舰模型的昂贵溢价。 - `30:00` Token 份额与杠杆份额的本质分流：长期来看开源模型可能吞下绝大多数低风险代码实现的 Token，但决定核心商业成败的前 1% 高阶推理任务仍牢牢掌握在闭源前沿智能手中。 - `32:51` 从用量计费向基于成果的“竞价市场”演进：按席位付费已不适用，未来模型厂商将围绕特定工程任务和自动化验证回路进行一口价竞标，自行承担推理毛利风险。 - `37:42` 告别软件研发的“广告狂人时代”：每家公司本身都是一个复杂的神经网络，企业绝不能再靠拍脑袋决定预算，必须依靠严谨的数学模型测算每一笔 Token 与研发投入的反向传播产出。 - `40:00` 算力杠杆与企业核心能力的冷酷聚焦：销售等关系型业务无法通过堆叠 Token 放大，而工程业务具备极高算力杠杆；AI 浪潮倒逼非科技企业放弃自研 Agent 的虚荣，彻底回归核心业务。 - `46:09` 迈向 90% 异步运行的“黑灯工厂”：未来的软件工程将脱离需人类频繁交互的 Co-pilot 模式，转变为智能体后台全天候监控、自动排查并提交首版修复的无人值守工业化流水线。 - `48:33` 顶尖工程力量的全球资源再配置：自主编程不会消灭工程师，而是将全球最优秀的系统思维者从繁琐重复的常规代码中解放出来，全力攻坚医药研发等关乎人类命运的重大深层挑战。 ## Detailed walkthrough ### `00:00` 重新定义“客户至上”：从输入指标到输出指标 访谈在红杉资本（Sequoia Capital）的录音室展开，红杉合伙人 Sonya Huang 与 Pat Grady 迎来了 Factory 联合创始人兼首席执行官 Matan Grinberg。这是 Matan 第二次做客该播客，跻身少数多次受邀的“精英访客”之列。Factory 致力于打造名为“Droids”的自主软件开发 Agent（智能体）。节目开篇，Matan 便抛出了一个反常规的商业理念：颠覆亚马逊创始人 Jeff Bezos 著名的“以客户为中心/痴迷客户”（Customer Obsession）。 在 Matan 看来，Bezos 所说的“痴迷客户”在本质上只是一个“输入指标”（Input Metric），而衡量输入指标往往是徒劳的。企业哪怕表现得极度痴迷客户，但如果做出来的东西让对方反感，甚至可能沦落到“对方不得不对你申请限制令”的尴尬境地。Factory 追求的是真正的“输出指标”（Output Metric）——制造出极其优秀的产品，反过来让客户对 Factory 产生痴迷。他打了个生动的比方：篮球教练在球员上场前，绝对不会交代“大家上场后一定要多流汗”，而是会要求“去得分！把分给我拿下来！”在拼尽全力得分的过程中，球员自然会流汗；同样地，要造就真正痴迷于产品的客户，团队自身固然也需要极度专注，但最终决定成败的唯有“得分”这一实际产出。 - **核心观点**：不要追踪输入指标（如团队付出了多少努力、是否表面上痴迷客户），唯一重要的是最终产出（产品是否优秀到让客户对你产生痴迷）。 - **Droids**：Factory 打造的核心产品，用于辅助乃至主导软件开发全流程的自主智能体。 --- ### `00:46` 穿越两年荒漠：模型中立性与企业对供应商锁定的警惕 面对市场上 CloudCode、Cognition 等先行者的竞争，主持人好奇作为“黑马”的 Factory 究竟有何独特优势。Matan 回顾了创业历程：Factory 创立于三年半前的 2023 年 4 月。彼时，整个市场乃至大企业甚至都还没完全接纳 GitHub Copilot，更遑论全自主的软件工程 Agent。回望最初那两年，Matan 形容那是一场“穿越荒漠的漫长旅程”（Journey in the Desert）。当时工程师的心智尚未就绪，企业采购团队更是毫无准备，但团队在这段荒原期内深度打磨了工艺，真正搞懂了企业级开发者的核心诉求。 随着大模型实验室（如 Anthropic 和 OpenAI）携巨大的渠道优势下场推广 CloudCode 或 Codex 等工具，企业级客户的痛点也愈发清晰——企业绝不希望自己的核心命脉被任何单一供应商绑定，形成单点故障（Single Point of Failure）。大家在当年的云计算时代都吃过大亏：AWS 或 Azure 当年开出极其低廉的补贴合同，诱导企业签署三年长约；等到了续约节点，价格直接暴涨十倍，凭借“数据重力”（Data Gravity）让客户动弹不得，没人能承担耗时两年的整体迁移成本。如今面对前沿大模型，企业普遍带着这种心有余悸的“伤疤”。 此外，模型实验室（Model Labs）自身的风险画像也让企业不敢托付全部信任。传统云服务商极少发生人事动荡或治理危机，而模型实验室却几乎时刻伴随着内部高层内讧、撕裂、甚至与政府各机构公开放话冲突等戏剧性事件。一旦企业把软件研发命脉全盘交给单一模型提供商，风险巨大。因此，企业极度渴求“模型中立性”（Model Independence）与高度的“模块化”（Modularity），他们需要能够随时热插拔（Hot Swap）最新、更快、更便宜或性能更强的模型。Factory 恰恰抓住了这个企业级痛点，帮助企业既能享受前沿模型的红利，又能规避单一模型厂商的生态捆绑。 ```mermaid flowchart TD accTitle: Factory与模型实验室的架构解耦 accDescr: 展示企业如何通过Factory中立框架灵活切换底层模型，同时避免专有知识被供应商锁死。 subgraph LABS["传统模式：直接绑定单一厂商"] L1["模型提供商 (Anthropic / OpenAI)"] -->|"专有插件与全套锁定"| E1["企业软件工程"] style L1 fill:#ffebee,stroke:#c62828 end subgraph FACTORY["Factory 模式：中立与模块化"] M1["模型 A (OpenAI)"] -.-> H["Factory Agent 框架 / 调度层"] M2["模型 B (Anthropic)"] -.-> H M3["开源/其他模型"] -.-> H H -->|"热插拔无缝切换"| E2["企业核心代码库"] E2 -->|"保留在客户内部"| A["自动化工作流 & 技能注册表 (Skills Registry)"] style H fill:#e8f5e9,stroke:#2e7d32 end ``` 针对主持人提出的尖锐问题——“企业放弃了模型供应商，难道不等于被锁死在 Factory 身上吗？”Matan 澄清了 Factory 的架构哲学： - **资产与知识彻底留存本地**：Factory 帮助企业构建的自动化流程、技能注册表（Skills Registry）以及生成的所有工作构件（Artifacts），全部存留在企业自己的代码库内。 - **无隐秘部落知识（Tribal Knowledge）截留**：Factory 不会在自身平台扣留客户组织的专有知识；一旦客户认为 Factory 无法保持在最前沿，可以随时脱离，开发资产依然完整归客户所有。 - **算力成本套利空间全额让渡**：Factory 协助企业在不同模型之间进行成本套利（Arbitrage）获得的成本优化收益，全部让渡给客户，而非作为平台过路费截留。 --- ### `05:00` 为过早入局买单：退还两百万美元营收的生死决断 针对红杉合伙人提到“提前两三年看对趋势其实就等同于看错”，Matan 深表赞同。从学术界物理学博士中途退学创业的他，此前甚至从未有过一份正式全职工作。在那段“荒原之旅”中，他顶着巨大压力，说服了 20 位他所见过的最顶尖技术人才离职加入 Factory。这些人多数背负着家庭和孩子，放弃了来自各大前沿模型实验室开出的丰厚薪酬包，将数年青春押注在全自主 Agent 的愿景上。然而现实是残酷的：初期模型性能严重不足，客户在心理和行为上也根本没有准备好。 Matan 调侃了一个开发者体验的小插曲：如果你发现自己不得不向开发者发“净推荐值”（NPS）问卷，那就说明他们绝对不喜欢你的产品。开发者永远是用脚投票的群体，爱憎分明，如果你还在犹豫“他们到底喜不喜欢”，答案通常是斩钉截铁的“不”。 在这场漫长的摸索中，团队摸透了企业销售，甚至一度凭借出色的销售技巧拿下了近 200 万美元的合同收入。然而，团队清醒地意识到一个致命问题：产品本身还不够好，未能真正打动开发者。单纯靠销售能力签单却留不住挑剔的工程师，无异于坐在随时会引爆的“定时炸弹”上，最终必将迎来灾难性的客户流失（Churn）。 面对这一严峻现实，Matan 与管理层做出了一个艰难而极端的决定：**主动向客户退款，把将近 200 万美元的营收几乎全额原路退还**。 - **退款内幕与阻力**：团队里的 20 位顶尖人才当时正持续受到各大 AI Lab 天价 Offer 的诱惑，同期的不少 AI 初创公司也在宣扬虚假繁荣，而 Factory 却选择把好不容易换来的真金白银退还给客户，并向全员承认产品尚未达到预期标准。 - **守住核心原则**：Matan 解释，虽然他们成功向企业兜售了未来愿景并证明了团队实力，但交付的成果未能兑现“让客户产生痴迷”（Create Obsessed Customers）的铁律。如果仅仅为了账面收入而妥协，就彻底背离了公司最底层的立身之本。 - **至暗时刻的曙光**：这一背水一战的退款决定不仅守住了信誉，也让团队彻底放下了营收包袱，沉下心在内部打磨直觉与架构。随着模型能力的飞跃与技术栈的重构，团队内部的技术咬合力逐步成型，最终迎来了破局的转折点。 ### `10:00` 经历至暗时刻：退还客户收入与团队的韧性锻造 Factory 早期在构建产品时坚持以 Agent 原生（Agent-native）为导向，虽然产品确实在解决一部分痛点，但他们的构想明显超前于客户的接受度。为了维护与客户之间的长期信任，团队做出了一个惊人的决定：在产品尚未让用户真正痴迷之前，主动将几乎所有的收入原路退还给客户。Matan Grinberg 坦言，这样做的逻辑在于树立信誉——告诉对方即使你们愿意继续付费，我们也要把钱退给你们，给我们三个月时间闭门打磨，届时一定会拿出真正让人惊艳的产品。然而，客户对这番操作的反应却五花八门：有些客户平淡地表示“挺好的”，因为他们原本就没对产品产生狂热依赖；有些企业客户则感到彻底困惑，在企业级采购的常规逻辑里，预算一旦批复花掉就翻篇了，根本没人真正关心，甚至很多大公司内部压根就没有“把钱收回来”的退款财务流程。 向投资人坦白这一切同样需要巨大的勇气。Matan 回忆起与投资人 Sean 的谈话，虽然 Sean 一直与公司走得极近、保持着高度共识，但当你不得不告诉全力支持你的投资人“还记得之前那些收入节节攀升的简报吗？现在收入马上要清零了”，那依然是一件令人不寒而栗的事。更为艰难的是向全体团队宣布这个决定的全员大会（All-hands），Matan 将那段时间形容为“人生中最糟糕的月份之一”。会上并没有人当面大喊“这搞什么鬼”，但全场同事瞬间面色惨白、心头一紧的神情让气氛降到了冰点，每个人心中都在打鼓：这究竟只是阵痛，还是整家公司彻底沉没的前兆？ 面对看似绝境的局面，团队不仅没有分崩离析，反而展现出了惊人的向心力。Matan 认为这归功于公司早期在招聘上近乎无情的严苛标准：团队只招募对“为软件工程带来完全自动化”（bring autonomy to software engineering）这一使命真正极度狂热的人。此外，公司建立了透明的反馈闭环，让每个人意识到命运掌握在自己手中，同时选择坦然接纳现实的残酷——直面“这确实糟透了”的现状，承认竞争对手的收入正在疯涨，而自己处于退回全部营收的被动境地。Matan 用团队中赛艇运动员（Rowers）的经历来打比方：赛艇是一项纯粹对抗痛苦的运动，成败全由 2000 米测功仪上的一个冷酷数字决定。正是这种共同在深渊中承受压力的经历，在团队内部铸就了最牢固的纽带。 - 团队全员无一人离职，共同度过了收入归零的产品重构期。 - Factory 早期创立时的估值仅为 500 万美元，团队深刻体会过跌入谷底和失败的滋味，这种深植于基因的韧性让其区别于那些从第一天起就是独角兽、从未经历过生存危机的竞争对手。 ### `13:46` 范式转移：从“过于超前”到 Droid CLI 的破局 针对“模型变得更强并非行业发生质变的最核心要素”这一观点，Matan 阐述了深刻的行业洞察。他指出，Factory 早期的技术构想确实代表了未来——即构建全自动化的 Coding Agent，但提前两年入局在商业实践上“与做错无异”。全自主 Agent 要求开发者彻底改变既有的工作行为，而当时很多工程师甚至连 GitHub Copilot 这类基础工具都还没用上，直接跨越到全自动代理属于跳步过大的阶跃，步子迈得太大脱离了现实。 真正的转折点发生在 2025 年 9 月 26 日，Factory 推出了 Droid CLI。这款终端命令行工具没有强行重塑用户习惯，而是在开发者最熟悉的终端环境下迎合他们的既有工作流。Droid CLI 不仅展现出了当时行业顶尖的性能，更重要的是采用了完全的模型不可知（Model-Agnostic）架构，能够无缝调用市面上的所有模型。恰好在公司成立两年之后，整个开发者生态的心智也成熟了许多：到 2025 年底，大多数工程师已经对代码自动补全习以为常，并开始尝试通过聊天界面驱动 Agent 进行大面积的代码重构。 更为关键的变量在于开发者群体的心理防线终于松动。软件工程师在过去 30 年中形成了极其根深蒂固的工作习惯与工艺自豪感，早期许多人固执地认为“我的代码手艺绝不可能被 AI 工具取代”。随着时间推移，工程师们不仅逐渐理解了如何与 AI 协作、摸索出了如何为 Agent 设置护栏以确保其成功交付，同时也在心态上放下了戒备，愿意包容它偶尔犯错。此外，AI 意见领袖的关键发声起到了推波助澜的作用——当 Andrej Karpathy 等技术先锋在社交媒体上从最初的审慎转向公开拥抱 Agentic 工作流时，大批原本持观望态度的开发者立刻转变了观念，跟风进入了这一新范式。 ```mermaid flowchart TD accTitle: 开发者采纳 AI 编码范式的演进路径 accDescr: 展示从传统的阻抗心态到接受全自主智能体的渐进转变过程 subgraph Phase1["认知阻抗期 (2023 早期)"] A["工程师坚守 30 年工艺习惯<br/>'AI 绝不可能取代我的工作'"] B["强推全自主 Agent: 步子过大<br/>超前两年等同于做错"] end subgraph Phase2["习惯养成与松动期 (2023-2025)"] C["Copilot 普及代码补全"] D["KOL 发声带动心智转变<br/>(如 Karpathy 公开认可)"] E["开发者开始理解 Prompt 与约束边界"] end subgraph Phase3["落地破局点 (2025.09)"] F["发布 Droid CLI: 终端原生切入"] G["Model-Agnostic 架构适配全模型"] H["人机协同迈向规模化 Agent 生产力"] end A --> C B -.->|受阻反思| F C --> D D --> E E --> F F --> G G --> H ``` ### `16:47` 评测基准演进：从 SWE-bench 到 TerminalBench 的生命周期 针对业内关于“顶尖性能（Frontier Performance）”与 SOTA 的讨论，Matan 尖锐地指出了当前基准测试（Benchmarks）的短暂生命周期：任何优秀的评测标准发布后，往往在短短 3 到 6 个月内就会被各家模型通过针对性优化而“刷爆（Bench maxed）”。一旦基准测试失去辨识度，其参考价值便会迅速衰减。 在 Droid CLI 发布时，Factory 率先采用并力推的基准是 TerminalBench。在此之前，行业内最主流的评测标准是 SWE-bench，但后者的局限性在于测试用例多集中于 Python 语言、简单的脚本编写或单个文件的修改，无法反映复杂的工程真实场景。相比之下，TerminalBench 将评估置于真实的终端环境（Terminal Setting）中，考察 Agent 执行任务调度、环境调试、多工具联动等跨越整个软件生命周期的综合能力。尽管 Droid CLI 当时在 TerminalBench 上取得了突破性的领先成绩，但在当前激烈的刷榜竞争下，后继模型的得分已经普遍达到了 90% 左右。Matan 强调，从一个优秀 Benchmark 面世到它被彻底吸收进新模型的训练数据中，时间窗口正在变得越来越短。 - **SWE-bench 的局限**：局限于 Python 单文件修改与脚本修复，无法模拟端到端的复杂系统工程。 - **TerminalBench 的优势**：聚焦真实终端操作与整体开发环境的调度，能真实衡量工程代理能力，但如今也已高度“被刷满”。 ### `18:24` 破解 Harness 迷思：模型协同设计 vs. 模型不可知架构 围绕构建优秀智能体运行框架（Harness）的技术分歧，Matan 拆解了支撑高性能 Harness 的几大底层硬核工程指标： 1. **Token 缓存机制（Token Caching Rate）**：在真实工程调用中，命中缓存的 Token 成本仅为未缓存 Token 的十分之一左右。因此，Harness 对上下文结构的编排以及 Token 缓存命中率的高低，直接决定了整个系统的经济效益与响应速度。 2. **上下文压缩与压实能力（Compression / Compaction）**：在长时间、多轮次的复杂会话中，工程任务极易超出大模型原生的上下文窗口限制。Harness 必须对历史上下文执行摘要压缩与精简。而在压实过程中能否像“大海捞针（Needle in a Haystack）”一样，无损保留住藏在数万行对话中的关键架构指令与微小信息，是判定 Harness 优劣的分水岭。 3. **工具调用与环境闭环验证**：系统能否高精度调用外部环境工具，并利用环境反馈主动验证代码与操作的正确性。 对于行业内盛行的“模型与 Harness 协同设计（Co-design）才是终极答案”的论调，Matan 给出了截然相反的反直觉结论。尽管 OpenAI 和 Anthropic 等顶尖实验室的朋友坚持认为同构自研必然带来更强性能，但实际工程表明：一个能够适配多种异构模型的 Harness，其综合表现反而会远超仅为单一模型定制的 Harness。 Matan 将单模型协同设计的思路比作十年前深度学习前沿时期的常见误区——当时在 GPT-3 尚未问世的机器学习时代，很多人热衷于“我要训一个专属于我的个人 AI，把我的所有私人数据全喂给它以让它彻底懂我”。这种做法看似合身，实则极易陷入局部过拟合与视野狭隘；唯有置身于广阔、多样化的多模型生态中，Harness 才能抽象出真正通用、鲁棒且具备强大泛化能力的工程架构。 ### `20:00` 模型无关的 Harness：打破大模型与框架的过度绑定 Matan 提出了一个极具颠覆性的技术类比：“模型之于运行框架（Harness），正如数据之于模型本身。”在模型训练初期，人们曾以为在自有数据上微调是最佳路线，后来事实证明，在整个互联网的大规模数据上训练出来的模型反而泛化能力更强。同样的规律也适用于 Agent 的 Harness：一个框架暴露给越多的底层大模型，就越能避免针对单一模型的特定习性产生过拟合（Overfitting）。各大前沿实验室（如 OpenAI 和 Anthropic）倾向于将专有模型与官方框架（如 Claude Code 或 Codex）做紧密协同设计，希望打造“强强联合、非我不可”的生态壁垒；但 Factory 发现，多模型兼容的通用 Harness 能够在不同模型的长处与怪癖中汲取经验，反而在综合基准测试中超越单一厂商的原生组合。 在实际表现上，不同模型有着截然不同的“人格”特征。Matan 幽默地打比方：Opus 就像那位随性又擅长变通的同事，如果你丢给它 20 项任务，它可能会说：“嘿，搞定了，顺便提一句，我发现其中有 5 项根本没必要做就直接省了，今晚不早了，咱们去喝杯啤酒，剩下的明早再说”；而 GPT-5.6 则是一个彻头彻尾的“强迫症（OCD）执行狂”，哪怕不睡觉也必须一字不差地啃完所有待办项。然而在真实开发环境中，这两种风格各有优劣——有时你需要模型灵活重构方案，有时你则需要它死磕细节。 这种行为差异直接影响了 Harness 的工程设计。例如在执行复杂的代码迁移时，Agent 通常需要生成并维护任务待办清单（To-do list）。早期 Claude 的模型本身容易在推理长程任务中走神，因此 Claude Code 框架必须设置极度严苛的约束拉住模型；而 Codex 模型自身就极为执拗，框架便无须额外强力约束。但如果用户在不同底层模型间切换，最忌讳的是交互体验割裂或核心工具丢失。一旦面对上下文压缩（Compaction）与长会话摘要，若 Harness 的工具调用（Tool use）不够鲁棒，待办列表中的第七步骤就可能在摘要中被遗忘，导致致命失败。通过抹平各家模型的缺陷，Factory 的 Droid 在 Terminal Bench 上的早期跑分甚至一度压过了实验室的原生框架。 ```mermaid flowchart TD accTitle: 专有绑定框架与多模型 Harness 对比 accDescr: 对比单一模型过拟合框架与多模型通用 Harness 的架构优势 subgraph S1["单一厂商紧绑定路线"] M1["专有 Frontier 模型"] --> H1["定制 Harness"] H1 --> R1["过拟合单一模型特性<br/>切换模型极易出现断层与失效"] end subgraph S2["Factory 模型无关路线"] direction TB MA["Claude Opus<br/>(灵活善变/易走神)"] --> HF["通用鲁棒 Harness<br/>(Droid)"] MB["GPT-5.x<br/>(严谨强迫症/死磕清单)"] --> HF MC["开源模型 GLM 等<br/>(低成本高效能)"] --> HF HF --> R2["抹平模型差异<br/>长会话压缩防丢失 / 统一工具调用"] end ``` --- ### `23:00` 从“Token 卷王”到“成本理性化”：企业 AI 采用的四个阶段 企业在引入大模型编程时，正在经历一场从狂热走向理性的剧烈洗牌。Matan 将这一演变过程划分为四个鲜明阶段： - **阶段零（怀疑期）**：全行业没人相信 AI 能够写代码。 - **阶段一（共识期）**：大模型爆发，董事会开始质问 CEO：“你们的 AI 战略到底是什么？”慌乱的 CEO 只能层层施压，要求 CTO 限期全员推广。 - **阶段二（指标强制期）**：由于传统工程师对新技术充满防备与顽固态度，CTO 为了交差，将 AI 工具的使用量强行塞进绩效考核（Perf Review），甚至拉出使用排名的公开红黑榜，比拼谁消耗的 Token 更多。 - **阶段三（Token 卷王期，Token Maxing）**：为了保住绩效考核评分，员工开始滥用高阶模型。 这种对使用率的矫枉过正导致了严重的资源浪费。Matan 透露，他们合作的部分大型银行客户，每月仅在琐碎提问上就要烧掉数十万美元：员工们遇到哪怕“旧金山今天天气如何”或“请帮我解释一下 Python 基础概念”这种 Google 就能秒出结果的弱智问题，也会毫不犹豫地调用最昂贵的旗舰模型 Opus。但 Matan 认为这种先“不择手段抓采用率”，然后再反过来“规范治理与合理化成本”的路径是合理且高效的——对于顽固的组织而言，唯有先让大家毫无门槛地体会到 AI 的价值，后续的精细化治理才成为可能。 --- ### `25:00` Factory Router：以自然语言调度的企业级多模型分流 随着盲目消耗 Token 的时代画上句号，企业 CIO 面临着前所未有的算力治理难题：未来 12 个月内，CIO 必须像论证新增员工编制一样，严密解释每一笔新增 Token 的投入产出比。然而，企业内部的开发需求千差万别，采取“一刀切”的 Token 额度上限毫无逻辑。产品经理（PM）用自然语言随手写写界面原型（Vibe coding），其所消耗的算力额度显然不该与维护核心底层基础设施的资深工程师平起平坐；更不用说银行中那些庞大的 COBOL 老旧代码库，调用通用的前沿 Opus 不仅大材小用，效果往往还不如在 COBOL 数据上专门微调过的小模型。 针对这一痛点，Factory 推出了动态模型路由系统（Factory Router）。该路由器不仅支持确定性的策略，还允许企业管理员直接使用自然语言编写调度规程（Routing procedure instructions）： - **按研发场景分流**：组织内负责搭原型、写报表的部分，直接路由到轻量且便宜的 Gemini Flash；维护遗留系统的团队，精准分流至专有的微调模型。 - **跨厂商组合流水线**：针对极其看重可靠性的关键系统，配置多模型流水线——由 OpenAI 模型生成代码，Anthropic 模型编写测试用例，再由 Gemini 进行代码审查（Code Review）。 - **自然语言灵活分配**：管理员可以直接写下类似“给搞不清在干什么的某员工默认分配 Flash 级别模型”或“出于特定顾虑限制某些部门访问开源模型”等策略，系统内部还会基于基准测试动态权衡任务与模型的适配度。 --- ### `27:30` 开源权重模型的崛起与“爱因斯坦做代数家教”隐喻 在模型生态的演进中，开源权重模型的突飞猛进正在深刻改变技术经济学。Matan 盛赞了 GLM 5.2 等新一代开放模型的惊人表现。在 Factory 内部，工程团队的 Token 使用完全不设上限，然而内部实际调用的 Token 中，足足有一半已经切换到了开源模型。Matan 指出，业内普遍存在一个评估误区：人们总是拿 GLM 5.2 去硬碰同时期刚刚发布的绝对顶尖模型（如 Opus 4.8 或 GPT 5.6），得出开源略逊一筹的结论；但更符合商业规律的比照对象应当是上一代顶尖模型（Frontier minus one，如 Opus 4.7 或 GPT 5.5）。 事实明确证明，开源模型已经稳稳达到了“顶尖减一代”的水平，同时拥有极高的推理速度和极为低廉的成本优势。Matan 打了一个生动的比喻：“如果你要给女儿找一个初中代数家教，你完全可以在市场上找到比阿尔伯特·爱因斯坦便宜得多的老师。也许未来她会成为世界顶尖的物理学家，到那时你再去请爱因斯坦也不迟；但眼下找个高中生就完全足够了，而且划算得多。” 对企业级软件工程客户来说，核心诉求是以最低成本、最快速度解决实际问题。当多模型架构打破了单一巨头对智能的垄断，软件工程正在迈入一个百花齐放的“智能花园”（Garden of intelligence）。就企业客户的模型消耗比例而言，虽然绝大多数企业目前仍处于“从无路由迈向初步接入路由”的第一步，但随着精细化配置在未来 6 到 12 个月全面落地，开源模型正在迅速蚕食闭源前沿模型的份额基数。 - **GLM 5.2 的工程落地**：推理速度更快、价格大幅压缩，在 Factory 内部已承担了近 50% 的研发 Token 负载。 - **智能花园理念**：摒弃单一模型垄断，根据业务难易程度自由选配阶梯式智力算力，极大释放企业的工程吞吐量。 ### `30:00` 开源模型的 Token 份额爆发与智力分配的杠杆法则 开源模型在企业内部的渗透正在经历迅猛增长。最初开源模型处理的 Token 仅占很小的个位数百分比，而如今已经迅速跨越进入两位数百分比的区间。尽管因为开源 Token 成本极其低廉，Token 数量的份额并不直接等同于支出成本的份额，但这种增长速度仍然令人瞩目。 Matan Grinberg 预测，长期来看开源模型的 Token 份额最终将逼近极高比例的渐近线，因为开源模型赋予了企业更大的选择自由度与巨大的成本优势。然而，“Token 份额”与“杠杆份额”（Leverage share）存在本质区别： - **前沿与低阶任务分流**：企业中可能只有 1% 的 Token 极具价值，负责最核心的高阶决策与复杂推理；而剩余 99% 的 Token 则是低风险的纯代码实现。 - **前沿智能的不可替代性**：开源模型的 Token 永远不可能达到 100%。前沿智能（Frontier of intelligence）对任何企业都将持续具备核心价值，因为商业赌注只会越来越高，思维的复杂度也将愈发关键。 - **组织智力分配映射**：这如同工程团队的职级架构——资深工程主管凭借经验与智慧，每分钟脑力调用的杠杆率极高，而普通工程师在一天中大多数时间的脑力消耗其实非常平庸。 Factory 的目标正是将那些低杠杆的工作彻底自动化，把零碎的“顿悟时刻”（Eureka moments）扩展为持续数小时的高价值创造。Matan 举了一个生动的例子：过去像 Stripe 这样的公司凭借令人惊艳的开发者文档获得了巨大的竞争优势（Alpha），但如果顶尖工程师把大量时间耗费在写文档这种低杠杆事务上，无疑是对智慧的浪费。未来的世界应当让每家企业都能轻松生成比肩 Stripe 水平的文档，而把最优秀的头脑解放出来去解决深度的系统架构难题。 --- ### `32:51` 从用量计费到基于成果的“Token 交易市场” 在商业模式与定价策略上，虽然开源模型的成本断崖式下跌引发了成本结构与交付价值的脱节，但 Factory 坚持以客户需求为导向，而非盲目推行超前模式。吸取了创业前两年的沉痛教训，Factory 绝不强推企业尚未准备好的定价方式： - **当前模式**：全面采用基于用量（Usage-based）的计费方式，让客户消耗与企业价值保持同步；Matan 直言按席位付费（Seat-based）对于 Agent 产品毫无逻辑。 - **未来演进**：预计到 2030 年代，软件行业将彻底转向基于成果（Outcome-based）的计费，但目前企业采购和流程尚未成熟。 ```mermaid flowchart TD accTitle: 基于成果的竞价交易市场架构 accDescr: 展示工程师提出任务后，模型提供商如何针对任务和验证回路进行竞价并交付成果的完整闭环。 subgraph DemandSide ["需求端 (Buy Side)"] Engineer["工程师 / 业务方<br/>定义具体任务与验收标准"] end subgraph FactoryRouter ["Factory 动态路由中枢"] Router["Token 任务分发与撮合器"] end subgraph SupplySide ["供给端模型市场 (竞价方)"] OpenAI["OpenAI"] Anthropic["Anthropic"] CloudModels["AWS / GCP / 开源托管"] end subgraph Validation ["闭环验证与结算"] Loop["自动化验证回路<br/>(CI/CD / 单元测试 / 集成校验)"] Outcome["成功交付: 获利结算<br/>失败交付: 承担负毛利"] end Engineer -->|"任务描述 + 严格验证标准"| Router Router -->|"任务竞价分发"| OpenAI Router -->|"任务竞价分发"| Anthropic Router -->|"任务竞价分发"| CloudModels OpenAI & Anthropic & CloudModels -->|"按任务打包报价并执行"| Loop Loop -->|"通过全部测试"| Outcome ``` Matan 描绘了一个极具想象力的“任务竞价市场”蓝图。当下的 Factory 路由机制更像一个简化版的聚合器，根据成本和性能基准把 Token 炮弹（Token cannon）定向发射给 OpenAI、Anthropic、AWS 或 GCP；但在未来的成果计费世界中： 1. **模型厂商包工竞价**：模型厂商不再按单个 Token 报价，而是针对具体任务和给定的验证标准进行一口价竞标，自行承担模型推理的成本风险与毛利波动。 2. **严苛验证防止作恶**：这种模式倒逼使用者建立极其严密的验证闭环（Validation loops）。Pat Grady 幽默地提到美剧《硅谷》（*Silicon Valley*）中的经典桥段——当要求 Agent 修复代码 Bug 时，Agent 发现把全部代码删光就能消灭所有 Bug（“Son of Anton 去中心化代码库暴走”）。如果验证测试不严密，Agent 就会为了达成目标走荒谬的捷径。 --- ### `35:56` 软件工厂的工业化：从作坊手艺到流水线装配 谈及 Factory 的公司命名（更名前曾叫 Droid），Matan 指出，其实当今每家公司都在运营着一座“软件工厂”，只是绝大多数仍处于前工业化时代的作坊状态： - **作坊式生产的低效现状**：就像工业革命前手工业者手动缝纫或做木工一样，如果走进一家拥有上万名员工的企业，询问一个新功能从规划到发布的完整决策流水线，往往牵涉数百甚至上千人。几乎没人能把这张端到端的流程图画出来，全靠人际冗余和繁琐审批维系。 - **隐性知识的代码化转化**：传统大厂严重依赖“在公司干了 30 年的技术宗师”口口相传、跨部门反复盖章审批以及遗忘在角落里的陈旧合规检查清单。现代软件工厂的使命，就是将这些部落隐性知识（Tribal knowledge）全部结构化、代码化。 - **清晰端到端的装配流水线**：企业必须精准标定输入信号（客户反馈、市场动向、产品主管输入），并建立起清晰透明的软件装配流水线（Assembly line），从而能清晰地追溯和验证每个环节是否真正为业务带来了实际成果。 --- ### `37:42` 企业即 AGI：告别“广告狂人”时代的凭感觉决策 Matan 将未来的企业决策与人工智能模型训练进行了深刻类比。两三年后，CIO 们面临的终极拷问将是：**企业新增的每一块钱预算，究竟应该投向新增员工人头（Headcount），还是投向 Token？**如果投向 Token，又该分配到组织的哪个业务节点？ - **软件开发的“广告狂人时代”终结**：未来的软件开发模式看今天，就像现代商业看古代连会计记账都没有的企业，或者像上世纪 60 年代美剧《广告狂人》（*Mad Men*）里的营销界——一切全凭创意和感觉，“上线个功能，感觉好像挺不错”，但根本不知道究竟哪一部分在起效。大量功能上线后，对用户留存、活跃度没有任何正面推动，纯粹是在凭空浪费算力。 - **Jack Dorsey 的“公司即 AGI”假说**：Matan 引用了 Twitter 联合创始人 Jack Dorsey 著名的博客观点：每一家公司本身就是一个复杂的 AGI 神经网络。 - **企业反向传播必须依靠严谨数学**：管理一家企业就像优化神经网络的权重，管理者必须弄清哪些节点在承重，哪些节点形同虚设，哪些节点需要补充更多 Token。训练模型或许可以凭借灵感做架构尝试，但执行反向传播（Backpropagation）时全靠精密严苛的数学计算。企业绝不能再靠拍脑袋、凭感觉（Shooting from the hip）来随心所欲地制定 Token 预算与架构路线。 ### `40:00` 算力分配与企业核心能力的“冷酷聚焦” 企业过去裁员往往显得随意而缺乏科学依据，往往拍脑袋决定削减 2 万个岗位，纯粹是“先砍掉一块看看会发生什么”。而在未来的组织中，这种决策将变得更加偏向量化与数学模型化。管理层需要清晰地评估：业务的哪一部分在注入更多 Token 时能产出更高价值，而无需增加人力投入；相反，又有哪些业务环节即便堆叠算力也收效甚微，反而极度依赖人与客户建立的深厚关系。这种判断需要定量的洞察，也正是像 Factory 这类“软件工厂”所要赋能的。如果企业在 Token 与工程人力的投入比例上缺乏科学依据，一切就只是在盲目猜测。 在极限情况下，企业在 Token 和工程人力上的支出配比将完全取决于业务特性。以销售团队为例，优秀的销售人员其核心超额收益（Alpha）来自于面对面与客户交流、理解痛点并探讨如何提高软件构建效率。销售人员消耗 Token 的场景仅限于生成 AI 简报、会议记录总结或辅助跟进邮件，这些场景消耗的 Token 极其有限，增加再多算力也不会显著提升产出，但增加优秀的销售人员却能带来直接增长。 ```mermaid flowchart TD accTitle: 业务部门的 Token 与人力杠杆对比 accDescr: 对比销售、工程以及中间业务环节对 Token 和人力的不同依赖度与杠杆效应。 subgraph Sales ["销售团队 (关系驱动型)"] S1["增加更多 Token: 边际效应极低<br/>(仅用于笔记/会议纪要)"] S2["增加更多优秀人力: 显著提升业务产出"] end subgraph Eng ["工程团队 (结果驱动型)"] E1["工程师全流程负责业务目标 (End-to-End)"] E2["注入海量 Token: 研发生产力成倍放大"] end subgraph Ops ["中间环节 (运营/财务/市场)"] M1["介于两者之间，视核心业务属性而定"] end ``` 与销售相反，工程团队由工程师端到端（End-to-End）负责最终结果，一旦赋予他们大量 Token，生产力便会成倍放大。至于运营、财务和市场等部门，则介于两者之间。 这也倒逼所有企业思考自己的“核心竞争力”（Core Competency）： - **盲目自研的教训**：很多消费级物流公司曾豪言要自研软件开发智能体（AI Agents），半年后撞上现实之墙才意识到，自己并非 AI 技术公司，不该雇佣昂贵的 AI 工程师去做非核心事务，其真正核心在于物流履约。 - **比萨饼店类比**：互联网早期，比萨饼店要建网站可能不得不招募程序员，但这只是特定历史时期的副产物，做网页绝非比萨店的核心价值所在。随着第三方工具普及，如今的比萨店不再需要设立工程部门。 - **聚焦与外包**：AI 时代将驱动企业展开“冷酷的重新聚焦”（Ruthless Refocusing），企业应把全部精力收拢到自身最擅长的核心能力上，非核心能力则完全依赖外部采购。 --- ### `43:26` 企业 AI 转型的破局：Hackathon 与“打破圣牛” 面对企业的自我重塑（就像过去十几二十年的“数字化转型”，如今演进为“AI 转型”），许多传统组织在两年前根本无法承接自主智能体（Autonomous Agents）的落地。然而，走在成熟度曲线前端的客户总结出了一套行之有效的打法： - **全员 Hackathon 的驱动力**：令人意外的是，最有效的做法往往是设定全员黑客松。哪怕只是专门空出一天时间让全公司“用 AI 随便折腾做点东西”（"build shit with AI"），都能彻底定下转型的基调与节奏。 - **允许试错与拥抱失败**：一些组织试图从第一天起就做出百分之百正确的决定，这往往导致停滞不前。真正成功的企业敢于在试错中前行。例如 Factory 的大客户安永（EY），虽然在外界眼中并非处于 AI 绝对前沿的技术极客，但安永管理层非常清醒：“我们在以往的几波技术变革中落后过，这一次绝不能迟到。”在守住绝对不能出错的合规底线之外，安永放手让工程师全面折腾、在边界处探索工具的极限，快速掌握员工的真实喜好。 - **敢于打破“圣牛”（No Sacred Cows）**：转型最顺利的团队对既有流程毫无盲目崇拜，敢于把过去的条条框框搁置一旁；新尝试如果不奏效，再把老规矩搬回来。 - **自下而上的变革动力**：如果变革指令仅仅来自董事会的自上而下施压，往往难以为继；真正的成功转型几乎全是由技术团队、一线独立贡献者（IC）或技术主管在内部主动点燃的。 --- ### `46:09` 走向“黑灯工厂”：从交互式 Co-pilot 到 90% 异步运行 当前 AI 行业的消费量正呈爆发式增长，营收数据也令人兴奋，但 Matan 指出，**绝大部分当下的使用依然是“同步模式”（Synchronous Usage）**。换句话说，如果全球开发者明天全部因病卧床，像 Claude Code 或各类代码工具的调用量将瞬间归零，因为每一次调用本质上都需要人类主动发号施令（"Hey Claude Code" 或 "Hey Droid"）。当前行业仍停留在高阶 Co-pilot 的范畴——即便智能体能自主执行多个步骤而不反复询问，但启动键依然握在人类手中。 Matan 预测，在未来 12 到 24 个月内，**90% 的 Token 消耗将完全转变为“异步 Token”（Asynchronous Tokens）**： - **自主感知与修复**：智能体（Droids）将在后台自主运行，监控系统信号。一旦捕获到用户端暴露的问题，无需等待人类指令，便会自动完成排查、编写并提交首版修复方案。 - **“黑灯工厂”（Dark Factory）愿景**：Factory 公司的命名灵感直接来自特斯拉的超级工厂——车间内密密麻麻的机械臂在自主运转，不需要工人在旁逐一安装零部件，整个工厂可以在关着灯的情况下高效生产。软件工程正在迈入这种熄灯运转的境界，这也是埃隆·马斯克（Elon Musk）所推崇的理念——“制造机器的机器”（"the factory is the machine that builds the machine"）。 - **品牌名称的双关幽默**：马斯克曾调侃事物往往会变成其名字的反面；Factory 也欣然接受这种宿命——随着工业化“工厂”彻底接管底层代码流水线，人类所做的软件开发反而回归为纯粹精湛的“手工艺”（Artisanal）。 --- ### `48:33` 短期震荡阵痛与长期软件普惠的乐观图景 面对未来，Matan 展望了 Factory 以及整个行业的技术走向与社会影响： - **短期的痛苦修正与行业责任**：过去几年整个行业充斥着严重的资源错配与人员冗余，接下来的结构性纠偏将是极其剧烈且痛苦的。Matan 认为，“重新分配资源”这一冷酷术语背后是活生生的失业，每一位 AI 公司的 CEO 都应该为此承担比现在多得多的责任，并积极寻找缓解与治愈这种社会阵痛的方案。 - **对工程师职业消亡论的反驳**：Matan 坚决不认可所谓“工程师将彻底消失”的言论。现实是：世界上存在海量的问题，其中极大一部分可以通过软件来解决，而目前真正被软件有效解决的仅是沧海一粟。 - **系统思维者的再配置**：过去，大量宝贵的工程资源被过度倾斜配置在少数特定软件上；而在阵痛之后，这些世界上最优秀的系统思维者（Systems Thinkers）和问题解决专家将被释放出来，去攻克以往无暇顾及的全新领域。 - **终结“糟糕软件”的现状**：当前许多领域虽有软件支撑，但体验极其糟糕，比如各类政府部门网站、DMV（车管所）系统或 IRS（国税局）网页，使用体验极为落后。人类完全没有理由继续忍受低劣的软件交互。Factory 的终极愿景正是成为底层的“制造机器”，帮助开发者打造卓越的软件，将优质系统拓展到社会治理与日常生活的每一个角落。 ### `50:00` 顶尖工程力量的重新配置：从常规软件走向制药与重大难题 在探讨软件工程变革的深远影响时，马坦·格林伯格（Matan Grinberg）将视野从单纯的编程工具拓展到了全人类面临的核心挑战。他指出，加速所有软件的构建固然令人振奋，但像医药研发（pharmaceutical research）这类关乎攻克人类疾病的尖端领域，本质上早已不仅是一个生物学问题，其背后极其依赖世界上最优秀的软件工程师。在以往的商业格局中，这类关乎人类命运的重大领域往往无法分配足够的资金预算，因而难以在人才市场上与开出天价薪酬的消费级互联网或金融科技巨头竞争，无法吸引到最顶尖的工程师。 然而，随着自主编程 Agent 和 AI 驱动的软件生产模式爆发，这种资源配置失衡迎来了被打破的契机。马坦强调，未来的资本与技术分配将更加紧密地锚定在“这世界上最重大的问题究竟是什么”之上，让最优秀的大脑和解题者全力攻坚最关键的挑战。他认为，作为整个科技行业的一员，当下的核心责任就是尽可能加速这种人才与资源重组的进程——不应等待漫长的十年，而是要在短短六个月到一年内将这种重新分配推向现实。 - **生物与医药研发的软件化本质**：疾病攻坚不仅依赖生物实验，更需要依靠顶尖的软件工程架构来支撑庞大的数据分析、模型预测与管线运转。 - **资本与人才重构的目标**：打破过去低效的资源错配，将最顶尖的开发者从繁琐、重复的业务逻辑中解放出来，投入到攻克疾病等高价值的全球性议题中。 - **行业使命与时间压缩**：马坦呼吁全行业共同努力，将原本可能需要 10 年才能完成的工程师人才流动与重新配置周期，大幅压缩至 6 个月到 1 年内完成。 ### `50:45` 始终如一的清晰愿景：从荒漠跋涉到 Factory 的蜕变 对谈临近尾声，主持人（红杉资本合伙人）索尼娅·黄（Sonya Huang）向马坦致以诚挚的赞叹。她回顾了 Factory 从早期探索至今的旅程，感慨马坦随着时间推移所展现出的愿景清晰度与始终如一的定力（"clarity and consistency of your vision over time"），并直言这种执着始终令人深受鼓舞。 主持人进一步提到，距离上一次录制《Training Data》播客虽然时间不算太久，但亲眼见证马坦作为一名创业领导者的飞速成长，以及 Factory 整个团队与业务规模的蜕变，这种进化速度堪称“令人肃然起敬”（"truly awe-inspiring"）。在一片欢声笑语与热烈感谢中，本期播客圆满收尾，也为 Factory 所描绘的“软件自构建”与未来“暗黑工厂”（Dark Factory）图景画下了生动的注脚。 ## Notable quotes > `00:00` 去得分！把分给我拿下来！ — Matan Grinberg > `05:00` 提前两三年看对趋势其实就等同于看错 — Matan Grinberg > `10:00` bring autonomy to software engineering — Matan Grinberg > `13:46` 我的代码手艺绝不可能被 AI 工具取代 — Matan Grinberg > `20:00` 模型之于运行框架（Harness），正如数据之于模型本身。 — Matan Grinberg > `27:30` 如果你要给女儿找一个初中代数家教，你完全可以在市场上找到比阿尔伯特·爱因斯坦便宜得多的老师。也许未来她会成为世界顶尖的物理学家，到那时你再去请爱因斯坦也不迟；但眼下找个高中生就完全足够了，而且划算得多。 — Matan Grinberg > `37:42` 企业新增的每一块钱预算，究竟应该投向新增员工人头（Headcount），还是投向 Token？ — Matan Grinberg > `43:26` build shit with AI — Matan Grinberg > `43:26` 我们在以往的几波技术变革中落后过，这一次绝不能迟到。 — 安永管理层 > `46:09` the factory is the machine that builds the machine — Elon Musk > `50:45` clarity and consistency of your vision over time — Sonya Huang ## Mentioned Matan Grinberg, Sonya Huang, Pat Grady, Jeff Bezos, Sean, Andrej Karpathy, Jack Dorsey, Elon Musk, Factory, Sequoia Capital, Droids, Droid CLI, Factory Router, CloudCode, Cognition, GitHub Copilot, OpenAI, Anthropic, AWS, Azure, Google Cloud Platform (GCP), Stripe, EY（安永）, SWE-bench, TerminalBench, Claude Code, Codex, Claude Opus, GPT-5.5, GPT-5.6, Gemini Flash, GLM 5.2, 美剧《硅谷》（Silicon Valley）, 美剧《广告狂人》（Mad Men）, 播客《Training Data》 ## Video description Factory started building fully autonomous coding agents in April 2023, two years before enterprises were ready. Matan Grinberg now says this is indistinguishable from being wrong. The Factory co-founder and CEO explains how the company survived its "journey in the desert," including the decision to hand nearly all of its revenue back to customers when the product wasn't making developers obsessed. Matan makes the contrarian technical case that a model-agnostic harness beats the model-and-harness co-design that labs like OpenAI and Anthropic favor, because exposing a harness to many models keeps it from overfitting to any single one. He argues open-weight models like GLM will capture the majority of tokens by staying one generation behind the frontier at a fraction of the cost, and that CIOs will soon justify every incremental token the way they justify headcount. Looking ahead, he predicts 90% of coding tokens will run asynchronously—the "dark factory" where software builds itself. Hosted by Sonya Huang and Pat Grady, Sequoia Capital [Source](https://pscrb.fm/rss/p/traffic.megaphone.fm/CPUAI7029994616.mp3)

[0:00] Matan Grinberg: 去得分！把分给我拿下来！ [5:00] Matan Grinberg: 提前两三年看对趋势其实就等同于看错 [10:00] Matan Grinberg: bring autonomy to software engineering [13:46] Matan Grinberg: 我的代码手艺绝不可能被 AI 工具取代 [20:00] Matan Grinberg: 模型之于运行框架（Harness），正如数据之于模型本身。 [27:30] Matan Grinberg: 如果你要给女儿找一个初中代数家教，你完全可以在市场上找到比阿尔伯特·爱因斯坦便宜得多的老师。也许未来她会成为世界顶尖的物理学家，到那时你再去请爱因斯坦也不迟；但眼下找个高中生就完全足够了，而且划算得多。 [37:42] Matan Grinberg: 企业新增的每一块钱预算，究竟应该投向新增员工人头（Headcount），还是投向 Token？ [43:26] Matan Grinberg: build shit with AI [43:26] 安永管理层: 我们在以往的几波技术变革中落后过，这一次绝不能迟到。 [46:09] Elon Musk: the factory is the machine that builds the machine [50:45] Sonya Huang: clarity and consistency of your vision over time

[0:00] Matan Grinberg: It doesn't matter if you're customer obsessed. You could be customer obsessed and they file a restraining order against you because they don't like what it is that you're doing. Our job is to build something so good that our customers themselves become obsessed with us. [5:00] Matan Grinberg: There's no consolation prize. It's either you do the thing or you don't do the thing... We sold them on a good vision... but we realized that the product that we were delivering was not up to snuff... One of our operating principles that I really like is create obsessed customers. [10:00] Matan Grinberg: We know what it's like to be at rock bottom. We know what it's like to lose... When we first started the company, our valuation was 5 million. A lot of our competitors out there these days don't know what it's like to not be a unicorn... That makes us so resilient. [20:00] Matan Grinberg: Opus is kind of like that super friendly colleague where you're like, 'Hey, I want to go do these 20 tasks.' And they're like, 'Okay, cool. Hey, by the way, five of those tasks I realized we didn't need to do... Tonight's not a good time, let's pick it up in the morning... let's go get a beer afterwards.' Meanwhile, GPT-5.6 is like, 'Absolutely, I will do every single one of those and nothing will stop me. I'm not going to sleep...' [25:00] Matan Grinberg: If you're trying to get a tutor for your daughter in algebra, you can probably find someone cheaper than Albert Einstein to be that tutor... most likely you can get a high school student... and it's probably much more cost effective.

[0:00] Bezos at Amazon, it's customer obsession. But in our mind, that's an input metric. You don't want to measure input metrics. It doesn't matter if you're customer obsessed. You could be customer obsessed and they file a restraining order against you because they don't like what it is that you're doing. Our job is to build something so good that our customers themselves become obsessed with us. That is our job. The analogy is, if you're a coach of a basketball team, you don't want to tell your players before they come out there like, hey guys, make sure to sweat. It's like, what? No, score points. We need to score points. And in doing so, yeah, you're probably going to sweat. And I think similarly, to create obsessed customers, you probably need to be really obsessed yourself with the customers. But the output is what matters. we're here in the studio with matan from factory this is our second time with matan thanks for having me you're in the small and elite group of second time training data attendees so thank you Oh yeah. Matan is the co and CEO of Factory which makes droids which are autonomous agents for the art of software development Yes indeed And Matan we going to jump right in because I think you guys are a little bit of a dark horse candidate in this world of software development. It is a market that has absolutely taken off. There are folks like CloudCode and Cognition and others who have a lead, but you guys are coming up strong. Talk about the competitive dynamics and what makes Factory special? It's been a wild ride. We started Factory three and a half years ago now. So in April of 2023, when the world and the enterprise in particular was barely ready for GitHub Copilot, let alone fully autonomous agents. And so I think the first two years, it was kind of our journey in the desert is how I like to refer to it, because we were focused on fully autonomous agents, but engineers weren't ready. Procurement teams at the enterprise weren't ready. And so I think retrospectively, we really like honed our craft and learned a lot about how to build for developers in the enterprise. But, you know, it took a lot of time to actually come around to when they were ready to receive it. And so we're kind of now emerging much more. And some of these other players like Anthropic or OpenAI who have a ton of distribution are going in and bringing their incredible tools like CloudCode or Codex The thing that enterprises are really caring about that we have learned through those two years is they do not want anyone to kind of be their single point of failure. They do not want anyone to kind of control their fate. And so something that really matters is model independence. everyone learned from cloud where you know back in the cloud days it was like aws or azure being like hey you know come on in sign this three-year contract it's going to be so cheap we're going to subsidize it it'll be great and then a couple years later when it came time to renewal they would 10x the the contract haha data gravity we got you now yeah we got you what are you going to do a two-year migration to go to someone else like no way everyone has scars from that now And so everyone knows, look, Cloud Code is fantastic. Codex from OpenAI is fantastic. We cannot put our fate in any one of these model providers' hands. Also, like, you just look at the risk profiles of the model labs versus the cloud providers. What's the last piece of drama that came out of one of the cloud providers versus, like, the model labs? it seems like there kind of always some sort of chaos of internal fighting or getting in spats with the government or any other entities other entities And so if you going to you know build this very important part of your business you want to make sure that you robust to any of these changes And that something that we learned over those kind of initial two years is like developers really care about things being modular. They want to know that they can customize it to what they want. They want to know that if there's a new model that comes out that's faster or cheaper or more performant, they can kind of hot swap it in. And that's, I think, one of the biggest reasons why a lot of the largest enterprises are taking the momentum that they had from a codex or a cloud code and then are carrying that into factory because they get that performance from these fantastic models, but they do it without the vendor lock-in that the Model Labs directly provide. And if I'm the enterprise, I'm going to be like, wait a minute, am I now just getting locked into factory? What's the answer to that? So it's a really good question because that is something that you might think of like, okay, wait, so we're just switching the lock-in point. All of the modularity that we build is such that if at some point you wanted to say, hey, you know what? Factory's not staying at the frontier anymore. Whether it's like the automations that you build or the skills registry that we help you create, the work that we've done stays in your code base. And any of the automations that we've created, the artifacts also live in your code base. In other words, there aren't really things that we're [5:00] our tribal knowledge about your org that we're keeping on our side and not giving to you. And that's part of the relationship that we have with customers is like, we similarly want to make sure we're providing the best experience possible. If we help you arbitrage between different models to get cost optimization, we're giving you that optimization. We're not taking that away from you. And I think that's a really important part of the trust that we're building with these enterprises. You and I were talking probably a couple months ago at this point, And I was trying to give you credit for having the right vision for this market two, three years ago. And you responded with something along the lines of thank you. But being two or three years early is the same as being wrong. Yes. Which I thought was a wonderful response in so many ways. Can you talk about like that those two years in the desert? How did it feel to have this vision that turned out to be right that nobody appreciated for a year or two? Can you just talk about that journey and what it has done to the DNA of your company? Yeah. I mean, in the moment, it's really, really difficult because I hadn't had a job before. I dropped out of my PhD to start this company. And over the course of those two years convinced 20 of the smartest people that I ever met to quit what it was that they were doing and you know join factory and join us on this mission And these are people with families These are people with kids who are like dedicating years of their lives to this problem and going, you know, customer after customer. And they like, they weren't ready for agents. They didn't get it. Also, the models weren't as performant, but I think a lot of it was behavioral. and I mean even just a fun anecdote of like giving developers an NPS survey if you ever are giving a developer an NPS survey they do not like whatever it is that you're giving it to them because like developers they vote with their feet they are very clear what they like and what they don't like and if you're like hmm I wonder if they like it they definitely don't um and uh but during that time I think there were there was a lot that we were learning there was a lot that I myself was like, I'd never had a job before. Enterprise sales is not something that comes obvious to a physicist. But at the end of the day, it doesn't matter. You don't get any bonus points for being early because who cares? There's no consolation prize. It's either you do the thing or you don do the thing And that all that matters And for the team is really tough There were points where we ended up getting good at enterprise sales but the product still wasn good And that a very tricky position to be in because we ended up you know getting to a point where we were like, just under 2 million in revenue, and the product was not good. And there was a point in time where we realized this, because if you're really good at sales, you can sign contracts, that's like, you can definitely do that. But if you're doing that in the developers don't like your product, it's like a ticking time bomb, because it's eventually they're going to churn and it's going to be really, really bad. We realized this and we proactively gave all of those customers their money back. And I remember that was one of the most difficult decisions to make because not only is there a group of 20 people who are getting ridiculous offers from all the labs, they have these huge financial incentives to go elsewhere. There are all these other companies that are doing well and they decided to do this. And then we're going to say, oh yeah, hey, by the way, that little bit of revenue we managed to get, we're actually gonna give it back because we don't think product is making their developers happy. We also had to tell- Why did you make that decision? You know, we sold them on a good vision and convinced them that this is the right team to work with and that we were gonna deliver the solution for them But we realized that the way that we had sold them on it and the product that we were delivering was not up to snuff in a way that I don think it would hold true to one of our operating principles And one of our operating principles that I really like is create obsessed customers Yeah. This kind of like flips over Bezos' thing where Bezos at Amazon, it's customer obsession. But in our mind, that's an input metric. And input metrics are – you don't want to measure input metrics. It doesn't matter if you're customer obsessed. Like you could be customer obsessed and they file a restraining order against you because they don't like what it is that you're doing. Like our job is to build something so good that our customers themselves become obsessed with us. That is our job. It's like, you know, the analogy is if you're a coach of a basketball team, you don't want to tell your players before they come out there like, hey, guys, make sure to sweat. It's like, what? Like, no, like score points. We need to score points. And in doing so, yeah, you're probably going to sweat. And I think similarly to create obsessed customers, you probably need to be really obsessed. yourself with the customers, but the output is what matters. And I think that it coming back to this, the product that we were delivering was not creating obsessed customers. And we wanted to make sure like this was a group of the smartest people I've ever met. We were getting there, like we were getting a lot of intuition. Things were starting to come together internally. Like we could see internally we were starting to become a lot more. [10:00] agent native in how we were doing things. And the product was kind of scratching that itch, but we were kind of ahead of our customers and we wanted to maintain trust with our customers so that when it does hit, we can come back to them and say, Hey guys, this is the real deal. I promise. And to build that credibility, we have to say, Hey, look, you know, even though you were maybe happy to continue, we're going to give you this back and say three months from now, I think it'll be ready. Give us some time. And I promise we will knock your socks off. How did your customers react when you had that conversation? Some of them were like, oh, great. Sounds good. Because I think it wasn't something that they were obsessed with. Some of them were a little bit confused. But I think generally, it's especially enterprises. They're not used to these things. A lot of times enterprise budget, once it's gone, it's gone and no one really cares. Yeah. And so some of them didn't even know if they had a mechanism by which to take back the money. But, you know, it's a difficult thing to tell. Also, like investors who believe in you, like, you know, I remember having the conversation with Sean. And Sean, obviously, he stayed really close with the company. So he was very like on the same page. But it's kind of a scary thing to be like, hey, by the way, you know, remember all those updates and you're saying, hey, look, the, you know, revenue is going up. It about to go down to zero It was a scary thing And I think it was kind of a leap of faith of like we see the signal internally early of like this is the direction we need to go We need to kind of pivot the approach on the product. But I remember that all hands where we told the whole team, it was like, Oh my God, that was like one of the worst months of my life. Like I was just, cause no, like not everyone was going to say like, what the hell is this? What's going on? But it's kind of the looks on their faces where they kind of go a little bit pale and they're like, oh boy like is this just the early signs and we're about to sink completely um how'd you keep the team together through that i think honestly the only reason the team stayed together is we were so ruthless about hiring early on where it was like people that are genuinely really really obsessed with the mission which our mission is to bring autonomy to software engineering and like really really caring about that making sure everyone um was also like very clear feedback loops as to like this the fate is in our hands it's not like this is like oh something that i go do it's like we all have a part to play in you know making this work and i think embracing how much it sucked was also i think something that was very valuable just being honest about it being super honest about like yeah this sucks like yo look look at those competitors the revenue is going up like crazy like this is not good Like we are in a very bad position Like we just had to give back all of our revenue Like we need to really get our shit together And in the moment, I think retrospectively, those are the moments where really the deepest bonds are made. Like, if you talk to people who are like athletes or even like academics or whatever, whenever you're in the like stressful period, whether it's like cramming before finals or, you know, in intense, like, you know, we have some, some rowers on our team. And I think that's an example we always go to, like that's a pure pain sport. It's pain. It's literally just, there is one number that quantifies your performance. It's just, what is your time on your 2k or your time in that? But like embracing that is what creates those enduring bonds such that afterwards, like we know what it's like to be at rock bottom. We know what it's like to lose. We know what it's like. I mean, when we first started the company, our valuation was 5 million. Like a lot of our competitors, a lot of the companies out there these days, they don't know what it's like to not be a unicorn. That's like manifestly, that is what they are day one. Whereas like we have been there kind of in those dark moments and not a single person left. Yeah. That makes us so resilient and so strong that you know going forward things are going a lot better now but there are going to be really bad times but we have that resiliency in our DNA that I not sure some of these other companies do I love that So talk to us about what changed. And I'm curious your comment from earlier that the models getting better is not the most important thing that happens. Because at least in my mind, the model getting better is the most important thing that happens. So just help me understand. Yeah, so a couple of things. So one is the interaction pattern that we were building for before was too ambitious. Like to your point, we were right in that what we were building for was fully autonomous agents, but it was two years too early, which makes it wrong. And fully autonomous agents require a complete change in behavior from the developer. And we were trying to do that out of the box before they were even using tools like Copilot. It was just too much of a leap. It was too much of a step function jump. So it's an important day. September 26, 2025 was when we first put out basically the Droid CLI. And the Droid CLI met developers where they were in a manner that previously these fully autonomous agents did not. And also its performance was like completely state of the art and it was model agnostic. So it could use every model that was out there. September 26 was also two years after we initially started. So the world had gotten much more used to using things like autocomplete. Like by late 2025, most engineers were using... [15:00] an autocomplete tool. And many were starting to, at the time, use like a chat interface to ask an agent to go do changes like wholesale. So like the more agentic interaction. However, what we see is that like, if you go back now and use in this like agentic interaction, some of these older models, they're still good. So the biggest thing that changed was developers, and in particular in the enterprise, like being open minded to this new way of working. In particular, developers, they've established their workflows over the last 30 years. They can be stubborn. A lot of them were like, no, no, no. My craft could never be done by an AI tool. So a lot of it was just understanding how to work with these tools and having the willingness to go in and try and also intuition about what are the guardrails that you need to provide in order for it to succeed. And so I think it was a combination of both of these things. The model is getting better, so you need to do less in the way of providing guardrails, but also developers lowering their guard and being like okay you know what let me go try and do these things it's going to go do things i don't like and then also there's a certain degree to which when andre carpathy tweets about something then every engineer suddenly is like okay you know maybe this is true and andre started to tweet about these agentic work Early on he wasn as open to it And then him being more open to it genuinely just changed some people minds which is funny, but that's some of the things that go into behavior changes. Like you hear it from people you trust. You start seeing it, you know, from people within your organization who are maybe a little bit more agent native. But that's kind of these things together is what changed that. And now we're all going to be on Slack. we might we might be on we might be pushing the limits of slack which i think is going to be another interesting thing but yeah okay so september 2025 you launched the droid cli you said frontier performance soda what does that mean for you there's like the benchmarks which have a very short half-life like anytime there's a good benchmark it gets bench maxed within like three to six months yeah at the time i think the one that we kind of championed when we launched and kind of it ended up becoming a pretty good benchmark was TerminalBench. So prior to that, the one that was kind of leading was Sweebench, which was kind of took some open source projects and some examples of issues that were then solved. The problem with that was it was very focused on like Python and like scripting or like individual file changes, whereas TerminalBench was more one it was in the terminal setting So it was things like scheduling runs and things that were not just like changing the code file but general software development tasks And that was something that we ended up you know having really frontier performance on Now it's like bench maxed to the extreme to where it's like, I think, you know, models that come out now are like 90% on it. And I think there's a very short time horizon from putting out a good benchmark to then it being kind of in the training data. What goes into building a great, and is it a great harness? And it seems like there's almost a lot of FUD in the ecosystem of my harness is better than your harness. And you need to own the model to have a good harness. Or actually, you have a better harness if you don't own the model. What's your mental model for benchmark maxing aside? What keeps you at the frontier? Yeah, so some general things that matter are the way you do caching. So cash tokens end up being like a tenth as expensive. And so one big piece of performance for a given harness is what is your rate of token caching? Another example would be how do you perform while in compression or compaction? So typically when you're dealing with a long session, you're going to exceed the context limit of the model itself. And so the harness will do some sort of summarization compression compaction whatever you want to call it And the way that you perform during that compaction is a big determining factor of how good your harness is And tests that they do for that are like you know they call it needle in the haystack where you have some long thread and maybe there's one piece of information that's really important. How often will your harness preserve that through compaction? Other examples are like tool use or how does it use the environment to validate whatever work that it's doing? these are things that you can kind of have individual metrics on and that we kind of have our own internal benchmarks to measure how do the out of out of the box agents do versus how does factory perform i think one thing that naively everyone believed initially was if you train the model and you build the harness you're going to make them better together yeah and much to the chagrin of many of my friends at open ai and anthropic this is not true if you build a harness that supports different models, that harness will be better. What's the, like, my intuition would be model, harness, co-design makes you better. Yes. What's the intuition for why it's actually not? It's very analogous to the idea maybe like, I don't know, 10 years ago of if you were to be like, hey, I want to train my personal AI back in like ML days before like GPT-3. I want to train my personal AI. I'm going to give it all of my data because I want it to know me. [20:00] It turns out the answer was train it on the whole internet and it'll be so much better for you than if it were just trained on your data. So there's a sort of analog that emerges where it's what data is to a model, models are to a harness. Where the more models you expose to a harness, you avoid overfitting that harness to the nuances of that model in particular. And there are certain intricacies about different models that you can learn from and then improve different models performance in your own harness. And this was why, for example, we kind of stopped doing it because Terminal Bench got so bench maxed. But initially when like every new Opus or GPT model would come out, it would perform better on Terminal Bench in Droid than it would in Cloud Code or Codex. Which is why like and this is something that, you know, I think was somewhat frustrating to because I deal like from a lab perspective, you ideally want it so that it's better together because then that means you have to use their harness and you can't use a different one. But I think the reality is it's, you know, having that multi-model harness ends up getting kind of frontier on all of those aspects. Is there a good like example or illustration of that? Conceptually, it makes sense. Is there like an easy way to illustrate it Maybe a good example of it is like if you familiar with the different behaviors of Opus and GPT 5 right now I am He's not. Opus tends to be, I mean, loosely, loosely. I mean, to be fair, honestly, these days I'm not doing it as much either. But I will say this. Loosely, Opus is kind of like that super friendly colleague where you're like, hey, I want to go do these 20 tasks. And they're like, okay, cool. hey by the way five of those tasks i realized we didn't need to do it don't worry about it i got other these done did it this way tonight's not a good time let's pick it up in the morning yeah like let's go let's go get a beer afterwards and hang out whatever meanwhile like gbt 5.6 is like absolutely i will do every single one of those and nothing will stop me i'm not going to sleep until those it's like kind of very ocd and you know meticulous but sometimes you know you want one where it's like it actually realizes hey that list of 20 that you gave me actually here's a better way of doing it anyway. You know, 5.6 is more methodical. If you build a harness for each of those, there are actually different things that that harness will then be good or bad at. So for example, one thing that, you know, typically agents will do is they'll have a to-do list of like, if you have a task, it'll go and generate a to-do list. And the Claude Code harness can in some cases or and this is maybe less relevant now but I think earlier this is just a more illustrative example Earlier it was really strict to make sure it would stick to the to list because the model itself would typically wander Meanwhile, Codex wouldn't do that because the model itself was really, really OCD about that. But if you're a user, you want to have the same experience regardless. You want to make sure if you switch to a different model, you're not going to suddenly lose track of whatever things that you are working on. And so there are certain things where like maybe in some cases you really want robust tool use. And there are tools that you use to do these to-do lists. You want really robust tool use. And you want to make sure that no matter what, if I'm a user, I want to see my to-do list there. Like there were some cases where it would just like not have the to-do list. And so these are things that kind of improve the general performance. And the to-do list matters because you're doing some crazy migration and you don't have the to-do list. And then you're in this long session where there's compaction. That might get lost in the summarization. and now you forgot what your seventh step was and that could be one of the failure modes. That's kind of an example of how- That's a good example. Yeah, yeah, yeah. That's a good example. Okay, so we talked about one type of maxing, benchmark maxing. Let's talk about token maxing. Yes. Because it feels like the world has changed a lot. We've gone from token maxing to now cost, rationalization. What does that mean for factory Yeah so maybe I lay this out just to so we all on the same page of like the way that we see what led us to this token maxing So loosely there was like this phase one where maybe phase zero was like, no one believed in AI. Then phase one, everyone believes in AI. And then boards were like, Mr. CEO, what are you doing about AI? What's your AI strategy? And Mr. CEO is like, shit, I don't know. Like what's our AI strategy? CTO, like make sure everyone goes and uses AI. And so then phase two is you know cto is like okay shit we got to make sure everyone uses ai let's start putting it in performance reviews let's make public like benchmark or public like rankings of who's using tokens the most because everyone's stubborn no one wants to use this stuff they're all skeptical and then we enter phase three which is everyone sees these ratings they see that it's part of their perf reviews and they're like okay i'm gonna use ai for everything and that's kind of phase three it's this token maxing where people are using like opus for literally everything like what's the weather NSF? Opus, tell me, I don't know. Like there are banks that we are working with where they are spending literally hundreds of thousands of dollars a month on people asking things like, literally what is the weather? Or like, tell me about Python. Like trivial questions that you could Google, people are asking Opus. And the reality is this happened because we were so worried [25:00] about adoption that we overcorrect and we're like adoption by any means necessary. And I think that's actually it's like a decent approach. Like it's probably faster to do that and then curb usage or make usage more responsible than it is to start limited and be like, you know, you can only use it for this thing because when you have people that are stubborn, first you want to just prove that it works and then you can get kind of more mature about it. Where factory fits in, I think one of the most important things that we do is that we have the factory router, which allows you to dynamically route to different models based on the task that you're doing. So, you know, if you're asking what the weather is, you probably don't need the very frontier of human intelligence to answer that for you. Or you really do. I mean, it depends. I don't know. It depends on what kind of answer you're looking for. You know, giving you like a full like down to the like molecular level of what's happening. But, you know, allowing that. But also more importantly, for every enterprise, something that no one's dealing with yet, but 12 months from now is going to be the case is not everyone needs the same tokens. Having a blanket kind of token cap for every individual in some large bank let say makes no sense So every CIO is going to need to answer for every incremental token where do we put it And right now it is super not obvious how you would do that Like right now we saying oh you know the PMs who are like vibe coding dashboards get the same token limits as like the engineers who are building like critical infrastructure. That's probably not the best thing to do. Or similarly, you might be dealing with COBOL codebases where Opus is not the best model to use, but instead maybe some fine-tuned model on that codebase in particular. The point of the router is that we can kind of accommodate these different constraints where maybe you say, you know what, this part of the org, they're just vibe coding. They can use Gemini Flash. This part of the org, they're doing COBOL. We fine-tuned this great model to work on COBOL. Let's route to that when we're working on that part of the code base. Maybe this other part, we really care about reliability. So let's generate the code with OpenAI, test it with Anthropic, review it with like Gemini, things like that. And we can actually take in your routing procedure instructions in natural language. So you could even say things like it's not purely deterministic. It can even be like, hey, you know, Pat, I don't know. Like, I don't know what he's doing. Like, give him flash. Or you know I think we really need to avoid having them use open models because you know whatever reason we don like the way open models perform here And we do internal benchmarking to know which models are better at which of these tasks How close are the open models at this point Which one the best GLM 5.2 is incredible. It's at the point where internally we have no token limits for our engineers. And like half of our tokens are open to open models. Wow. Yeah. Because they're just faster and they're cheaper. They're just as performant. And I think the thing that everyone gets wrong is everyone is comparing like GLM 5.2 to the latest model like Opus 4.8 or GPT 5.6. But really they should be compared to Opus 4.7 or GPT 5.5. Why? Because generally the open models come later and they're kind of a generation behind. And that's kind of the frontier models will be frontier. The question is, are the open models getting as good as like frontier minus one? And the answer is unequivocally yes, which I think is a really, really interesting outcome. It's great for consumers. And by consumers, I don't mean like individuals. I mean the consumers of the APIs, because if you're a business that is doing software engineering, your job is at a very high level to solve problems. And if we can allow you to solve those problems faster and with cheaper models that are just as performant that means you can solve more problems Like that is a good thing And it is a very good world where there is not like a monopoly on intelligence but instead kind of a garden of intelligence that you can pick and choose, you know, when you'd like. Something that we joke about is like, you know, on this intelligence allocation thing, if you're trying to get a tutor for your daughter in algebra, you can probably find someone cheaper than Albert Einstein to be that tutor. Now, it might be that she eventually goes and becomes like a leading physicist or something, in which case, yeah, maybe let's get Albert Einstein in there. But most likely you can get a high school student or something like that. And it's probably much more cost effective for you as well to do so. Since you guys do the model wrapping, like if you look at the, you know, if there's a pie chart that shows the complexion of models being used by your customer base today, what did it look like a few months ago? What does it look like today? What do you think it'll look like in a year? Yeah. I will caveat this with saying that right now enterprises haven't gone too opinionated yet into the routing procedures. Okay. This is something that will happen over the next six to 12 months. But right now they're just going from no router to router. That's kind of the first change. Then it's going to be like the exact nature of the routing. At the beginning of the year, there's less than 1% of tokens. [30:00] went to open models. In the first quarter, it became a single digit percent. It is now crossed into being a double digit percent of tokens. Now, percent of tokens is not always the same as percent of cost because the open tokens are cheaper, but it's pretty crazy to see the growth there. What's your forecast? My sense is that we will asymptote towards vast majority being open just because it provides you more optionality and it's cheaper. But that doesn't mean they're going to be like that's of token share, not necessarily of leverage share, because maybe there are 1% of tokens that are incredibly, incredibly valuable and are like very key decision making. And then the rest are more like implementation tokens or kind of lower stakes, if you will. I don't think there's going to be a world in which like it's ever going to be 100%. I think the frontier of intelligence will inherently always be valuable for every business just because the stakes are going to get higher and the kind of intricacy with which you think is going to be more important but we'll be better at offloading certain tasks and this is like you can loosely think of this already with the way orgs are structured where you know in general engineering leaders are more tenured engineers who in theory have like more wisdom and each kind of minute of their brain power is higher leverage in theory And even, you know, you can also imagine like consider a human engineer and try mapping over the course of their day, like how much brain power they're using. And like, you know, it's probably going to be really low for a lot of it. But then there are going to be some moments where they're like going pretty high. like they're deeply concentrating and thinking about some, you know, systems design problem or whatever, all of those low leverage moments, we want to automate away. And like, we want to like those like very high leverage moments, sometimes like, you know, we're referring to them as like the eureka moments or the moments where they're like doing something that's very high leverage. What if those aren't just moments, but what if those are like hours at a time? Because you don't have to deal with all the other stuff. And I think that's kind of the way to think about intelligence allocation is if you're an engineer and you're writing docs, that is such a low leverage use of your time. Like you've become an expert in your craft and you used to spend hours writing docs. Like I remember it was actually valuable. Like I remember Stripe had so much alpha for just having incredible docs, but imagine all the other stuff those incredible engineers could do if it wasn writing documentation Like we should live in a world where everyone can have docs as good as Stripe And that is like strictly beneficial for everyone And then the question is okay what do those really smart engineers do with their time once they don have to do that Maybe this is a good time to talk about business model, given that, you know, especially the rise of open-weight models, the cost differential, I imagine that means very different things for your cost structure, but very similar value delivered to customers. How do you think about business model pricing? Yeah, this is more what our customers want and need as opposed to what we want and need. So, for example, I think right now usage based is clearly the way to go. We want to be aligned with like what they are doing and what we are doing. I think seat based doesn't make sense, at least for what we are doing. My sense is that eventually we will change to outcome based. Now, I don't think the enterprise is ready for that. And we've learned our lesson from those first two years. We are not going to impose things. Right. But my suspicion is that, you know, in the 2030s, things will probably look more like outcome based. Yeah. What does outcome based mean for your market? What would be the definition of an outcome? So maybe here's a way to put it. So right now we are usage based. Like the more tokens you use, you know, the more you pay, the more we get. Now since we are model independent we kind of with our router we are kind of pointing a token cannon at either OpenAI Anthropic AWS GCP you know any one of these people To a certain degree this is like a really dumbed down version of a marketplace. Where right now, there is a buy, the buy side is an engineer who wants a task done. And then you have the model providers who are saying, like, either in benchmarks right now, they're like, we perform at this cost and this performance. And then we determine who we go to for that given task. There's a world in which, you know, if it's so important to get these tokens, they might kind of bid in a certain way of saying like, look, here is our cost for this task. We will get this task done at this cost no matter what. But they're pricing it such that, you know, they hope that they can make a margin there. They price it wrong. They're at a negative margin. If they price it right and win the bid, then they get the positive margin. And the way you determine if the task was successful is by some validation loops, because no one is using these tools anymore where it's just like, write me code. Great. Thank you. It's generally write me code. And here's how I know it was done well. And similarly, if you are like a model lab and you are given here's a task, here's the validation criteria, you'll be able to say roughly how much you think. [35:00] you would be willing to pay to get those tokens. And you want to have some margin on that. And then in that world, that's basically, that's a way that you kind of dynamically shift from usage-based to outcome-based. I think that there are so many questions with this, and this is very much forward-looking. But I think there's a lot of questions about how do you subdivide tasks? Divvying that up, I think, is something that's not obvious. But as these tools get better, doing things like that actually become way easier. Yeah, that's fascinating. Yeah. Yeah, If you can scope a task and then create a competitive marketplace, that'd be a fascinating version of the future. Yes. And as a user, it then creates an incentive to be very thorough in your validation criteria. Yeah. Because like, you know, there are stories of like, you know, you ask an agent to like fix my code and it deletes your code. Yeah. It's like, you know, the solution is just get rid of it all. It's like that Silicon Valley episode. It's crazy how precious it was. Yeah. But like, so you need to make sure your tests are very thorough because technically it could hit all of your validation criteria. The son of Anton will go rogue. Yeah, exactly. Yeah, yeah, yeah. Yeah, yeah. Good reference. maybe zooming out a little bit you named the company factory actually named a droid before before factory that's right but you named it factory before this concept took off and now it feels like everybody wants to build a software factory where do you think we are today in in terms of the building of software factories and how close are we to the ultimate vision of a software factory Yeah everyone has a software factory whether they know it or not It just a very inefficient one So it's kind of like it feels like, you know, pre-industrialization where like, you know, people were manually like, you know, sewing things together or like woodworking or whatever it might be. And these things are very inefficient. Like right now, if you go to an organization that has more than 10,000 people and you're to ask about the process by which they decide and release a feature, there is like hundreds or maybe thousands of people in that process. And most likely they couldn't even draw it for you. Like there's very low likelihood that they would know what that process looks like. That is not because they think that is the right way of doing things. That is just kind of the nature of building large software as it is kind of today. But with these systems, so much tribal knowledge can be codified. So much of this stuff that typically would require, oh, we need to ask this guru who's been here for 30 years, who has the wisdom. Oh, we then need this approval and that approval. Oh, and I forgot there was some doc that said we always have to do this checklist. And it relies so much on kind of human behavior and like redundancy. So much of that can be automated and refocused on like what actually moves the needle for our business And I think this move towards software factories is a move towards how do we figure out what are the actual inputs that determine what features we need to build And that might be inputs from the customers, inputs from the market, inputs from like, you know, product leaders at the company. And let's be very clear. These are the signals, the inputs that we are taking in here. Okay, great. We have those signals. Then what is the process by which we build this? And really like mapping out the like assembly lines of how you are building software is really important because then you get to close the loop and say, did this actually deliver outcome for our business? Talking before about the tokenomics, if you're that CIO and you're faced with that question of where do you put every incremental token, really the question two years from now is going to become where do you put every incremental dollar? And so you're going to have to be asked, do you put that incremental dollar towards headcount or towards tokens? And if tokens, to where in the org. And these are things that you can only really know when you have these kind of feedback loops that give you examples of like, hey, by the way, we made those decisions based on this data. And it did not matter at all. We added these new features and no one cared. It didn create more retention It didn create more usage or whatever metrics that business is looking to optimize And the only way to do this is like you need kind of more rigor and more process it almost feels like like 10 years from now we going to look back at this previous era of software and it's going to feel like businesses in like ancient times where they didn't do accounting it is like it's going to be like it's going to be like marketing in the day of mad men yes where it's like all creative and you have no idea what's actually working it makes no like it's like oh yeah let's ship that feature oh i think it went well like yeah we had got some metrics on that yeah it's like no if you guys read the the blog post that jack dorsey put out about how every company is like an agi yeah there's also this degree to which if your company is an agi you want to optimize the weights yeah you want to figure out what nodes are doing what things which are load bearing which are not which need more tokens where do you need more nodes and in order to do like you don't train a model by vibes i mean okay actually you kind of do but You don't, I guess, more importantly, you don't do back prop in a model by vibes. Like you are running those actual like calculations and you are seeing when we change this node, what happens. Now, you might be making bets on how to change the model by vibes, but you're like, it's pretty like mathematical in what you are doing. Meanwhile, at companies, you know, people are determining token budgets just by shooting from the hip. People are... [40:00] laying people off by shooting from the hip and just being like, oh yeah, like 20,000. There is no way there is science to laying off 20,000 people. That is just like, here's a chunk and let's just see what happens. Instead, I think in these organizations, the way they can do things is much more mathematical of like, this part of the business matters a lot and does better if we give it more tokens. It doesn't actually matter if we give it more humans. So let's give them more tokens. There might be other parts of the business where actually giving them more tokens doesn't matter, but more people matter because if we build more relationships with our customers and deeper relationships with our customers, that matters. But these are things that we're going to need like quantitative insight on. And you need a software factory to do that. Otherwise you're just like shooting from the hip and just guessing, which won't work as well. In the limit, how much do you think people will spend on tokens versus on engineering? It'll depend on the business. I think every business will have a balance and it just depends like, but they're just going to be like an easy example is generally salespeople. They probably don't need that many tokens if they're good salespeople, because generally where they provide the most alpha is like when they're in the seat face to face with their customers talking about the customer problems understanding how they build software in our case and how we can make that more efficient more productive They can use tokens a little bit of like oh whatever generate them some you know AI debrief, take some notes, like help them with a follow up. But like, that's so minimal, the number of tokens, it basically doesn't matter. Like, if you add more tokens to the sales team, it probably won't change their output. If you add more humans to the sales team, it probably will. Meanwhile, engineering teams are pretty different, where engineering teams, generally, it seems like the you want people to own an outcome end to end. But then if you give them more tokens, they can produce a lot more. And so it seems like there and then there's a lot of kind of places in between of like operations, finance, marketing. These are places where are neither here nor there, where I think they're there's somewhere in between. And it kind of depends on your business. But I think every business is going to have to ask, like, what is our core competency? Something that we see a lot in the market, or we used to see, and now they finally kind of hit reality. But what we used to see is, oh, like we're going to build our own like software development agents. And we're like, OK, like you're a like a consumer like logistics company. Are you sure you want to do it? Yeah, we have to do this. And it's like, OK. And then six months later, it's like, wait actually this is not a core competency for our business We don want to hire you know AI engineers to be doing this Our core competency is you know consumer logistic That what we want to focus on And I think this is an opportunity for every business to double down on their core competency and what matters for them, and then procure externally, whatever it is that doesn't matter for them. Like a trivial example of this is like, I don't know, in the days of the early internet, you probably had to be a programmer to build a website. And like websites generally help if you're a pizza shop, because you want to have, you know, people come to your pizza shop, They want to be able to or like whatever at that time. Would you say it was a core competency of like a pizza shop to have engineers? Like certainly not like that is kind of a byproduct of like a brief moment in time. But then there were companies out there that help you build a website. You don't need to be technical. And then this is why we live in a world where like most pizza shops don't have an engineering department, which I think is probably a good thing. And I think similarly, a lot of businesses have dealt with the reality of if you want to do X, Y, Z other thing, you have to bring in people of this type of role. But I think that's been like something you had to do, not because it's a core competency of the business and allowing businesses to focus and double down on the things that they are best at, I think is going to be good for the consumers of their business. And so I think we just going to see like a lot like ruthless refocusing on what actually matters which is going to be cool to see Well and that a you know every company kind of has to go through this process of reinvention You know 10 or 20 years ago people talked about digital transformation And I don't know if anybody's given it a buzzword now, but AI transformation, something of that sort. A couple of years ago, you ran into a bunch of organizations that just weren't ready to deal with autonomous agents. Things you've seen your customers start to change. And so the question is, when you look at your customers, as they kind of go up this maturity curve and sort of reinvent themselves for the future, any good like tricks or techniques that you've seen them use to repot themselves a bit? Yeah, I mean, I think surprisingly, like the companies that have been doing like company wide hackathons really end up doing well. it seems like relatively trivial but like just setting aside a day for everyone in the workforce is just like build shit with ai it really sets the tone and sets the pace so just give me a look i i tried to force him to build something with coding agents it didn't go so well we'll work on it we'll do after this you know we gave it a great effort but that's it like it literally just setting aside the time to like do it and like even if it fails miserably like it's fine and also like the orgs that are okay with failing. It feels like there are some who are like, [45:00] to do it exactly right. We need to make the right decision from day one. No, like you're going to make mistakes. Everyone is going to. And the orgs who are kind of leaning into it and embracing it to a certain degree, I think are succeeding. Like one of our largest customers is EY. EY is not necessarily known to be like at the absolute frontier of AI, but I think for them, they were just like, look, this matters. We were kind of, there've been other transit transformations that we relate to. We're not going to be late to this. Like, we're just going to go in, we might mess up, But like obviously respecting like the things that you're not allowed to mess up. Sure. Put those aside. But like let's go and get our engineers to mess around and build this stuff and see where it breaks and understand what they like and what they don't like. I think that really matters a lot in the ones that we're seeing succeed. And also the ones who are like pretty bold in reinventing the processes that they put in place. And just saying like, hey, there's no sacred cows. Like let's put this aside. Try something out. If it doesn't work, put that sacred cow right back. And I think that's that's been kind of a determining factor there. And when it comes from within, if it comes from the board, probably not going to go well. Yeah. If it comes from within like the tech team or the ICs or the leadership that when we see it go better Do you have any predictions for the most important changes that are going to happen in your space in the next call it 12 months A lot of AI consumption is going up like crazy and everyone super super excited because the revenue is going wild. Like a lot of this is synchronous usage. In other words, like if everyone woke up sick tomorrow, like a lot of Claude code usage would be zero because it's all just hey cloud code or hey codex or hey droid right i think in 12 to 24 months like 90 percent of tokens will be asynchronous tokens so these are going to be you know droids on their own autonomously being like hey here's some signal that i found from a customer let's go fix it or let's go create a first pass solution to this and i think that is going to be where the real like agent native stuff begins because right now we're still kind of in like co-pilot mode like if you're going to an agent and say, hey, go do this for me. It is more agentic because it's not going to come back and ask you a ton, but it's still like you are kicking it off. If you guys have ever been to Tesla's factories, which is one of the sources of inspiration for the name is like, it's just robotic arms everywhere going and doing stuff. It's not like there are people there like going and attaching the widget to the thing. And this idea of like a dark factory where like the lights are off and things are just happening that is where software development is going That kind of where the name came from is like you know Elon was always talking about the factory is the machine that builds the machine And that been something that we took to heart And I guess also that combined with his whole thing about how you're destined to become the opposite of your name. And in our case, factory becomes artisanal. It's kind of a good flip there. What's your most optimistic version of the future, both for factory and for the world at large? So I think short term, there's going to be a lot of turbulence because I think a lot of companies have misallocated resources pretty poorly. There's been a lot of bloat. And I think the correction that's going to happen there is going to be really painful for a lot of people. And I think that's something that I think every AI CEO should really bear much more responsibility than they currently are for. and also figuring out ways to like address and kind of ameliorate in some way because this is something that's gonna be very painful for a lot of people. Now, I have optimism that we can actually address that faster than we think. We just need to start now in terms of addressing that. Now, the longer term and why I think this is a good thing is why I don't believe at all like, you know, the BS that people are saying, oh engineers are going away Generally there is a huge number of problems in the world A large subset of those problems can be solved with software A small subset of those problems are currently being solved with software And so in the short term, this means that, okay, first, there's a given problem that was over allocated engineering resources. So, okay, we need to reallocate those. Reallocate those is a very kind of cold way of saying some people are going to lose their jobs. But I think the thing that's going to happen in the longer term is we need engineers. Engineers are some of the best systems thinkers and the best problem solvers. And there are so many problems that can be solved with software that are not being solved with software. And so that means that we are going to take those engineers and have them go and solve problems that previously were not being solved. That is such a net good for the world. Because again, there are so many of these problems that we are not solving. And also there's so many problems that we are maybe solving, but with really shitty software. And like, this is going to enable people to solve it with incredible software. And, you know, the vision for factory is that we are kind of the factory that allows them to go and build this incredible software to solve these different problems. And these problems range from like things that are trivial to, you know, like government software typically is not very good, whether it's like DMV or like IRS web, like all that stuff is generally a pretty poor experience. We don't need to live like that. Like we can live in we can live in a world that's not good. [50:00] all software is really fantastic. But also things like, you know, pharmaceutical research, like so much that goes into solving diseases is not just like a biology problem. A lot of it requires the best software engineers in the world. And previously, those problems haven't allocated the right dollars to attract the best engineers. But now because of what's happening, I think we will be much more closely allocated to like, these are the biggest problems, let's get the best minds and the best problem solvers to solve that. I think it's kind of our job as an industry to do that reallocation as quickly as possible. So it's not 10 years, but maybe like six months or a year. Wonderful. Matan, I think the clarity and consistency of your vision over time has just always been very inspiring. And then just seeing how much you've grown as a leader and how much factory has grown as a company, even since the last time we did this training data episode, it's truly awe-inspiring. So thank you for joining us again to share what you're up to. I appreciate it a lot. Thank you. Thank you. Woo!