"那 1,980 个现在得由我来维护":代码变便宜会不会取消开源供应链的理由、harness 与模型路由被拆成两层,以及一位 EVP 拒绝把 token ROI 算成收入(Latent Space × Jay Parikh,2026-11-08)¶
- 嘉宾: Jay Parikh(Microsoft CoreAI 的 EVP;⚠️ 转录稿把姓写成 "Parrick")
- 主持: swyx
- 来源: YouTube · 23 分钟
- 转录稿: sources/latent-space/20261108-rSWiNE92xqM(⚠️ 自动字幕 en-orig,无说话人标签;转录稿只有
>>标换人,逐句归属为本库的编辑判断)
⚠️ 节目形态必须先写:这是 GitHub Universe 主题演讲结束后的现场采访(开场第一句就是"我们就在你的 keynote 之后录",[00:03:01]),约前 3 分钟是 swyx 的独白开场,采访本体约 20 分钟,末尾约 1 分钟是关于会议徽章(一块能连 Copilot 的 Game Boy)的闲聊、无 AI 实质内容。
⚠️⚠️ 立场:受访者是 Microsoft CoreAI 的 EVP,而本期几乎是同日产品发布的延伸——全部数字(Octoverse 统计、agent 占比、安全能力、成本控制功能)为自述或自家报告,无第三方核实,本库一律记为自述口径。 ⚠️ 主持方同时在筹办自己的会议(AIE Code),期内把 GitHub 侧称为长期合作对象、并把一位用户(Peter Steinberger)称作"我的讲者"。 ✅ 但本库判本期厂商色彩明显偏轻,依据是三处他没有顺着送上门的有利说法走:① 他拒绝了主持人递过来的"代码已经不重要了"(第三节);② 他拒绝了对卖 token 一方最有利的 ROI 口径——把 token 支出接到收入上(第五节),✅ 本页判这一处是全期厂商色彩最轻的地方;③ 在"用开源还是全部自己重写"上他给的理由是维护负担转移,而不是自家产品优势(第二节)。
⚠️⚠️ 两处口径必须分开记,否则容易被当成同一来源: - ① 开场那两个关于 agent 的数字出自 swyx 本人的独白,不是 Parikh 说的,而 swyx 没给来源([00:00:00]–[00:01:00]):"GitHub 上大约 40% 的 pull request 是 agent 创建的"、"agent 总量在 6 个月里涨了 6 倍"。⚠️ 本库记为主持人未注来源的转述,与下面 Parikh 给的 Octoverse 口径分开。 - ② swyx 开场那句"今年第一个达到 0 个 9 的可靠性的服务"是在拿 GitHub 的宕机开玩笑("zero nines"),不是一个指标([00:00:00])。⚠️ 本库标出这一条,因为自动字幕把它写成 "09s",容易被误读成一个正面数字。 ✅ 而他随后自己承认了这个立场的局限:"不过我们当中谁又能在宕机这件事上扔石头呢。"
✅ 本页认为这一期值得长期保存的是五处,其中两处是本库此前完全没有的: ① ⚠️⚠️ 本库第一条关于"代码变便宜会不会取消开源供应链的理由"的正面交锋,而受访方的反驳是一条成本转移论证、不是产品论证:swyx 的挑战是"GitHub 和我们的开源供应链建立在'代码很贵'这个前提上,而也许现在代码很便宜了……也许最好的加固方式就是把一切 vendoring 掉或者重写掉"(把 2,000 个依赖砍到 20 个) → ⚠️⚠️ Parikh 的反驳:"我有 2,000 个开源项目在用,我去掉 1,980 个、只用 20 个,但那 1,980 个现在得由我来维护了。" → "所以这是一个你必须选择把你的钱、你的人、你的时间放在哪里的问题。" ✅ 本页判这条值得保存的理由是它把答案定位在"谁拥有那段代码的维护责任"上,而不是定位在生成成本上。 ② ⚠️⚠️ harness 与模型路由被明确拆成两层,并各自给了"工作职责",而本库此前的 harness 材料没有一条做过这个拆分:harness 负责工具、MCP、模型的编排(已作为 SDK 放出,"你可以拿那个 SDK 去构建别的应用");而 Fusion 负责选模型——"把认知负担从你这个工程师身上拿掉,你面对的是一堆价格性能各异的模型",目标是"我们可以帮你优化掉这件事。我们能让你很快拿到最好的质量,而且便宜得多"。✅ 他给的关系是"harness 和 fusion 一起起伏(ebbing and flowing together)"。 ③ ⚠️⚠️ "同一个 harness 跨全部界面"被讲成一条护城河,而它的形状是上下文复利:手机上发起、桌面上接着做,而"上下文、记忆、偏好、那个智能引擎,全都在一个地方为你复利" → ⚠️⚠️ 竞争性主张:"今天如果你用一家提供商的一个工具、然后切到另一家,它们不会把各自的智能复利到一起。" ⚠️ 本页标注这条把切换成本重新描述成了用户收益,而那正是锁定效应的标准讲法;但本页同时给出它可检验的部分(见第四节)。 ④ ⚠️ 一个被主持人当场指认的激励错位:"你们展示的那些成本控制功能,其实是实验室不做的事,因为他们希望你尽可能多花。" ✅ 本页判这条有用,因为它说明"帮客户少花钱"这个功能只可能出现在平台侧而不是卖 token 侧——而这是价值捕获往哪一层移动的一个具体例子。 ⑤ ⚠️⚠️ 而本页判全期最该被单独保存的一句是他拒绝了一个对自家更有利的 ROI 口径:对话走到"我这周花了 1,000 美元 token……然后如果你能说我产生了 25,000 美元收入,那就挺不错"时——"我觉得收入有点太……作为一个写代码的人我不负责收入。但至少我交付了功能。" → 替代口径是"成本节省,或者说这提高了参与度、留存,或者改善了 CSAT——这些都是可度量的,而作为产品团队和工程团队,你应该挂在这些结果指标上"。
一、⚠️ Octoverse 的口径:可逐年核对,但全部是自家报告¶
([00:03:01]–[00:04:01])⚠️⚠️ 全部为 GitHub 自家年度报告(Octoverse)口径,本库记为自述、未核实;但本库标注这组数字的价值在于它们逐年可比。
- 平台规模:2.25 亿开发者(⚠️ swyx 先说 2.2 亿,被 Parikh 当场改成 2.25 亿),"覆盖世界上每一个国家"。
- ⚠️ 增速口径:"去年在我们的 Octoverse 报告里,每一秒都有一个新开发者加入平台。而那是连续第二年发生这件事。" ✅ swyx 当场把它换算成一个可检查的数:"我真得去查了一年有多少秒,因为你说今年每一秒都有一个开发者加入。那是 3,150 万。"
- 活动量:170 亿次 code push(17.9 billion)、343 亿次 commit(34.3 billion)、13 亿个 PR(1.3 billion)。
- 开源侧:开源社区的贡献同比"涨了两倍半",约 15 亿次贡献(⚠️ 转录稿此处写成 "2 1.5 billion",数字残缺;本库按上下文记为约 15 亿,并标出此处不可直接引用)。
- ✅ swyx 做了一个本页认为有用的注脚,因为它把"贡献"这个词还原成了基础设施负载:"而对在听的开发者和工程师来说,那些都是数据库写入、文件写入、元数据计算。"
- ⚠️⚠️ 而开场那两个 agent 相关数字必须与上面分开记,因为它们出自 swyx 的独白、无来源([00:00:00]–[00:01:00]):"大约 40% 的 pull request 是 agent 创建的"、"agent 总量在 6 个月里涨了 6 倍"。✅ 本库标注:如果这两个数字成立,那么上面那 13 亿个 PR 里有相当一部分不再对应人的决策,于是"PR 数"作为开发活动指标的含义已经改变了——而本期没有人处理这件事。
- ⚠️ 本期另提到一期本库尚未收录的访谈:swyx 说"我们此前采访过 GitHub 的 COO"(⚠️ 姓名在转录稿里写作 "Kyle Dagel",本库不确证拼写,也未收录该期)。
二、⚠️⚠️ 本期最该被保存的交锋:代码变便宜,开源供应链还剩什么理由¶
([00:17:15]–[00:18:18])✅ 本页判这是全期最该被 开源与基础设施 与 LLM 安全 同时引用的一段,而且它是本库第一次拿到这个问题的正面交锋。
swyx 的挑战(本页认为这个提法本身是材料):
"我在想的一件事是安全与开源之间的关系。我觉得 GitHub 和我们这条开源供应链,是建立在'代码很贵'这个前提上的。而也许现在代码很便宜了。也许安全评审其实也很便宜了,而实际上加固我们系统的最好方式就是把一切 vendoring 掉、或者把一切重写掉,因为它便宜。然后就不依赖开源。" 他把它具体化成一个数:"我的依赖是 2,000 个每个人都在用的核心软件件。它们全都是可被攻击的表面积。也许我就把它们减到 20 个。"
Parikh 的反驳(本页判这是本期最有迁移价值的一步,因为它不依赖任何产品优势):
✅ 他先接住了这个问题:"我不觉得这太离谱,因为这确实是我们被问到的一个问题。" ⚠️⚠️ "我也不觉得那是万灵药。因为,嘿,我在我的东西里用了 2,000 个开源项目,我要去掉其中 1,980 个,然后用剩下的 20 个——但那 1,980 个现在得由我来维护了。" "所以这是那种你必须选择把你的钱、你的人、你的时间放在哪里的情况。"
- ✅ 而他的处方被明确说成一个方向选择:"而且我觉得开源里正在发生的事情有太多是重要且有价值的。我不觉得那会停下来。如果说有什么变化,我觉得开源对企业、对构建者、对创作者的价值只会从这里继续上升。" → "所以让我们去解决那个问题,也就是让开源里的东西变安全,而不是所有人都走进某种围墙花园的路子。"
- ✅ 本页标注这条为什么值得长期保存,以及它可以怎么被检验:⚠️⚠️ 它把"代码变便宜会不会取消开源供应链的理由"这个问题的答案定位在维护责任的归属上,而不是定位在生成成本上——重写一次是便宜的,但拥有那段代码之后的每一次安全修复、现代化与升级都变成你的。 ✅ 而这是可检验的:如果 vendoring 真的成为主流,应该先看到企业内部代码库规模与内部安全/维护投入同时上升,而不是只看到依赖数下降。
- ⚠️ 本页记下这段里 Parikh 没有处理的一步:swyx 的前提有两段(代码变便宜、安全评审也变便宜),而 Parikh 的反驳只针对第一段。如果安全评审与维护本身也被 agent 大幅压低成本,那"那 1,980 个得由我维护"这个成本就不一定是决定性的。 ⚠️ 本期没有人提出这一点。
- 🔗 本库既有的相邻材料:Nathan Lambert 关于开源经济为什么结构性更慢、Arora 关于 agency 与责任归属(⚠️ swyx 在本期也提到了"最近 PHP 那件事",[00:14:10])。
三、⚠️ 他拒绝了送上门的"代码已经不重要了"¶
([00:08:04]–[00:09:05])✅ 本页判这一处值得记,因为顺着主持人走对他更有利,而他没有。
- swyx 的提法:keynote 上被重点展示的一个仓库"就是一个 markdown 文件夹,全是 markdown"(⚠️ 作者名在转录稿里写作 "Matt PCO",本库不确证)→ "这确实让我想到 GitHub 那套语言占比——哦,这个仓库 76% 是 Rust——50% 已经不重要了,对吧?那什么是仓库?什么又是代码?我们在存什么?"
- ⚠️⚠️ 而 Parikh 只同意了一半:
"我同意你。但我觉得还有大量代码存在。你想想所有那些用 Java 和 .NET 写的、今天在跑着业务关键的庞大生意的代码。" "所以那些都在这个过程里——你得做安全修复,你在把它们现代化,你还在优化它们,你还在修 bug。所以记住,它跨越很多不同类型的内容、文本,而其中一些东西有几十年历史。" ⚠️ "而其中一些,正在我们说话的这会儿被 vibe code 进生产。"(⚠️ 转录稿把 vibe-coded 写成 "viodated",本库按上下文判定)
- ✅ 他的收口落在选择权,而本页认为这句是他的方法论自陈:"所以我觉得这就是工具必须灵活的地方,而外面有很多选择。而我们也在意、也相信开发者需要选择权。我自己就是个开发者。我对某些事很挑,而且……在某种意义上这是我的个性,或者说有一种手艺,是我用我用的那些工具表达出来的。"
- ✅ 本页标注这条的位置:⚠️⚠️ 本库此前关于"代码的本体变了"这条线的材料(markdown 即程序、spec 即源码那一类)几乎全部来自主张变化的一侧。这一条是第一次由一个掌管全部存量的人给出反方,而反方的依据是存量而不是观点——数十年的 Java/.NET 业务关键代码仍在被修改。
⚠️ 相关的一条:PR 会不会终结¶
([00:06:03]–[00:07:04])
- swyx 引的是 Peter Steinberger(OpenClaw 作者)的推动:"他有一个有意思的推动,是 pull request 的终结,也许。" ⚠️ 他把这位用户描述成"你们最顶的 0.001 百分位用户"。
- ⚠️ Parikh 的回答是可配置性,而不是对这个方向的判断:"所以如果这些概念之一没用、或者人们不想要它是必需的,那它可以变成可配置的。" → 约束条件是规模:"但记住,跨越 2.25 亿开发者、大企业、小公司、学生等等,我们确实必须提供一个有很多概念的平台,然后你应该能把这些概念组装起来、按你想要的方式工作。"
- ✅ 而他自己给了一个一手例证,本页认为这比他的产品表述更有信息量:"我有些仓库是我自己瞎折腾玩的,我不做 PR。对我来说我就是不停地往里丢想法,我就是在建、建、建、建,我不想处理 issue 或者 PR 或者任何东西。"
四、⚠️⚠️ harness 与 Fusion 被拆成两层,以及"上下文复利"这条护城河主张¶
([00:09:05]–[00:14:10])✅ 本页判第一半该被 LLM OS 与 用 LLM 的实践 引用;第二半是一条厂商主张,本页按厂商主张处理并给出检验点。
① ⚠️⚠️ 两层各自的"工作职责"¶
- swyx 先给了一个定位:"Copilot 是第一个 harness"(⚠️ 他对时间的说法是"三年,四年,也许四年"),而"harness 在最根上的核心工作,就是把模型能力榨到最大,其中很大一部分就是模型路由"。
- ⚠️ Parikh 对 harness 的描述([00:10:06]):已作为 SDK 放出("你可以拿那个 SDK 去构建别的应用,我自己做过,很多人也做过");"它背后的关键原则之一就是多模型";而它必须持续适配"MCP、你为写代码或别的事需要的其它工具、以及进来的不同模型"。
- ⚠️⚠️ 而 Fusion 被说成另一层,职责是把选择的认知负担拿掉([00:11:07]):
"然后你需要某种智能,知道怎么把一个任务、一个 prompt、某个最终会成为一个完成的软件工作单元的东西拿过来、拆开,并且在某种意义上把认知负担从你这个工程师身上拿掉——你面对的是所有这些价格性能各异的模型之类的东西——然后说:嘿,我们可以帮你把这件事优化掉。我们能让你很快拿到最好的质量,而且便宜得多。" 关系:"我看它的方式是,你把 harness 和 fusion 想成一起起伏的,因为你解决的恰恰是那个问题……你要有 fusion 来帮你搞清楚用哪个模型,因为今天选择太多了。"
- ✅ 本页标注这条为什么是新的:⚠️⚠️ 本库此前关于 harness 的材料(Ali Ghodsi 的"2 倍成本"、Lio 的 80% 天花板、Reducto 的"harness 挡的是静默漏抽")都在讲 harness 值多少钱、能到多高、挡哪种错,没有一条把"选哪个模型"从 harness 里单独拆成一层。这一条是第一次。
- 🔗 ✅ 而它正好是本库既有的 fusion/路由那条线在超大规模厂商侧的对应:Alex Atallah(OpenRouter)与 Amjad Masad 的"用 AGI 级模型干所有事是用核弹打蝴蝶"、"fusion 把前沿质量做到四到五折"。⚠️⚠️ 本页标注两者的差别:那一条来自一个中立路由方,论证是经济性(便宜几折);这一条来自一个同时拥有 harness、界面、云与模型的厂商,而它给的理由是认知负担。 ⚠️ 本库记下:对一个自家也卖模型的厂商来说,"我们帮你选模型"这条功能的中立性无法从本材料判断,而本期没有被追问。
② ⚠️ "每个界面都是 Copilot":swyx 的提问比答案更直接¶
([00:12:09]–[00:14:10])
- swyx 的问法很直:"你们是觉得必须在那儿创新,还是说它基本上就是别人也有的东西的 Microsoft 品牌版?你们必须在 UI 上创新,还是只要在模型层做得好就没事了?"
- ⚠️ Parikh 的答案是"两者都要",并把它讲成全栈演进:"在每一层做创新和演进——最底下的低层基础设施、存储、计算、网络、安全,然后是平台层(git、actions、AI gateway,以及支撑今天 git 的很多其它服务),然后是工作流、以及各个界面。" ✅ 他给了一个说法:"因为那在很多意义上是一条铺好的路(paved path)。"
- ⚠️⚠️ 而那条护城河主张是([00:13:10]–[00:14:10]):
"现在它们全都用同一个 harness 连起来了。所以这非常有力,因为你可以在手机上发起一个东西,然后在桌面上接着做……但重要的是所有那些上下文都跟着你——在你的 repo 里、你的 issue 里、你的 PR 里、你的安全发现里。" "而且不管你用哪个模型,你可以用不同的模型,但所有那些上下文、记忆、偏好,还有我今早讲的那个智能引擎,全都在一个地方为你复利。" ⚠️⚠️ "今天如果你在用别的工具,如果你用一家提供商的一个工具、然后切到另一家,它们不会把各自的智能复利到一起。所以那就是我们想解决的。"
- ⚠️⚠️ 本页的处理:这条把切换成本重新描述成了用户收益,而那正是锁定效应的标准讲法;本库不采信"所以对用户更好"这个结论。 ✅ 但本页记下它可检验的部分,因为"复利"这个词本身给出了一个方向性预测:⚠️⚠️ 如果上下文复利是真的,那么换工具的代价应该随使用时长单调上升,于是流失率应该随使用时长下降得比单纯的习惯效应更快。 ⚠️ 而本期没有给出任何这方面的数据。
五、⚠️⚠️ Token 支出治理:一个被指认的激励错位,以及他拒绝的那个 ROI 口径¶
([00:20:19]–[00:22:20])✅ 本页判这一节该被 AI 商业模式与价值捕获 引用,而最后那一处是全期厂商色彩最轻的地方。
① ⚠️ 那个激励错位是主持人指出的¶
- swyx 的观察:"而你们展示的那些成本控制功能——那其实是实验室不做的事,因为他们希望你尽可能多花。"
- ⚠️ Parikh 的产品侧回答(自述):为组织拆解支出("这里是我们为了让你了解你的支出所做的全部事情") → 给优化建议("嘿,你在这些类型的用例上用了这个模型,也许你该用另一个模型") → "而尤其是财富 500 强,他们要治理、他们要能设上限,所以我们必须在那里提供控制与治理。"
- ✅ 本页标注这条为什么有用:⚠️⚠️ 它指认了一个结构性的动机差——"帮客户少花钱"这个功能只可能出现在平台/工具侧,不可能出现在按 token 计费的一侧。而这是价值捕获往哪一层移动的一个具体例子:当模型本身趋于可替换,"管住花钱"反而成为平台层的差异化。 ⚠️ 本页记下这条推论是本库的,Parikh 本人只讲了功能。
- ⚠️ 他把这件事列进了 2027 的两个主题之一(术语在转录稿里写作 "POPS",⚠️ 本库判定为 FinOps 之类的表述、不确证):"另一件会更被放在心上的事,一是安全,二就是——嘿,我怎么管理我在 token 上的全部支出,因为这是这些天一个非常热门的话题。"
② ⚠️⚠️ 而本页判全期最该被单独保存的是他拒绝的那个口径¶
- 对话的走向(swyx 一侧):"作为一个公司领导者,我不介意你在 token 上花我的钱。只要给我看它花得好。" → Parikh 接"所以问题是我们怎么帮你和很多其他人把这个闭环闭上:嘿,我这周在 token 上花了 1,000 块" → swyx 续"然后如果你能说,嘿,我产生了 25,000 美元收入,那你可能会觉得:嘿,那挺不错。"
- ⚠️⚠️ 而 Parikh 拒绝了这个口径:
"我觉得收入有点太……作为一个写代码的人,我不负责收入。但至少我交付了功能(I ship features)。我觉得能够谈的是这怎么转化成某种 ROI,也许不是收入。" 替代口径是:"成本节省——或者说,嘿,这提高了参与度、或者留存,或者它改善了 CSAT。这些都是可度量的,而作为一个产品团队和工程团队,你应该挂在这些结果指标上。"(⚠️ CSAT 在转录稿里写成 "seesat")
- ✅ 本页标注这为什么是厂商色彩最轻的一处:⚠️⚠️ "token 支出 → 收入"是对卖 token 与卖 AI 工具的一方最有利的叙事,因为它把支出直接接到最大的那个数上;而他主动把它降级到了功能交付、成本节省与产品指标,并且给的理由是职责归属("作为一个写代码的人,我不负责收入")而不是谨慎。
- 🔗 ⚠️⚠️ 本页标注这与本库既有的 ROI 材料是同一问题的不同侧,而这一条补的是归因层级:Chamath 的"一旦跨到数百万美元级,你必须展示某种形式的 ROI 或总持有成本优势"讲的是买方在什么门槛上开始要 ROI;Salesforce 企业发展负责人的"ARR 是个很好的指标,但它掩盖流失"讲的是卖方指标会掩盖什么;✅ 而这一条讲的是:在工程组织内部,那个 ROI 分子该用什么单位——而他的答案明确不是收入。
- ⚠️ 本页另记一处与同晚另一份材料的对照:同日 All-In 那期 Jason 的 launch.com 自述恰好做了相反的事——他把 4–5 万美元的订阅支出直接接到"200 万美元价值"与"15 到 21 倍增量收入"上,而他在同一段里给了三个互不相同的数字。 ✅ 本页标注这两条并列很有用:一个把分子放在收入上并给不出一致的数,一个明确拒绝把分子放在收入上。
六、⚠️ 安全面(自述),以及 2027 的三条预测¶
① 安全([00:14:10]–[00:17:15])⚠️⚠️ 全部为自述能力声明,无第三方核实、无口径。¶
- 代码评审侧:"现在我们有 code review max,它应该能帮你在代码里找到更高严重度、更隐蔽的 bug。" ✅ 他给的理由本页认为值得记,因为它把评审与生成量绑在一起:"所以非常重要的是,我们在生成多得多的代码,我们要确保质量门槛不下滑。"
- 扫描侧:GitHub Advanced Security 现在带 AI 扫描;keynote demo 里"有人误推了一个 secret,而它在进入仓库之前就被拦住了";"深度扫描能找的不只是表层的漏洞"。
- 供应链侧(本页认为这是本节最具体的一条):Microsoft 安全团队与 GitHub 安全团队协作,既加固平台也与开源维护者合作,具体动作是"限制像 npm 这样的包管理器的暴露面,包括设置时间延迟、以及下架被攻破的仓库"。
- 🔗 ⚠️ swyx 把这一节接到了"最近 PHP 那件事"上,🔗 本库既有的那份材料见 All-In × Nikesh Arora(PHP 漏洞周、agency 与责任归属)。
② 2027 的预测([00:19:18]–[00:21:19])¶
- ⚠️ ① 基础设施:继续"在栈的每一层做阶跃式改进";而 Azure 迁移"计划是明年。那是我们瞄的目标"(⚠️ 本页记下这是一个有明确日期的可核对承诺)。
- ⚠️⚠️ ② 工作方式,而本页认为他这里给的是一个坦率的不知道:
"人们正在改变工作方式……我猜一年之后它会看起来相当不一样。而它会是什么样?我们是在管理成千上万个 agent,还是几十个、几百个?我不知道。" ✅ 而他的应对被说成一个设计原则:"所以我们必须继续用正确的原语来建这个平台,让你能把那些原语组装成你想要的工作方式。"
- ✅ 本页标注这条值得记的理由:⚠️⚠️ "并发 agent 数量的量级还不知道"是一个来自平台侧的、对自己不利的承认——因为平台的容量规划恰恰依赖这个量级。 🔗 而本库既有的并发 agent 一手材料(Steinberger 并行 4–10 个)与"成千上万"之间差三个数量级,本页记下这个缺口。
- ⚠️ ③ 安全 + token 支出治理(见第五节)。