AI Builders · 编程智能体与 Agentic Engineering(播客精炼)

这篇 wiki 把 11 档英文播客(AI & I / Latent Space / No Priors / Training Data / Unsupervised Learning)里关于"编程智能体"的讨论拧成一股,按概念而非按集数组织。这一波人(Karpathy、Claude Code 之父 Boris Cherny、OpenAI Codex 团队、Cursor、Notion、Pydantic)在 2026 春天高度共识的一件事:写代码这个动作正在消失,人的工作变成"对一群 agent 表达意图 + 验收"。他们也在几个关键路口公开掐架——这篇专门把分歧也摆出来。

何时打开:

你听人说"我已经不自己写代码了"但不知道这到底是吹牛还是真的发生了

你纠结 Claude Code 还是 Codex(OpenAI 的编程 agent),想看真正天天用的人怎么选

你是产品/运营,想知道"编程 agent" 凭什么能干非编程的活(写邮件、做调研、管指标)

你想搞懂为什么大家都在说 "skill"、"harness(外壳)"、"MCP vs CLI" 这些黑话

你想给团队/老板解释:为什么"会写代码"突然没那么值钱、什么才值钱

0. 一句话地图:这一波到底在讲什么

把"AI 写代码"想成一条电梯,这 11 档播客的人都站在不同楼层往上看,但都指向同一个顶楼:

楼层 0  人自己敲代码,AI 只做补全(2024,老黄那篇 newtype 讲过)
楼层 1  Vibe Coding:用嘴让 AI 写,人还盯着改       ← Karpathy 造的词
楼层 2  Agentic Engineering:派一群 agent 干活,人只表达意图 + 验收  ← 2025/12 拐点
楼层 3  零人工审查 / agent 自己开工单、自己改自己      ← "dark factory 暗工厂",最前沿
楼层 4  自动研究:给目标+预算,agent 自己跑实验自己迭代  ← Karpathy 的 AutoResearch

Why 这张图重要:很多人(包括你老板)还停在"AI = 聊天机器人"的认知,而台上这帮人已经在楼层 2-3 生活了。下面每一节都是这张图某一格的展开。

1. 那个拐点:2025 年 12 月,"从打字到调度"

几乎所有受访者不约而同把同一个时间点标成转折——2025 年 12 月。

Karpathy(OpenAI 联创、ex-Tesla,No Priors / Training Data 两档都讲了):

"I don't think I've typed a line of code probably since December." 译:我大概从十二月起就没自己敲过一行代码了。

"Code's not even the right verb anymore. I have to express my will to my agents for 16 hours a day. Manifest." 译:"写代码"已经不是合适的动词了。我现在一天 16 小时都在向我的 agent 们表达意志。用"显化(manifest)"更准。

他把自己的状态从 80/20(自己打 80% 代码)翻转成 20/80(80% 交给 agent),并说"一个普通软件工程师的默认工作流从十二月起已经彻底不一样了"。

Boris Cherny(Claude Code 的作者,Training Data)给出更极端的数字:

"For me, it's just solved. The model writes 100% of my code. There was a day last week I did 150 PRs in a day." 译:对我来说这事已经解决了。模型写我 100% 的代码。上周有一天我提交了 150 个 PR(代码合并请求)。

Why 拐点是真的、不是营销:两个独立的人(一个在 OpenAI 生态、一个在 Anthropic)用几乎一样的话、一样的月份描述同一件事。Karpathy 还补了句关键的——去年把 AI 当"ChatGPT 那种聊天玩意儿"的人,必须从十二月起重新评估,因为"agentic 的连贯工作流"这次是真的能用了。

对非技术读者的翻译:这就像打字员时代过渡到"口述给秘书团"——你不再纠结打字快慢,你纠结的是"我到底想要什么、怎么说清楚、怎么验收"。瓶颈从手指挪到了脑子。

2. 核心心法:Vibe Coding ≠ Agentic Engineering(别混)

这是 Karpathy 反复强调、最容易被外行搞混的一组词。

	Vibe Coding(凭感觉编程)	Agentic Engineering(智能体工程)
干什么	用嘴让 AI 生成能跑的东西	派一队 agent 做专业级软件
解决谁的问题	抬高地板:人人能做软件	守住天花板:专业质量不塌
还管不管质量	不太管,能跑就行	还得管(不能引入漏洞、对软件负责)
速度上限	一般	极高,"远超老的 10x 工程师"

Karpathy(Training Data):

"Vibe coding is about raising the floor for everyone. Agentic engineering is about preserving the quality bar of what existed before in professional software." 译:Vibe coding 是给所有人抬高地板;agentic engineering 是在飙速度的同时守住专业软件原有的质量门槛。

"10x 工程师"已经不够形容了——"10x is not the speed up you gain. People who are very good at this peak a lot more than 10x."(真正擅长的人峰值远超 10 倍。)

Why 这对产品经理很关键:你团队里那个"能用 Cursor 拼个 demo"的人,和那个"能调度一队 agent 交付不出 bug 的生产系统"的人,完全是两个段位。前者是 vibe coding(地板),后者是 agentic engineering(天花板)。招人、定级、分活都得按这条线重切。

3. 软件 1.0 / 2.0 / 3.0:理解这一切的底层框架

Karpathy 的经典三段论(贯穿两档节目,Cursor 那期的 Dima 也借用了):

代际	你在"编程"什么	大白话
Software 1.0	写明确的代码	程序员手敲 if-else
Software 2.0	整理数据集 + 训练神经网络	"用数据编程"(深度学习时代)
Software 3.0	写提示词 / 上下文	把大模型当"解释器",上下文窗口是你的操纵杆

Cursor 的 Dima 又加了一层(从训练视角):1.0 雕代码 → 2.0 雕训练数据 → 3.0 雕评估标准(eval rubrics)。

关键的认知翻转(Karpathy):别把 AI 当成"老范式的提速器"。一整类 App 现在"不应该存在了"——因为神经网络直接把活干了。

"MenuGen example: he built a full app (OCR + image-gen + Vercel) to turn restaurant menus into pictured menus; the Software 3.0 version is just handing the photo to Gemini and saying 'use Nanobanana to overlay the dishes onto the menu'." 译:他原本造了个完整 App(文字识别 + 图像生成 + 部署)把菜单变成带图菜单;Software 3.0 版本就是把照片丢给 Gemini 说"用 Nanobanana 把菜品贴到菜单上"——整个 App 都成了多余。

Why 对产品决策致命:你正在做的某个功能,可能下一代模型一句话就替代了。"凡是你能验证对错的事,LLM 都能自动化"(见 §7)——所以做产品前先问:这事是不是模型一句话就能干?如果是,别造 App,造提示词。

4. 新工作方式:一个人指挥一支 agent 舰队

拐点之后,"工作"长什么样?受访者描述高度一致——多 agent 并行,人在中间当调度官。

Karpathy 的 "Peter Steinberg 原型":一个屏幕铺满几十个 Codex agent,每个高强度跑 ~20 分钟,本地 checkout 了 ~10 个仓库,人在仓库间来回派活。
Cherny 的手机流:现在主要用手机上 Claude App 的 code 标签页——同时开 5-10 个会话、几百个 agent 在跑、隔夜几千个跑更深的活。
Karpathy 对工作的重新定义:工作变成对仓库下"宏动作(macro actions)"——把互不干扰的功能丢给 agent 1、agent 2……一个做调研、一个写码、一个做规划,你练的是调度的肌肉记忆。

新的稀缺资源不是算力,是"令牌吞吐量(token throughput)"和人的注意力。

Karpathy:留着没用完的订阅额度会让他焦虑(Codex 用光就切 Claude),像"博士生看着 GPU 闲着难受"。

Ryan Lopopolo(OpenAI Frontier,Latent Space)把这点推到极致:

"The only fundamentally scarce thing is the synchronous human attention of my team." 译:唯一真正稀缺的,是我团队成员同步的人类注意力。

Why:令牌和 GPU 可以无限并行、便宜;人的注意力一天就那么几小时。所以整套工程的目标变成了"把人从环里拿掉"。

对你的启发:别再用"工时"衡量产出。新的产能单位是"你能同时盯住几个 agent 而不翻车"。这本身是要练的技能(Karpathy 反复说的"肌肉记忆")。

5. "Skill"、"Harness"、"Loop":黑话三件套(给非技术读者)

这三个词在每档节目里反复出现,搞懂它们这一波就听得懂一半了。

5.1 Skill(技能)= 一个 markdown 文件 + 几个脚本

Swyx(Latent Space 创始人,现在 Cognition,Unsupervised Learning 那期)给了最干净的定义:

"Skills = a markdown file + attached scripts. I don't see how it can be more simple than that." 译:技能 = 一个 markdown 文件 + 附带的脚本。我想不出还能更简单。

他把 agent 拆成最小公式:agent = "带工具的大模型在循环里跑" + 文件系统 + 检索 + 技能。这一层现在"基本达成共识"了。

大白话:skill 就是你把脑子里某个 SOP(标准流程)写成一篇说明书塞给 agent,它照着干。不需要写程序——会写 Word 文档就会写 skill。

5.2 Harness(外壳)= 包在模型外面那层"装配台"

模型是发动机,harness 是车架。"Harness engineering 有巨大的 alpha(超额收益)"——Anthropic 平台团队的 Angela(AI & I)说,他们给 agent 做记忆功能时试了好几种 harness,评测结果差异巨大:

"You can hill-climb a tremendous amount by just harness-engineering the right pieces together." 译:光靠把外壳的零件拼对,你就能爬升一大截性能。

5.3 Loop / Routines(循环)= 让 agent 自己定时反复干

Cherny 最爱的原语就是 /loop——让 Claude 用定时任务(Cron)反复跑:看护 PR(修 CI、自动 rebase)、保持测试健康、每 30 分钟聚类一次 Twitter 反馈。

"Loops are the future at this point. If you haven't experimented with it, highly recommend it." 译:循环就是未来。还没玩过的话,强烈建议试试。

新出的 "Routines" 是服务端版的 loop——关了笔记本它还在云上跑。

Why 这三件套是核心:它们让 agent 从"问一句答一句"变成"自己持续干活的同事"。这正是从楼层 1 爬到楼层 2-3 的台阶。

6. ⚔️ 分歧一:Claude Code vs Codex(到底用哪个)

这是整批播客最有看头的实战分歧。同一批顶级用户,选择不同、理由公开。

Dan Shipper & Austin(Every 公司,AI & I《我们为什么从 Claude Code 换到 Codex》)的故事:

半年前 Codex"是垃圾"——Dan 原话:"Codex... three months ago, six months ago, it was trash." Austin:"Nothing has ever made me feel more stupid than Codex two months ago."(没有任何东西比两个月前的 Codex 更让我觉得自己蠢。)它"会跟你吵架、没情商、有点自闭"。
然后 OpenAI 在 ~3 个月里硬掉头,把 Codex 从"只给资深工程师的沙箱玩具"改成"日常主力"。Austin 现在 80% 的工作时间泡在 Codex App 里,理由不是模型更强(他认为最新 Opus 和最新 GPT 在他的知识工作上"至少打平"),而是 Codex 的桌面 App 比 Claude 桌面 App 快得多、强得多,子 agent 也强——他估"好 30-40%"。
但他特意补一句:别人不一定非得换,Claude 桌面 App 本身已经改变游戏规则了。换的成本也极低:你可以直接叫 Codex"去把我所有 Claude 的东西搬过来"。

Karpathy 的"人格对比"(No Priors):Claude"像个队友",拍马屁拿捏得准(夸你时你觉得配得上,烂主意不会被强捧);而编程版 Codex"很干、似乎不在乎你在创造什么"。

Samuel Colvin(Pydantic,Latent Space)的神比喻——他同时用三家:

"Claude Code is like Captain America. Codex is this neurotic, geeky, like the Q guy in Bond. And Gemini is like the Joker — this unhinged lunatic that will occasionally do an incredible job, but half the time just delete all of your files." 译:Claude Code 像美国队长(稳、正);Codex 像 007 里那个搞技术的神经质极客 Q;Gemini 像小丑——疯批,偶尔神来之笔,但一半时间直接把你文件全删了。

怎么用这组分歧:

没有标准答案,而且半年就翻盘一次——别把"某某更好"刻进脑子,这是高波动期(Swyx 语)。
选择更多取决于桌面 App 的工程体验(速度、子 agent),而非模型原始智力——后者已趋于打平。
Swyx 的商业视角:Anthropic 是高价精品(限额度、限模型发布、产品+模型捆绑);OpenAI Codex 是"快进来"(补贴、开放 SDK、重置额度)。建议:趁补贴还在薅羊毛,$200/月的套餐就足够当"能力探索者"。

Dan Shipper 的元建议:"Someone using a new tool with a new paradigm and a new workflow is just going to beat you by default."(用新工具+新范式+新工作流的人,默认就会赢你。)所以定期换工具试新范式,本身是竞争力。Every 公司每年搞两次 "Think Week"(整周不干日常活,只玩新工具),他建议团队至少每季度一天。

7. 决定一切的尺子:可验证性(Verifiability)+ 锯齿状智能

这是判断"AI 能不能帮你干某件事"的通用判据,Karpathy 讲得最透。

核心命题:经典计算机自动化"你能用代码写清楚的事";LLM 自动化"你能验证对错的事"(automate what you can verify)。前沿的强化学习(RL)只奖励"可验证"的领域,于是练出来的智能是"锯齿状(jagged)"——在数学/代码上是顶尖博士,在别处可能像十岁小孩。

Karpathy 的名句(Training Data):

"How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor a 100,000 line codebase or find zero-day vulnerabilities, and yet tells me to walk to this car wash? This is insane." 译:最先进的 Opus 4.7 既能重构十万行代码、又能挖出零日漏洞,却建议我走路去那个洗车店——这太离谱了。

锯齿来自两股力:(1) 什么是可验证的;(2) 实验室选了把什么塞进训练数据。GPT-3.5 到 GPT-4 的国际象棋大跃进,不是通用能力涨了,是有人往预训练里加了大量棋谱。"你受制于实验室在干嘛。"

对产品/创业的可操作结论:

做事前先判断你的应用"在不在 RL 回路里"——在(数学/代码/可自动判分的事),你起飞;不在(模糊、说不清对错的事),你挣扎。
可验证的领域哪怕实验室不重点搞,你也能自己拉微调杠杆搞定(Karpathy 给创业者的建议)。
终极乐观:Karpathy 认为"一切皆可自动化"——连写作这种模糊领域,也能用"一组 LLM 评审团(council of LLM judges)"造出可验证性。这是"难 vs 易"的问题,不是"可能 vs 不可能"。

配套金句(他常引用的一条推):

"You can outsource your thinking, but you can't outsource your understanding." 译:你可以外包你的思考,但你没法外包你的理解。

人退化成"瓶颈/导演",但理解是没法委托出去的东西。这条对非技术个体尤其重要:工具帮你思考,但你必须真的懂,否则验收不了、也指挥不动。

8. ⚔️ 分歧二:MCP vs CLI(给 agent 接外部工具,走哪条路)

"怎么让 agent 用上外部工具/数据"有两条技术路线,业内分两派。先把两个词翻成人话:

MCP(模型上下文协议):一套标准插头,把工具"声明"给 agent,"你只能调这些工具",权限干净。
CLI(命令行工具):让 agent 像人一样在终端里敲命令。

反 MCP 派(Ryan Lopopolo / OpenAI Frontier;Notion 的 Simon 偏向 CLI):

Lopopolo 直言看空 MCP:它强行把所有工具的说明塞进上下文,搞乱自动压缩,agent 还会"忘了有哪些工具"。他偏好薄薄的 CLI 壳(比如只包他们真正用的 3 个 Playwright 调用),并把 CLI 包成省 token 的样子(只输出失败的测试、从日志里抠出异常)。
Notion 的 Simon Last 看多 CLI,因为它住在终端里,天然有分页、渐进披露,而且能自举(self-bootstrapping):"我的 agent 没有浏览器,我就让它自己做一个——100 行包一下 Chromium API。"

挺 MCP 派(Notion 的 Sarah Sachs 部分认同;Cherny 力挺):

Simon 也承认 MCP 的权限模型强:"MCP is just the dumb simple thing that works, and it is pretty good."(MCP 就是那个又笨又简单但管用的东西,而且相当好。)适合窄、轻、强权限的 agent。
Cherny(Claude Code 之父)对知识工作直接说最简单的答案就是 MCP——同一套连接器(Salesforce、Google 文档/日历)能跨 Cowork、Claude CLI、Claude Code 复用;没有 MCP 的系统就用"计算机操作(computer use)"兜底。

两派其实都同意的那句话(Cherny):

"To the model is just tokens." 译:对模型来说,这些(MCP / CLI / API / 计算机操作)全都只是令牌。

接入机制本身不重要,重要的是省不省 token、权限干不干净、agent 能不能自己 debug。

Sarah Sachs 的成本视角(给产品/财务的关键):

"Needing language to execute deterministic tasks feels wasteful." 译:用(烧 token 的)自然语言去执行确定性任务,感觉很浪费。

按量计费下,让 agent 写一段代码去调 CLor(确定性、一次性成本),比反复付 token 费让 LLM 去敲 MCP 划算——尤其超出缓存窗口时。所以 Notion 对搜索这种核心能力故意不用 MCP,自己写。

怎么决策:窄而稳、要强权限 → MCP;复杂、要 agent 自己探索/自愈、量大要省钱 → CLI。

9. ⚔️ 分歧三:harness 是不是难点?真正的墙在哪

一个"业内自己打架"的话题——大家以为难的地方,可能不是真正的墙。

Anthropic 平台团队(Caitlin,AI & I)"辣评":

"I think people think the harness engineering part is the hard part... but everyone hits an infrastructure wall." 译:大家以为外壳工程是难点……但每个人最后都撞上的是"基础设施"那堵墙。

她的意思:提示词缓存、把上下文窗口塞满这些"外壳"活,Agent SDK 已经帮你搞定了;真正的墙是"产品化"——让服务器一直在线、按需启停、存对话记录、安全沙箱、容错(沙箱一死,整个 agent 就死)。这正是 Anthropic 做 "Managed Agents(托管智能体)" 的初衷。

但 Angela(同台)又坚持 harness 有巨大 alpha(§5.2)——所以这不是矛盾,是分层:外壳能让你爬升性能(有 alpha),但你要规模化跑生产,撞的是基础设施墙。

还有一个关于"模型锁定"的重磅观点(Angela):老一代模型时代,流行做一个"很通用的 harness"+热插拔模型;下一代,每家实验室技术路线分叉,harness 和模型变成"紧耦合的一对"。所以你要做冗余/切换,应该在"agent 层(harness + 模型一起)"切,而不是在底下做一个通用 harness 然后热插拔模型。

Why 对采购/架构决策重要:别再幻想"做个万能中间层,模型随便换"。这一波,模型和它的外壳是一套的,换模型基本等于换整套 agent。

10. 极端案例:把"零人工"推到尽头(暗工厂)

Ryan Lopopolo 的团队(OpenAI Frontier,Latent Space)做了一个激进实验,值得当"未来预演"看:硬规定团队一行代码都不许手写,逼自己把 agent(Codex)训成能干工程师全部的活。

结果(~5 个月):~100 万行代码、~1500 个 PR、3 个人、比手写快 ~10 倍——但头 1.5 个月反而慢 10 倍(在给 agent 搭"装配台")。

几个反直觉的运营心法:

人类审查从"合并前"挪到"合并后":不再当守门员,而是合并后抽样看团队在哪卡壳。代码审查 agent 可以自主合并。
"模型本质上渴望文本(crave text)":整套打法就是把文本从一个 agent 灌给另一个 agent——文档、能教 agent 怎么修的报错信息、技术追踪表、质量分、PR 评论,全是在补 agent 缺的上下文。
每个错误 = 一条还没写下来的隐性需求。把工程师脑子里"什么叫好"挖出来,编码成文档/测试/审查规则。
代码是一次性的:他们的系统有个"返工"状态——PR 不能干净合并,就把整个工作区+PR 扔了从头来,然后问"为什么是垃圾",把答案编码进去。
信任 = 可压缩的可读性,不是监控:他不想要你 Cursor 会话的录屏,他期待 agent(像队友)给 PR 附个视频证明代码是好的、可合并的。

Swyx 把这种现象命名为 "dark factories(暗工厂)",并标出两级"编程精神病":(1) 零人工代码(5 个月前觉得疯,现在正常)→ (2) 下一个前沿是零人工审查——不看就合并。"这是唯一可规模化的路径,需要把软件开发流程整个翻向更多测试/自动验证。数量 → 质量。"

重要免责(Lopopolo 自己反复强调):这一切发生在全新的 greenfield(空地)仓库,不保证能搬到老旧的存量系统(brownfield)。别拿这个去忽悠你公司的祖传屎山。

11. 自己训模型还是用前沿模型?Cursor 的 "agent lab 打法"

Notion 拒绝自己训(§13),但 Cursor 走了相反的路并讲清了"什么时候该自己训"。

Swyx 总结的 "agent lab 打法"(Unsupervised Learning):先用最强的前沿模型起步 → 为你的领域做专门化 → 等积累够多高质量用户工作量,再训自己的小模型省成本/降延迟。他叫这"反转的苦涩教训(reversal of the bitter lesson)"——先靠大通用模型起飞,再蒸馏成小模型跑高频低波动的活。

Cursor 的 Composer 2 实证(Training Data):

把模型权重当成一块有限的"硬盘",把每一个 bit 都分配给唯一一件事——"在 Cursor 里做软件工程",而非泛泛的编程。
专门化 = 它比 Opus 便宜约一个数量级的根因(小而专的模型可以低价服务)。
从开源底座 Kimi 2.5(1 万亿参数 MoE、激活 300 亿)起步,做中段训练 + 强化学习,而非从零预训练——自上而下,为了最快出一个有用的模型。
长任务靠把"压缩/自我总结"放进 RL 训练回路:模型是 20 万上下文窗口,但靠"边总结边重启上下文"能实际跑上百万 token。

Federico(Cursor)的一句很重要的破除迷信——大家以为提示词能解决一切:"Prompt engineering has an upper bound."(提示词工程有天花板。)要做出顶级 AI 产品,必须靠后训练去影响模型行为。Composer 上线时带提示词,但他相信不带也能跑,因为训练已经把它推对了方向。

Why 对绝大多数公司的结论:你大概率不该自己训模型(§13 Notion 给了最强论证)。Cursor 能训,是因为它有"自己的产品当作天然的 RL 环境"("The most powerful environment is your own product." 最强的训练环境就是你自己的产品)+ 几万张 GPU。没这两样,老老实实用前沿模型 + 专心打磨 harness/工具/验证。

12. Monty:给 agent 用的"轻量代码执行" + "100 倍提速判据"

Samuel Colvin(Pydantic 作者)的 Monty 项目,讲清了一个产品经理也该懂的取舍。

它解决什么:agent 经常需要"写段代码算一下"。两种老办法各有毛病——纯工具调用(安全简单但表达力弱)、完整沙箱(强大但要外部基础设施,大金融机构不让用)。Monty 卡在中间:给你"代码模式"的表达力,但不用沙箱(单数微秒级延迟,而起一个沙箱要 ~1 秒)。

对所有人都通用的金句——"LLM 提速 100 倍(而非 3-5 倍)的四个条件"(Colvin 的便携判据):

内部实现模型很熟(如堆、字节码解释器);
外部 API 模型很熟(如 Python 语义"刻在它权重/灵魂里");
单元测试极其好做(对照 CPython 是否一致,能"自己 Ralph 到通过");
API 不需要扯皮(Python 把所有报错/行为都定义死了)。

"If you cover all four of those things, that's why everyone is basically cloning Redis in Rust right now." 译:四条都满足,这就是为什么现在人人都在用 Rust 克隆 Redis。

Why 对你有用:这是判断"哪类工程任务交给 AI 会爆杀(而不是只快一点点)"的速查表——有现成标准答案、测试好写、不用吵规范的活,AI 一夜干完几周的量。反过来,没有客观标准的活,别指望它 100 倍(呼应 §7 的可验证性)。

还有一条类型安全的洞察:Colvin 最强信念——"type safety is important for humans but critical for AIs."(类型安全对人重要,对 AI 是生死攸关。)四个 Anthropic 的人各自独立告诉他:一旦你链式调用工具 / 用代码做工具调用,类型安全就特别要紧——这信号让他判断出 Anthropic 在做"编程式工具调用"(后来果然发了)。

13. 反共识:Notion 的"别什么都上 agent / 别自己训模型"

在一片"agent eats everything"的热潮里,Notion 的 Sarah Sachs & Simon Last(Latent Space)是清醒的反向参照,对产品经理尤其解毒。

"Auto(自动选模型)"才是难而重要的活:要说服用户相信 auto 不是最便宜最蠢的模型,而是最适配任务的那个。Robinhood 类比:auto = 智能投顾 / 指数基金。Notion 不把 auto 当利润机器,只是降焦虑——大多数任务用不上 Opus 级。

她点出一个跟前沿实验室的根本差异:

"It's not replacing people. It's replacing processes." 译:它不是替代人,是替代流程。

以及:Notion"并不是被激励让你烧尽可能多的 token"——很多时候正确的工具就是直接写段代码,根本不需要 agent。(对照前沿实验室靠 token 赚钱的动机,这话分量很重。)

坚决不自己训基座模型(Sachs):"不是我们的核心能力""没钱训基座";而且在自己工具上微调会失败,因为"我们每天都在改工具"——重训节奏根本追不上。Simon:训练是"实现细节",99% 的问题是某个工具里的 bug,修 bug 就行,精力放外层(harness、工具、验证)。唯一值得投训练的是检索/排序——因为现在大部分搜索流量来自 agent 而非人,agent 写查询的方式不同。

Notion 重建 AI agent ~5 次的血泪教训(对做 AI 产品的人是金矿):

核心原则:"Give the models what they want."(把模型想要的喂给它。)别把你自家系统的复杂度暴露给模型。
实例:放弃自家"变态的 JSON"数据库查询格式,换成 SQLite——因为模型对 SQL 很在行;放弃无损 XML 格式,换"Notion 风味 markdown"——因为模型懂 markdown。
从"少样本提示"彻底转向"目标驱动的工具定义",这一步是最大的速度杠杆:之前只有 5-6 个人能碰那条共享提示词(一个"卓越中心"瓶颈),改成工具定义后,工具所有权能分散给各个团队。
100+ 工具带来"渐进披露危机":光打个招呼就烧几千 token,任何人加个冷门工具都可能"把整体模型搞废"。解法:重做 harness,别一次把所有工具甩给 agent,让它自己搜索/筛选工具。

Simon 的一句重锤:"Everything is a coding agent. The coding agents are the kernel of AGI."(一切都是编程 agent;编程 agent 是通往 AGI 的内核。)——这跟开头 Dan Shipper 的"会写软件就会干任何知识工作"同一立场。

14. 比"会写代码"更值钱的东西:领域知识、判断、品味

这是全批播客对非技术个体最大的好消息,几乎人人都讲到。

Cherny(Claude Code 之父)的"印刷机时刻":印刷术前欧洲 ~10% 识字率,之后 50 年出版量超过此前一千年、书价跌 ~100 倍、识字率最终到 ~70%。软件正在被同样地民主化,而且比 50 年快得多。推论:

"The best person to write accounting software is not an engineer, it's a really good accountant. Because coding is the easy part. It's knowing the domain that's the hard part." 译:写财务软件最合适的人不是工程师,是一个真正厉害的会计——因为写代码是简单的部分,懂业务才是难的部分。

Karpathy:人继续掌管品味、判断、审美、规格/设计、监督;agent 像"记性超好的实习生,负责填空",但你得拥有每个决策(比如"这些用户 ID 必须唯一")。

Sarah Sachs 点破工程师自身的身份危机:

"Every software engineer is going through the identity crisis that every manager goes through — their ability to write code is less important than their ability to delegate and context switch." 译:每个软件工程师都在经历每个管理者经历过的身份危机:突然发现自己"会写代码"不如"会委派、会切换上下文"重要。

对你(非技术 PM)的直接含义:

你的业务/领域深度第一次可以直接变成产品,不再卡在"找不到工程师"。
但别误读成"零基础也能开发"——你仍需编程思维 + 判断力 + 验收能力(呼应 newtype 老黄的同款警告,见 newtype · AI Coding 实战与工具栈演化 §10)。
AI 写的东西署你的名,你就得对每一条负责。 Dan Shipper 说他常宁愿读你 agent 写的东西也不读你自己写的——前提是"你站得住、你想清楚了";信任来自人真的拥有每一行。

15. 把 Claude Code 当"第二大脑"(非编程用法)

Noah Brier(Alephic 创始人,AI & I)给出一个对知识工作者极有参考价值的范式:他用 Claude Code 的头号用途根本不是写代码,而是当"思考/调研/笔记的第二大脑"——架在他的 Obsidian 笔记库(纯 markdown + 文件夹 + Git 同步)上。

"Probably my number one Claude Code use is using it as a tool to interact with my notes." 译:我对 Claude Code 的头号用途,大概就是拿它跟我的笔记互动。

几个可直接抄的做法:

在整个笔记库的根目录启动 Claude Code(不是某个项目子文件夹),让它能跨 ~1500 篇笔记搜索;用 PARA 笔记法分类。
最爱的"重入"咒语:"Can you catch me up on the last few days of research?"(帮我接上前几天的调研进度。)—— 深度工作最难的是重新进入心流,这句直接点火。配 claude --continue 续上会话。
造一个"思考伙伴"子 agent:专门提示它只负责促进思考、问尖锐问题、不准动手写,并维护一份"已挖到了什么"的运行日志。
一个反复出现的模型坏毛病:哪怕你明说"别写、别产出",模型还是忍不住要产出成品。Brier 用一条强硬的开头指令对抗("不要创建提纲、草稿或任何版本……照字面执行")。他猜这是"乐于助人 + 产物经济学"的偏见被"自我摄入"进了模型。

Brier 的一个深刻 reframe:因为我们叫它"生成式(generative)",大家过度盯它的写能力,严重低估了它的"读"能力——而读才是日常更有用的:"我们产出成品的频率,远低于我们只是在思考事情的频率。"

Why 对你(做 kb 知识库的人)直接相关:这套"Claude Code 架在 markdown 笔记库上当第二大脑"的范式,和你自己的 kb 仓库工作流几乎同构——可作为优化自己 kb 用法的参照(见 Claude Code 工作流(跨作者主题综合))。

16. SaaS 会死吗?护城河重排 + Jevons 悖论

几位都谈到对软件商业的冲击,值得 PM 收着。

Cherny 用 Hamilton Helmer《7 种力量》框架:AI 削弱两种护城河——切换成本(工具间一键搬家)和流程力(Claude 4.7"给个目标就能爬升任何东西");但网络效应、规模经济、独占资源不变。推论:未来十年颠覆性创业公司数量 ~10 倍增长,因为一个小团队现在能造出和大公司一样值钱的东西、正面硬刚。

Swyx 的"编程战争"现状(数字仅为业内估算,口径有争议):Anthropic 单 Claude Code ~25 亿美元 ARR、OpenAI Codex ~20 亿、Cursor 传 ~20 亿。大概率终局 = 两大玩家 + 一长串细分长尾。当前是"能力探索期"而非"效率期"——现在的激励是让你烧更多 token,不是更少;"我们大概还在整体性地少用 AI"。

Karpathy 的 Jevons 悖论(软件版):软件曾经稀缺昂贵,降低门槛会释放更多需求(经典例子:ATM 普及反而让银行网点和柜员更多)。因为代码现在是"易逝、可随时改的(ephemeral)"而非一次性买断的订阅,他谨慎乐观:软件总需求会涨。

对产品决策的提炼:

如果你的产品护城河靠"切换成本"或"流程复杂度"——危险,正在被削。
靠"网络效应/规模/独占资源"——相对安全。
"AI vs SaaS" 的真实难点不是"能不能重建"(Swyx 公司花 20 万/年的 SaaS,他估 2 千就能重建),而是"怎么把不那么 AI-native 的团队一起带上来"——公司内部"AI 精神病程度"的落差正在造成真实裂痕。

17. ⚔️ 分歧四:Agent 是不是基础设施的新买家?(产品/增长视角)

对做产品、做营销、做开发者关系的人,这是最该立刻行动的一条。

强共识(Swyx + Vercel CTO Malte Ubel):agent 已经成了基础设施的"买家"。

"If it doesn't exist as an API that agents can use, it doesn't exist." 译:如果它不以一个 agent 能调用的 API 形式存在,那它就等于不存在。

数据:Vercel 的应用管理/配置流量里 ~60% 是机器人,不是人(Notion 的 Sarah Sachs 也说"长期看我们大部分流量会来自 agent 用我们的界面,而非人")。规则:多建 CLI,别只建 UI。

但 Swyx 又把这件事"祛魅"——他认同 Netlify 的 "Agent Experience(智能体体验)" 概念,但强调:

"Everything that you should do for agents is something that you should have done for humans anyway." 译:你为 agent 该做的一切,本来就是你早该为人类做的(好文档、一致且基本无状态的 API、可发现性/渐进披露)。除了"更多 spam、更大量"之外,没什么本质新东西。

关于 AEO/GEO(优化让聊天机器人推荐你):短期有复利红利(Resend 案例:2023 年才创立,现在 Claude 被问邮件服务商时 ~70% 默认推它);但 Swyx 判断 3-4 年后,记忆 + 个性化会比"被提及频率"更决定模型/工具的选择。默认名单会收窄到 ~3 个,不是 20 个。

对你的行动清单:

把你的产品/文档改成 agent 能 copy-paste 直接用(Karpathy 的反复吐槽:别再写"教人类怎么做"的文档,给"丢给 agent 的那段文本")。
有 UI 就配 CLI/API。
AEO/GEO 现在做有红利,但别 all-in 押"刷存在感",中长期押"被记住/被个性化选中"。

18. 更远的天花板:AutoResearch、记忆瓶颈、世界模型

几条偏未来、但能帮你判断"接下来什么会来"。

Karpathy 的 AutoResearch(自动研究):把"人退出回路"推到科研。给 agent 一个目标 + 一个可量化指标 + 边界,它整夜自己跑实验。他在自己手调了二十年的 NanoChat 上跑了一夜,它找出了他漏掉的调参(一个被遗忘的权重衰减、没调好的 Adam beta)。他设想一个"研究组织 = 一组定义角色与连接的 markdown 文件"(他叫 ProgramMD),甚至能元优化 ProgramMD 本身。两个前提:(1) 只适用于有便宜、客观指标的事(能验证才能自动研究);(2) 整个栈还在"撑破缝",推太前反而没用。

Swyx:记忆是最大的限制约束:

"Context length is the slowest-scaling factor in LLMs. Memory is probably going to be the biggest limiting constraint." 译:上下文长度是 LLM 里增长最慢的因子;记忆很可能是最大的限制约束。

(上下文从 4k 涨到 1M 花了 ~3 年;Gemini 的 1M 存在两年却很少被用满。)

Swyx 在看的两个下一前沿:(1) 记忆/个性化;(2) 世界模型(world models)——他认为这对"智能本身"重要,不止机器人/游戏。

Karpathy 的"动物 vs 幽灵"心法(帮你建立正确心智模型):

"We're not building animals. We are summoning ghosts." 译:我们不是在造动物(被进化塑造、有内在动机和好奇心),我们是在召唤幽灵(预训练的统计模拟回路 + 强化学习的附肢)。

冲它发火没用;有正确的心智模型,你才更能驾驭它。

19. 反 pattern 速查表(横切全 11 档)

❌ 别这样	✅ 应该这样	出处
还把 AI 当"聊天机器人"	当成可调度的 agent 舰队(2025/12 起范式已变)	Karpathy
把 vibe coding 和 agentic engineering 混为一谈	抬地板 vs 守天花板,招人定级分开	Karpathy
把某类 App 当成要永久做的产品	先问"模型一句话能不能替代",能则造提示词不造 App	Karpathy(MenuGen)
用"工时"衡量产出	用"能同时盯几个 agent 不翻车"衡量	Lopopolo / Cherny
死认"Claude Code / Codex 哪个最好"	半年翻盘一次,高波动期别刻进脑子;趁补贴薅	Every / Swyx
做万能 harness + 热插拔模型	模型和外壳紧耦合,在"agent 层"做切换	Angela(Anthropic)
以为难点是 harness/提示词缓存	真墙是基础设施产品化(在线/沙箱/容错)	Caitlin(Anthropic)
默认自己训模型	99% 是工具 bug,修 bug;只在检索/排序投训练	Notion
把所有工具一次甩给 agent	渐进披露,让 agent 自己搜工具	Notion(100+ 工具)
用烧 token 的自然语言干确定性任务	让 agent 写段代码一次性算,别反复付 token	Sarah Sachs
暴露自家系统复杂度给模型	"把模型想要的喂给它"(SQL/markdown 而非自家怪格式)	Simon Last
写"教人类怎么做"的文档	给"丢给 agent 的那段文本";多建 CLI 少只建 UI	Karpathy / Swyx
拿 greenfield 的"零人工"经验套祖传屎山	暗工厂打法只验证于空地仓库,存量系统另说	Lopopolo
外包了思考就以为能外包理解	思考可外包,理解不能;你得能验收	Karpathy
冲模型发火、当它是有动机的"动物"	它是"幽灵",建对心智模型才驾驭得动	Karpathy

引用与延伸

横切 11 档播客(全部全文消化,见 frontmatter sources):

AI & I by Every — 《Claude Code Can Be Your Second Brain》(Noah Brier)/《Why We Switched From Claude Code to Codex》(Dan Shipper + Austin)/《The Secrets of Claude's Platform》(Angela + Caitlin @ Anthropic)
Latent Space — 《Extreme Harness Engineering》(Ryan Lopopolo @ OpenAI Frontier)/《Monty》(Samuel Colvin @ Pydantic)/《Notion's Token Town》(Simon Last + Sarah Sachs @ Notion)
No Priors / Training Data — 《Karpathy on Code Agents & AutoResearch》/《Karpathy: From Vibe Coding to Agentic Engineering》/《Boris Cherny: Coding's Printing Press Moment》/《How Cursor Trained Composer》(Federico + Dima)
Unsupervised Learning — 《Ep 85: Has AI Infra Stabilized》(Swyx)

配套 wiki:

newtype · AI Coding 实战与工具栈演化 — 黄益贺(中文视角)2024-2026 AI Coding 工具栈实战;本 wiki 是其"英文 builder 圈"的对照面,两者对"非技术也得有编程思维""Vibe Coding 不能降低思考深度"高度互证
Claude Code 工作流(跨作者主题综合) — Claude Code 具体工作流;§15 的"第二大脑"用法可下钻到此

History

2026-06-05 v1.0 创建 — follow-builders 播客合成,coding-agents 主题桶 11 档全文消化。主题驱动横切(非按集),突出 4 组分歧(Claude Code vs Codex / MCP vs CLI / harness 难不难 / agent 是否基础设施买家)。

2026-09-26 增补：共用执行框架，单独设计审阅与维护者权限

证据范围：Logan Kilpatrick（feed 2026-06-11）与GitHub COO Kyle Daigle（2026-06-17）的本地截断稿，分别只覆盖至07:18、08:01；本节为 partial。下述产品细节是访谈当时的说法。

框架复用解决开发成本，任务差异决定最后一段体验。 Harness（安排模型调用工具、推进任务的执行框架）可以跨产品共用。Logan用“大约80%相同”形容底座复用，同时指出AI Studio编程与常驻个人助手各有优化。这是口头估计，不能把80%设为架构验收指标，也不能只凭节目标题推导“模型必将吃掉全部框架”。

“80% of the same stuff” 译：大约80%的部分相同。

当生成变得容易，瓶颈会移到审阅和贡献治理。Kyle提到GitHub内部法务、财务也在构建小应用；扩大的入口带来更多提交，却不自动增加维护者的处理能力。他描述的链条是先由agent辅助审阅、根据评论修改，再在允许范围内等待CI与政策检查后合并。已经生成代码、审阅通过、允许合并是三个独立状态。

开源又多了一层：公司能约束员工，维护者却未必能控制所有外来提交者。因此平台需要准入、贡献证明与权限等组件，让社区选择自己的规则，不能把一种担保制强推为全部项目的标准。

“really leave them in control.” 译：真正把控制权留给维护者。

给PM的验收问题：共享的是哪些执行能力？哪部分任务需要专门优化？谁能发起、谁能审阅、谁能批准？失败或等待检查时怎么呈现？不要用PR增长代替代码质量：访谈的1700万口径是2026年3月agent创建的PR；全年140亿提交是当时预测，均不是本次核验的业务结果。

2026-09-26 全文增补：设计Agent应支持发散、精修和审阅，而不只是生成

基于Figma Matt Colyer完整访谈00:00—33:52（full_scan）。主持人披露持有Figma股票；未来用户规模和主动agent形态属于观点与计划。

聊天很适合表达第一版意图，却不一定适合并排比较多个方向和精确移动元素。Matt用设计的“发散—收敛”说明画布价值：先保留多个候选，尝试风格、排版与可访问性，再聚类和选择。发散agent应带来不同方向，收敛agent帮助比较，直接操作则让设计师精修。这里仍有未来探索，不能把访谈愿景当已发布功能清单。

内置agent与外部agent可以承担互补路径。 设计系统提供团队组件与规范，外部agent则接入用户既有代码环境。访谈中的往返流程是代码页面→可编辑画布→设计上下文→实现分支与PR截图→人审阅；可评审的实现是终点候选，不是自动合并授权。

“the principles still matter.” 译：设计原则仍然重要。

工作流里最值钱的上下文往往早已存在。其PMOS示例从组织图、Slack与项目工具组合新人入职资料，把经理脑中的隐含关系变成可读取信息；不过“可访问”仍需与任务权限相符，不代表所有数据都可随意取用。

生成量增加后，审阅成了新的瓶颈。截图、录屏或第二个agent都只是候选界面，最终要让人理解改了什么、为什么符合标准、哪些地方仍不确定。软件生成越便宜，持续维护和结果验收可能越重要：嘉宾自建邮件agent后因长期维护成本反而购买更多软件。定时摘要已经能减少主动查看；邮件草拟则仍由用户逐封批准，不能把“主动”与“无须授权”混为一谈。

对设计产品的实用检查是：能否保留探索分支、遵守现有设计系统、做精确修改、显示实现差异，并把生成和批准分开。审美与好奇心帮助用户质疑输出，而不是把第一个看似漂亮的答案当完成。

2026-09-26 全文增补：代码生成提速后，重新测量评审与维护

AI Vibe Check 圆桌讨论了瓶颈迁移：当代码生成更快，团队可能被理解缺口、评审和后续维护拖住。评估应记录从需求到稳定交付的时间与总成本，并比较模型连同工具环境的整体效果，而不只看裸模型分数或代码量。

同一标价下，输出长度、思考量和重试次数也可能改变账单。可以用实际任务比较路由、较小模型和备用服务，并演练容量受限时先降级哪些功能。圆桌关于 API 中断、模型封闭、并购和公司走向的讨论属于情景预测或未经核验说法，不能当作已发生公告。把预测转成可检验的依赖演练，比直接据此迁移系统更稳妥。内容与归因见圆桌精炼。

全文增补：数据合作的信息边界，与模型和运行环境分别验收（2026-09-26）

按 2026-08-04 本地归档的一期 AI Vibe Check 圆桌，普通 API 调用、领域定制、交付专家样本和共享失败评测，会给供应方提供不同的信息。该讨论包含未经核验的公司事件与政策猜测；本页只保留可用于设计产品的分析问题，不将这些叙述视为新闻事实。

为什么要分清合作深度。 一次调用提供的内容，与完整编辑过程、用户最终接受的版本和专家评测集合不同。评估供应商合作时，应分别说明哪些数据进入服务、允许做什么、哪些领域知识构成自身优势。这个信息结构分析不等于断言任何供应商默认拿客户数据训练，实际约定必须另行核对。

案例：数据价值在新增信息。 访谈说 “we wanna maximize the marginal information gain.”（要最大化每条新增数据带来的信息。）用户的修改、拒绝和稀有失败可以比重复常见成功样本更有价值。嘉宾关于更多数据的判断明确附有同等质量前提；样本数量不能替代覆盖范围和反馈质量。

何时用于模型选型。 分开测试权重能力与工具、权限、循环和评测方式，同一个模型换运行环境后结果也会改变。开放权重不自动说明许可条件、部署适配或安全属性。对假设的供应链隐蔽行为，嘉宾明确说当时没有证据证明发生；不能把风险讨论写成某类模型已有后门的结论。业务选型仍应回到任务正确率、实际成本、许可原文和自身控制要求。

来源：开放模型圆桌原文消化。

来源与关联资料

2026-10-08 增补：云端推理和本机执行，要分别记录完成状态

基于10月6日、7日 Builders 日报中的 Thariq、Boris Cherny 发言整理。只消化已捕获的中文日报，不将其标成原帖或播客全文核验。

“云端大脑、本地双手”有一个实际前提：本机必须可用。 Thariq 的讨论把云端推理与本地操作分开，同时指出离线设备和同步边界尚有问题。对产品来说，云端已经排好计划，不能证明本机已经执行。任务卡应分别显示计划就绪、设备可达、动作已执行和结果已验证；恢复连接后先确认旧动作结果，再决定是否重试。

编辑应用建议：断线不是成功，也不一定等于失败。 假如 agent 正在本机导出报表，网络断开时可能已经生成文件，也可能只完成下载的一半。恢复后检查目标文件、任务编号和完成记录，能避免重复导出或误报完成。若动作是发送消息或修改外部记录，结果不明时更应先查询回执。这里的状态设计是据发言推导的产品方法，不是对某家 agent 已支持这些能力的保证。

委派时说清三个问题。 Boris Cherny 在10月7日强调目标、投入程度和验证方式。可以把任务写成“整理本月已结算订单，最多使用本次提供的材料，金额与原表逐项核对后输出”；相比“认真分析一下”，执行者更容易知道何时停止、如何判断完成。验证方式必须对应真实目标：生成一个文件只是中间状态，字段完整、数值一致、可被使用才是结果。

适用边界。 本地文件、浏览器和设备参与的任务需要这些状态；纯云端任务也应检查其外部依赖，不能因为运行位置在云端就推断全天可用。对于一次性低风险草稿，不必堆叠复杂调度系统，但仍应明确完成标准。

增补来源：Builders 2026-10-06、Builders 2026-10-07。

October 8, 2026 addition: track cloud reasoning and local execution separately

Based on remarks by Thariq and Boris Cherny in the October 6–7 Builders digests. This addition uses the captured digest text; it does not claim a fresh review of the original posts or complete podcast transcripts.

A cloud brain with local hands still needs an available device. Thariq separated cloud reasoning from local operations and noted unresolved boundaries around offline devices and synchronization. A completed cloud plan does not prove that the local action ran. Task interfaces should distinguish plan readiness, device reachability, execution and result verification. After reconnecting, establish what happened to the previous action before retrying it.

Editorial recommendation: disconnection is neither proof of success nor necessarily failure. An agent exporting a report locally may have created the file before the network failed, or may have downloaded only part of it. Checking the destination file, task identifier and completion record after recovery can prevent duplicate exports and false completion claims. For messages or changes to external records, query the receipt before retrying an action with an unknown result. This is a product design recommendation derived from the remarks, not a claim that a particular agent implements these capabilities.

Specify three things when delegating. Boris Cherny's October 7 remarks emphasized the goal, effort and verification method. “Compile this month's settled orders, use only the supplied material, and check each amount against the original table” gives clearer stopping and completion criteria than “analyze this carefully.” Verification must match the real objective: creating a file is an intermediate step; complete fields, consistent values and a usable result establish completion.

Scope and limits. Tasks involving local files, browsers or devices need these distinctions. Cloud-only tasks should also check external dependencies; cloud execution alone does not establish continuous availability. A low-risk, one-off draft does not require a complex scheduling system, but it still needs a clear completion criterion.

Sources for this addition

2026-10-15 增补：源码系统迁移要连同审阅和运行依赖一起验收

证据范围：10/14 Builders 收录的 Anthropic Scion 工程博客，已读取完整公开正文。性能与团队投入均为厂商内部案例，不是普通团队可直接复现的收益承诺；这里只提炼迁移与审阅边界。

为什么生成更多代码会改变基础设施需求。 Scion 面向巨大的统一代码仓库，把历史查询、合并等工作放到服务端，客户端按需读取文件与目录对象。其迁移同时依赖 Antique 审阅工具、搜索和持续集成（CI，自动构建与检查代码的流程）。因此，“新工具能取出代码”只是局部成功；完整工作还必须能找到相关实现、理解修改、运行检查并完成受控合并。

工程师要守住什么。 博客写道：“Engineers are no less valuable, but their work is changing.”（工程师的价值没有降低，但工作正在变化。）当代理能快速生成实现时，工程师仍要定义不可破坏的系统约束、解释为什么作出取舍，识别没有必要的复杂设计。审阅不只检查代码能否运行，还要检查实现是否符合原本意图，是否把成本或故障转移给了下游系统。

编辑应用推导：用完整任务验收迁移。 选一项包含查询、修改、审阅、自动检查和合并的真实工作，把各环节依赖和负责人列清。若取代码更快，却让审阅者找不到历史或让自动检查失效，不能宣布迁移完成。先用自己的仓库规模和工作负载验证，再判断是否值得迁移；不要仅凭厂商的内部倍数改造一般团队的工具链。交付与运行责任另见企业 AI 交付责任。

来源: Anthropic: Redesigning source control.

October 15, 2026 update: Validate a source-control migration together with review and operational dependencies

Evidence scope: Anthropic's public engineering post about Scion, read in full. Performance and staffing figures describe the vendor's internal experience, not benefits that ordinary teams can necessarily reproduce. This section focuses on migration and review boundaries.

Why generating more code changes infrastructure needs. Scion serves a very large monorepo, moving work such as history queries and merges to the server while clients fetch file and directory objects on demand. The migration also depends on the Antique review tool, search, and continuous integration (CI: automated build and code-checking workflows). Retrieving code with the new tool is therefore only one part of success. A complete task must also let people find relevant implementations, understand changes, run checks, and complete a controlled merge.

What engineers still need to protect. As the post explains, engineers remain valuable while the nature of their work changes. When agents can produce implementations quickly, engineers still need to define system constraints that must hold, explain tradeoffs, and identify unnecessary complexity. Review should check whether the implementation matches the original intent and whether it shifts costs or failures to downstream systems, as well as whether the code runs.

Editorial application: Validate the migration with a complete task. Choose a real task that includes searching, editing, review, automated checks, and merging; identify the dependencies and owners at each step. Faster code retrieval does not mean the migration is complete if reviewers lose access to history or automated checks stop working. Test against your own repository size and workload before deciding whether to migrate. Do not redesign an ordinary team's toolchain solely because of a vendor's internal performance multiples. See enterprise AI delivery responsibilities for the related discussion.

Source: Anthropic: Redesigning source control.

2026-10-18 案例：让 AI 产物帮助自己学习和验收

来自10月2日 Builders 对 Thariq 与 Guillermo Rauch 发言的整理；本轮未独立测试原型或观看演示，个人体验不作效率保证。

Thariq 为改进游戏跳跃动画，让 Claude 教概念、寻找参考，再生成可反复调节的动画编辑器。Rauch 则尝试让应用逐步讲解支撑功能的实现。两者补充了本页“判断与品味仍由人负责”的讨论：可以让 AI 先造一个便于比较和试错的小工具，把自己的判断对象变得更具体。

本库应用建议：选一个看得见的质量问题，固定参考和比较条件，每次只调整少量参数；记录哪一版更接近目标、为什么。对代码，要求解释关键实现与约束，再以测试和实际运行核对。讲解流畅不能证明实现正确，动画编辑器能用也不能证明整个游戏体验合格。适合需要反复比较的局部问题，不必为一次简单修改再开发一套复杂工具。

Case: Use AI-generated tools to support learning and acceptance testing

This case draws on the October 2 Builders accounts of posts by Thariq and Guillermo Rauch. The prototypes were not independently tested and the demonstrations were not watched in this review. Personal experiences are not efficiency guarantees.

To improve a game's jumping animation, Thariq asked Claude to teach concepts, find references and generate an animation editor for repeated adjustment. Rauch experimented with having an application explain the implementation behind its features step by step. These examples extend the existing discussion of human judgment and taste: ask AI to create a small tool that makes comparisons and experiments easier, so that the object of judgment becomes concrete.

An editorial application is to choose one observable quality problem, fix the reference and comparison conditions, and adjust only a few parameters at a time. Record which version is closer to the goal and why. For code, ask for the key implementation choices and constraints, then check the explanation against tests and actual execution. A fluent explanation does not prove correctness, and a working animation editor does not establish that the whole game experience is good. This approach suits local problems requiring repeated comparison; a simple one-off change does not require a complex new tool.

2026-10-21 增补：将规划、隔离执行与挑战性复核分开

Peter Steinberger 的使用记录给出一个具体分工：Astra 规划，在独立 worktree 中运行 Codex CLI，由 Sol 6.1 编码；另一个 Agent 监督并挑战规划者，而不是只让同一个 Agent 阅读目标文本来自检。他为这个“smart goal”方式写了 OC 插件。这是一个作者的经验，原帖未给完整插件代码、比较任务集或性能数据，不能据此认定 subagent 普遍更差。

可迁移的是职责边界：规划者负责说明目标和当前路线；执行者在隔离目录交付实际文件；复核者检查产物是否回答目标、证据是否充分、是否跑偏。独立目录能减少文件互相覆盖，不能自动消除错误；第二个 Agent 的反对意见也需要回到文件差异和运行结果核实。适用于任务可以拆出清楚产物、且值得承担额外协调成本时；很小的改动不应为了形式增加一层监督。

English

Peter Steinberger reports a concrete division of work: Astra plans and runs Codex CLI in separate worktrees, Sol 6.1 codes, and another agent supervises and challenges the planner. This differs from having the same agent read a goal text to review itself. He wrote an OC plugin for this “smart goal” arrangement. The post provides one author’s experience, without complete plugin code, a comparison task set or performance data. It does not establish that subagents are generally inferior.

The transferable idea is a boundary between responsibilities. The planner explains the goal and current approach; the executor delivers actual files in an isolated directory; the reviewer checks whether the deliverables answer the goal, whether the evidence is sufficient and whether the work has drifted. Separate directories can reduce overwrites without eliminating errors. A second agent’s objections still need checking against file changes and execution results. This arrangement is most relevant when deliverables can be defined clearly and justify coordination costs; small changes do not automatically need another supervisory layer.

2026-10-22 增补：按后果决定需要理解与承担责任的深度

AI 让生成代码更便宜，并未消除维护、数据泄露和错误发布的后果。深思圈转述 Guillermo Rauch 的一个有用区分，是个人试验小工具与承载他人数据、关键业务的系统，需要不同程度的理解与验收。这里不要求每个使用者重写全部代码；需要的是对具体后果负责的人，能够解释关键数据流、授权边界和失败时会发生什么。

落到项目上，可以先列出最坏结果，再决定审阅深度。仅在隔离环境里处理可丢弃测试数据的原型，可以用较轻的反馈循环；一旦接入真实用户数据、持久写入或外部服务，就应明确关键路径、错误恢复、权限和负责接手的人。这个分层是本站应用建议，不能因为项目自称“小工具”便忽略真实影响。

访谈中的部署比例、迁移用时和“可证明正确”的未来判断，尚未在本轮核对原节目，不当作提升效果或安全保证。沙箱、测试和证明分别覆盖不同性质；检查通过只能支持其所覆盖的条件，不能推导整个系统永远安全。与本页已有独立挑战复核互补：复核还要问“谁承担后果、哪些部分必须能讲清楚”。

来源：深思圈对 Guillermo Rauch 访谈的中文转述。

English edition

AI Builders: Coding Agents and Agentic Engineering

This note brings together discussions of coding agents from eleven English-language podcast sources—AI & I, Latent Space, No Priors, Training Data and Unsupervised Learning—organized by concept rather than episode. In the spring 2026 accounts collected here, Karpathy, Claude Code creator Boris Cherny, the OpenAI Codex team, Cursor, Notion and Pydantic converge on a shift from typing code toward expressing intent to agents and checking results. They disagree at several crucial junctions; those differences are retained below.

Open this note when:

You hear people say they no longer write code and want to understand what they mean.

You are choosing between Claude Code and Codex and want the reasoning of daily users.

You work in product or operations and wonder how coding agents can handle email, research or metrics.

You want explanations of skills, harnesses and MCP versus CLI.

You need to explain why coding ability alone may become less scarce, and what remains valuable.

Reading the historical material. Product comparisons, prices, model names, performance numbers and forecasts below belong to the cited accounts and their original dates. Translating this archive does not independently verify or update those claims. Later additions retain their own evidence limits.

0. A map of the shift

Think of AI-assisted coding as levels of an elevator. The speakers occupy different floors but look in the same direction:

Level 0  Humans type; AI completes code (the 2024 pattern discussed in the newtype notes).
Level 1  Vibe coding: describe what you want; keep watching and correcting (Karpathy's term).
Level 2  Agentic engineering: dispatch agents; express intent and validate deliverables (the December 2025 turning point).
Level 3  No human review: agents open issues and modify their own systems (the “dark factory” frontier).
Level 4  Automated research: supply a goal and budget; agents run and iterate on experiments (Karpathy's AutoResearch).

Why this map matters. Many people still equate AI with a chatbot, while these speakers describe work at levels 2–3. The sections below unpack individual parts of that map.

1. December 2025: from typing to orchestration

Almost all the interviewees identify December 2025 as a turning point.

Karpathy, an OpenAI cofounder and former Tesla leader, says in No Priors and Training Data that he probably has not typed a line of code since December. He describes spending sixteen hours a day expressing his will to agents: “Code” no longer feels like the right verb; “manifest” is closer.

He describes moving from writing 80% of the code himself to handing about 80% to agents, and argues that the default workflow of an ordinary software engineer changed fundamentally that December.

Boris Cherny, Claude Code's creator, gives a more extreme account in Training Data: the model writes all his code, and on one day in the preceding week he submitted 150 pull requests.

The note's interpretation. Independent speakers in the OpenAI and Anthropic ecosystems describe a similar change in the same month. Karpathy argues that anyone who assessed AI as merely a ChatGPT-style conversational toy a year earlier should reassess coherent agent workflows. These are practitioner accounts, rather than a controlled measurement of every team's productivity.

For nontechnical readers. The work moves from typing toward explaining what you want and deciding whether the result meets it. The bottleneck shifts from your fingers to your understanding and direction.

2. Vibe coding and agentic engineering are different

Karpathy repeatedly distinguishes these easily confused terms.

Question	Vibe coding	Agentic engineering
What do you do?	Ask AI to generate something that runs	Direct agents to deliver professional software
What problem does it address?	Raise the floor so more people can build	Preserve the ceiling of professional quality
Does quality remain your responsibility?	Often, running at all is sufficient	Yes: prevent vulnerabilities and remain accountable
Claimed speed ceiling	Relatively modest	Very high; speakers say beyond the old “10× engineer”

In Training Data, Karpathy frames vibe coding as raising the floor and agentic engineering as preserving professional software's quality bar while accelerating work. He says skilled practitioners can peak far above a tenfold speedup.

Product-management implication. Assembling a Cursor demo and coordinating agents to deliver a reliable production system require different skills. The original note proposes distinguishing those skills in hiring, leveling and task allocation; it does not establish that agents produce bug-free systems automatically.

3. Software 1.0, 2.0 and 3.0

Karpathy's three-part model appears across both interviews, and Cursor's Dima uses a related framing.

Generation	What you program	Plain-language description
Software 1.0	Explicit code	A programmer writes if/else logic
Software 2.0	Datasets and neural-network training	Program through data in the deep-learning era
Software 3.0	Prompts and context	Treat the language model as an interpreter and steer it with context

Dima adds a training perspective: sculpt code in 1.0, training data in 2.0, and evaluation rubrics in 3.0.

The proposed conceptual shift. Karpathy argues against treating AI only as an accelerator of existing software patterns: neural networks may directly perform jobs for which people previously built full applications.

His MenuGen example contrasts an OCR/image-generation/Vercel application for illustrated restaurant menus with simply giving Gemini a photograph and asking Nanobanana to overlay dish pictures. In that example, much of the application becomes unnecessary.

Product implication. A future model may replace a feature with a single instruction. Before building an application, ask whether direct model interaction can already do the job. Section 7 explains the accompanying argument about automating what can be verified. This is an architectural question, not proof that every application should become a prompt.

4. One person directing an agent fleet

The interviewees describe parallel agents with a person coordinating them.

Karpathy's “Peter Steinberg prototype.” His account describes a screen filled with Codex agents, each working intensely for about twenty minutes, roughly ten local repository checkouts, and a person allocating work among them. The name follows the archived note.
Cherny's phone workflow. He describes mainly using the Claude app's code tab on a phone: five to ten simultaneous conversations, hundreds of running agents and thousands tackling deeper work overnight.
Karpathy's new unit of work. Issue “macro actions” to repositories: send independent features to different agents; one researches, another codes, another plans. Orchestration becomes practiced muscle memory.

The note identifies token throughput and human attention as scarce resources. Karpathy compares unused subscription capacity to a doctoral student distressed by idle GPUs; when Codex runs out, he switches to Claude.

Ryan Lopopolo of OpenAI Frontier emphasizes the synchronous attention of his team as the fundamentally scarce resource.

Interpretation. Tokens and GPUs can support much more parallelism than a person's limited daily attention. The engineering objective becomes reducing the need for continuous human participation.

Application. Hours alone become a weak measure of output. A more relevant skill is how much concurrent agent work you can direct without losing control of results. That coordination still requires practice.

5. Skills, harnesses and loops

5.1 A skill is a Markdown file with scripts

Swyx, the Latent Space founder then at Cognition, describes skills in Unsupervised Learning as a Markdown file plus attached scripts.

His minimal agent formulation combines a tool-using model in a loop with a filesystem, retrieval and skills. The speakers present this as an emerging common foundation.

In plain terms, write down an operating procedure and provide the scripts an agent can follow. The note emphasizes how accessible the instruction-writing portion is; scripts themselves may still require engineering.

5.2 A harness is the assembly around the model

The model is the engine; the harness is the surrounding structure. Angela from Anthropic's platform team reports substantial performance differences between harness arrangements tested for agent memory in AI & I. Her point is that assembling the right surrounding components can yield large improvements.

5.3 Loops and routines support repeated work

Cherny favors /loop: schedule Claude to maintain pull requests, repair continuous integration, rebase, keep tests healthy or cluster Twitter feedback every thirty minutes. He calls loops a major future direction and encourages experimentation.

The newly discussed Routines move this pattern to a server so it can continue with the laptop closed.

Why these matter together. They change the interaction from asking and answering one question at a time toward sustained work. That is part of the transition from level 1 to levels 2–3.

6. Disagreement: Claude Code or Codex?

The same experienced users choose different tools and explain why.

Dan Shipper and Austin of Every, in AI & I's account of switching from Claude Code to Codex:

Dan describes Codex three to six months earlier as poor. Austin describes feeling unusually ineffective using it two months earlier, finding it argumentative and lacking social sensitivity.
They describe an approximately three-month turnaround from a sandbox mainly suited to senior engineers into a daily tool. Austin says he spends 80% of his work time in the Codex app. He attributes this to a faster, stronger desktop experience and stronger subagents, rather than a clear model-intelligence advantage: he considers the latest Opus and GPT at least tied for his knowledge work. His 30–40% improvement estimate is personal.
He does not argue everyone must switch: Claude's desktop app had already changed his work. He also describes low migration effort—asking Codex to transfer his Claude setup.

Karpathy's personality comparison, in No Priors: Claude feels like a teammate and gets praise approximately right; coding-oriented Codex feels dry and less invested in what the user is creating.

Samuel Colvin of Pydantic, in Latent Space, uses all three providers and compares Claude Code to Captain America, Codex to the technically minded Q from James Bond, and Gemini to the Joker: sometimes impressive but, in his account, prone to destructive mistakes. These are his colorful impressions, not measured failure rates.

How to use the disagreement:

There is no permanent winner; perceptions can reverse within six months. Swyx describes a volatile period.
Desktop engineering, speed and subagent experience may matter as much as underlying model intelligence.
Swyx characterizes Anthropic as a premium, constrained bundle and OpenAI Codex as an invitation to experiment through subsidies, an open SDK and quota resets. The archived note suggests making use of available subsidies and cites a $200 monthly exploration plan; these are dated commercial observations, not current pricing advice.

Dan Shipper argues that people who adopt new tools, paradigms and workflows can gain an advantage by default. Every holds two “Think Weeks” a year, suspending routine work to explore tools; he recommends at least one day per quarter for other teams.

7. Verifiability and jagged intelligence

Karpathy offers a general test for whether AI can help with a task: traditional software automates what can be specified in code; language models automate what can be verified. Reinforcement learning rewards verifiable domains, producing uneven or “jagged” capabilities—exceptionally strong in some math and code tasks, much weaker elsewhere.

In Training Data he contrasts the reported ability of Opus 4.7 to refactor a 100,000-line codebase or find zero-day vulnerabilities with its suggestion to walk to a car wash. The model designation and examples are retained from the account.

He attributes unevenness to what is verifiable and to what laboratories choose to put in training. His chess example describes a large GPT-3.5-to-GPT-4 improvement after adding chess material, rather than assuming a uniform increase in general intelligence. Users remain dependent on laboratories' choices.

Proposed product and startup implications:

Ask whether your application sits inside an effective RL feedback loop. Math, code and automatically scored tasks may benefit more directly than ambiguous tasks with no clear correctness test.
A verifiable domain a laboratory does not prioritize may still offer an opportunity to fine-tune.
Karpathy's optimistic view is that even subjective tasks such as writing could be made more verifiable through a council of model judges. He frames this as difficulty rather than impossibility; it remains his forecast.

He also repeats the distinction between outsourcing thought and outsourcing understanding. Humans may become the director or bottleneck, but they still need to understand enough to judge results and direct work.

8. Disagreement: MCP or CLI?

Two routes connect agents to tools and data:

MCP, the Model Context Protocol: a standard way to declare tools and delimit available actions.
CLI, the command-line interface: let the agent operate through terminal commands.

CLI-leaning views:

Ryan Lopopolo argues that loading every tool's description into context interferes with compaction and can leave agents losing track of their tools. He prefers thin command-line wrappers around what is actually needed—for example, three Playwright calls—and concise outputs containing failed tests or relevant log errors.
Simon Last of Notion favors the terminal's pagination, progressive disclosure and capacity to bootstrap new tools. His example is having an agent write roughly a hundred lines around Chromium APIs to give itself a browser.

MCP-leaning views:

Simon also acknowledges MCP's useful simplicity and permission model, particularly for narrow, lightweight agents requiring clear access boundaries.
Cherny calls MCP the simplest answer for knowledge work: the same Salesforce or Google Docs/Calendar connectors can be reused in Cowork, Claude CLI and Claude Code. Computer use can fill gaps where no MCP integration exists.

Cherny's common ground is that, to a model, MCP, CLI, APIs and computer use all become tokens. Evaluate token efficiency, permission clarity and whether the agent can debug its own interaction.

Sarah Sachs's cost argument. Using language-model inference to execute deterministic tasks can be wasteful. Under usage-based billing, code that invokes a deterministic tool can be cheaper than repeatedly spending model tokens on individual tool invocations, especially beyond a cache window. The source uses the unclear term “CLor”; it is retained here as an uncertain transcription, not expanded into a claimed product. Notion deliberately implements core search directly rather than using MCP for that path.

The note's decision heuristic: MCP for narrow, stable work with strong access boundaries; CLI for exploration, self-repair and high-volume work where tool design can reduce cost. This is a heuristic, not a universal performance result.

9. Disagreement: is the harness the hard part?

Caitlin from Anthropic's platform team argues in AI & I that teams may expect harness engineering to be the main difficulty but ultimately hit an infrastructure wall.

Her distinction is between SDK-supported work such as prompt caching and context management, and turning the agent into a product: servers staying available, starting and stopping execution, preserving conversations, safe sandboxes and fault tolerance when a sandbox dies. This motivates the team's Managed Agents work.

Angela's simultaneous claim of substantial harness gains is therefore a different layer: a harness can improve performance, while scaled production use still requires reliable infrastructure.

Angela also argues that as laboratories' approaches diverge, harnesses and models may become more tightly coupled. Rather than imagining one universal harness with interchangeable models, redundancy may need to switch the whole agent—model and harness together.

Procurement and architecture implication. Check the complete agent configuration when replacing a model. The speakers' warning challenges the assumption that a universal middleware layer makes every model swap effortless.

10. The extreme case: the “dark factory”

Ryan Lopopolo's OpenAI Frontier team describes an experiment banning handwritten code so the team must teach Codex to perform engineering work.

Reported results over about five months: around a million lines, approximately 1,500 pull requests and three people, eventually about ten times faster than hand coding. The first month and a half was reportedly ten times slower while they built the surrounding system.

Operational ideas from the account:

Move human inspection after merging. Instead of serving as a universal pre-merge gate, people sample results to find where the team struggles. A code-review agent may merge autonomously in this experiment.
Models need text. Documentation, actionable errors, technical tracking, quality scores and PR comments pass missing context between agents.
Each mistake exposes an unwritten requirement. Turn engineers' tacit quality standards into documentation, tests and review rules.
Code can be disposable. A failed PR that will not merge cleanly may lead them to discard the workspace and restart, then encode why the previous attempt failed.
Trust needs digestible evidence. Rather than watching an entire Cursor recording, Lopopolo wants an agent to attach a video showing why its change works and is ready to merge.

Swyx calls these “dark factories.” He contrasts the once-radical idea of no human-written code with the next frontier of no human review before merge. In his view, scale requires a shift toward more testing and automatic verification, using volume to improve quality.

Scope limitation emphasized by Lopopolo: this was a new, greenfield repository. It does not establish that the approach transfers to old, brownfield systems. Do not treat the experiment as a blanket promise for a legacy codebase.

11. Train your own model or use a frontier model? Cursor's “agent lab” approach

Notion rejects training its own foundation model (section 13), whereas Cursor explains a different set of conditions.

Swyx's agent-lab sequence, in Unsupervised Learning: start with the strongest frontier model, specialize the product for a domain, and only after accumulating enough high-quality real-user work train a smaller model to reduce cost or latency. He calls this a reversal of the bitter lesson: begin with a general model and distill frequent, relatively stable work into something smaller.

Cursor's account of Composer 2, in Training Data:

Treat the weights as a limited hard drive. Allocate capacity to software engineering inside Cursor, rather than programming in general.
Specialization is presented as the reason it can cost roughly an order of magnitude less than Opus.
Start from the open Kimi 2.5 base, described in the account as a one-trillion-parameter mixture-of-experts model with thirty billion active parameters. Use mid-training and reinforcement learning rather than pretraining from scratch, prioritizing a useful model quickly.
Train compression and self-summarization within the RL loop. A model with a 200,000-token window can, according to the account, perform much longer work by summarizing and restarting context.

Federico cautions that prompt engineering has an upper bound: post-training is needed to shape some product behaviors. Composer ships with a prompt, but he believes training already pushes it toward the intended behavior sufficiently to work without that prompt.

The note's conclusion for most companies: do not assume you should train your own model. Cursor has its product as an RL environment and access to tens of thousands of GPUs. Without equivalent conditions, frontier models plus careful tools, harnesses and validation may be the more practical path. Section 13 gives Notion's reasoning.

12. Monty: lightweight code execution and the conditions for a hundredfold speedup

Samuel Colvin's Monty project illustrates a tradeoff relevant to product managers.

Agents often need to write a little code to calculate something. Pure tool calls are simple and constrained but less expressive. A complete sandbox is powerful but needs additional infrastructure and may be unacceptable to some large financial institutions. Monty aims between these options: code-mode expressiveness without a full sandbox. The interview contrasts single-digit-microsecond execution overhead with about a second to start a sandbox; these are the reported project figures.

Colvin's four conditions for unusually large, rather than merely three-to-fivefold, AI engineering gains:

The model knows the internal implementation concepts, such as heaps or bytecode interpreters.
It knows the external interface very well; Python semantics are the example.
Excellent unit tests are easy to construct—compare against CPython and repeatedly iterate until they pass.
The API specification does not require negotiation: Python already defines behavior and errors.

He uses these conditions to explain why people are cloning Redis in Rust.

Application. Existing reference answers, easy tests and settled specifications make a task much more suitable for dramatic acceleration. Without objective standards, do not assume a hundredfold gain. This connects with verifiability in section 7.

Type safety. Colvin regards it as important for humans and critical for AI. He reports four Anthropic employees independently stressing type safety for chained tools and programmatic tool calls. He inferred that Anthropic was working on programmatic tool calling, which the account says was subsequently released.

13. Notion's counterpoint: not everything needs an agent or an in-house model

Sarah Sachs and Simon Last offer a counterweight to “agents eat everything” in Latent Space.

Automatic model selection is important work. Users need to trust that “Auto” means the model suited to the task, rather than the cheapest and least capable one. Sachs compares the positioning to automated investing or an index fund. She says Notion does not treat Auto as a profit-maximization device; it reduces anxiety because most tasks do not need an Opus-class model.

Her distinction from frontier laboratories is replacing processes, rather than necessarily replacing people. Notion, she says, is not incentivized to maximize token consumption. Sometimes the right tool is ordinary code and no agent at all.

Why not train a foundation model? Sachs says it is outside their core competence and budget. Fine-tuning on their own tools is also hard to sustain because the tools change every day. Simon calls training an implementation detail: most problems turn out to be tool bugs, so fix those and improve the harness, tools and validation. Retrieval and ranking are the exception they consider worth training for, particularly as agents generate more search traffic and write queries differently from people.

Lessons from rebuilding Notion's agent about five times:

Give models the representations they handle well, rather than exposing all the complexity of your own system.
Replace a proprietary, difficult JSON database-query format with SQLite because models understand SQL. Replace lossless XML with Notion-flavored Markdown because models understand Markdown.
Move from few-shot prompting to goal-oriented tool definitions. Previously, only five or six people could touch a shared prompt, creating a center-of-excellence bottleneck. Tool definitions let individual teams own their tools; this was described as the largest speed lever.
More than a hundred tools creates a progressive-disclosure problem. Even a greeting can consume thousands of tokens, and an obscure added tool can degrade the whole system. Rework the harness so agents search and select tools instead of receiving everything at once.

Simon describes coding agents as an underlying kernel that can enable much broader work. This aligns with the idea that software-building capability can support other forms of knowledge work; it remains the speakers' broader interpretation of the technology.

14. Domain knowledge, judgment and taste

This is the recurring opportunity for nontechnical readers.

Cherny's printing-press analogy. He compares software democratization with falling book prices and rising literacy after printing: the account cites roughly 10% initial European literacy, more books in fifty years than the preceding thousand, a roughly hundredfold price decline and eventual literacy around 70%. These are historical figures used in his analogy, not independently researched here. He expects the software transition to happen faster.

His product point is that a strong accountant may be best placed to specify accounting software: coding becomes easier, while knowing the domain remains hard.

Karpathy's division of responsibility. People retain taste, judgment, aesthetics, specifications, design and supervision. Agents resemble interns with excellent recall who fill in details, while people own decisions such as whether user identifiers must be unique.

Sachs's identity-crisis observation. Engineers are encountering a familiar managerial transition: delegation and context switching become more important relative to personally writing code.

For a nontechnical product manager:

Domain expertise can become a product more directly, with less dependence on first finding an engineer.
This does not mean no foundational understanding is required. Programming reasoning, judgment and acceptance testing still matter; the related newtype coding note makes a similar warning.
If AI-generated work carries your name, you remain responsible for it. Dan Shipper says he may prefer an agent-assisted document, provided the person has thought it through and can stand behind every line. Trust rests on ownership of the result.

15. Claude Code as a second brain

Noah Brier, founder of Alephic, describes his main Claude Code use in AI & I as interacting with research and notes rather than coding. It sits over an Obsidian collection of Markdown files and folders synchronized with Git.

Practices from his account:

Start at the root of the note collection, rather than an individual project folder, so it can search roughly 1,500 notes. Organize them with PARA.
Use a re-entry request such as “Can you catch me up on the last few days of research?” to recover the thread of deep work; claude --continue resumes the conversation.
Create a thinking-partner subagent whose job is to ask sharp questions and support thought, with explicit instructions not to write a finished artifact. Maintain a running account of what has been uncovered.
Expect a recurring failure: even told not to produce an outline or draft, the model may still try to generate one. Brier uses a firm opening instruction forbidding outlines, drafts or other versions. He speculates that helpfulness and incentives around producing artifacts have become part of the model's behavior.

Brier's reframing. Calling the technology “generative” makes people focus on writing and underestimate reading. People think about things far more often than they finish artifacts; reading can therefore be the more useful everyday capability.

For someone using a Markdown knowledge repository, this pattern is directly comparable. See the related Claude Code workflow note for practical details.

16. SaaS, changing moats and Jevons's paradox

Cherny uses Hamilton Helmer's Seven Powers framework. He argues AI weakens switching costs, through easier migration, and process power, through goal-directed improvement. Network effects, economies of scale and exclusive resources remain. He predicts roughly ten times as many disruptive startups over the next decade because small teams can build valuable products that compete with large firms. The model reference “Claude 4.7” belongs to the archived discussion.

Swyx's description of the coding market. The source labels the numbers as disputed industry estimates: about $2.5 billion ARR for Claude Code, $2 billion for Codex and a rumored $2 billion for Cursor. His possible outcome is two large players plus a long specialized tail. He describes capability exploration rather than efficiency optimization, with incentives to consume more tokens and a belief that overall AI use is still too low. These figures and predictions are dated claims.

Karpathy's software version of Jevons's paradox. Making formerly scarce, costly software easier to create can unlock more demand. He uses the ATM-and-bank-branch example to illustrate the argument. He sees code as increasingly ephemeral and changeable, rather than a fixed subscription purchase, and is cautiously optimistic about total demand.

Product interpretation:

Moats based mainly on switching difficulty or process complexity may be weakened.
Network effects, scale and exclusive resources may be more resilient.
Rebuilding software is only part of the challenge. Swyx compares $200,000 in annual SaaS spending with an estimated $2,000 rebuild, but the harder issue is bringing less AI-native teammates along. Uneven adoption inside a company can cause real friction. Neither estimate is a verified migration budget.

17. Disagreement: are agents the new infrastructure buyers?

Swyx and Vercel CTO Malte Ubl argue that agents increasingly select and use infrastructure. A service inaccessible through an agent-usable API can effectively be invisible to them.

The account says bots represented about 60% of Vercel application-management/configuration traffic. Sachs expects much future interface traffic to come from agents. The proposed response is to provide CLIs alongside interfaces.

Swyx also demystifies “Agent Experience,” a term associated here with Netlify: good documentation, discoverability, progressive disclosure and consistent, largely stateless APIs were already useful for people. Higher volume and more spam may be changes in degree rather than a completely new discipline.

AEO/GEO—visibility in AI recommendations. The archived Resend example claims that Claude recommended it by default in about 70% of email-provider queries despite its 2023 founding. Swyx expects memory and personalization to outweigh mention frequency in three to four years, possibly narrowing defaults to around three services rather than twenty. These are a source example and forecast, not current search measurements.

Suggested actions:

Make documentation directly usable by an agent, including text a user can hand over without rewriting it.
Complement the UI with CLI/API access.
Explore recommendation visibility without staking everything on repeated mentions; consider how a service earns ongoing, personalized selection.

18. AutoResearch, memory and world models

Karpathy's AutoResearch. Extend reduced human participation to research: give an agent a goal, measurable metric and constraints, then let it run experiments overnight. He reports that experiments on NanoChat found a forgotten weight-decay choice and an untuned Adam beta after years of manual tuning. He imagines a research organization described by Markdown roles and relationships—ProgramMD—and even optimization of that description itself.

He retains two conditions: cheap, objective feedback is needed, and the stack is still fragile enough that pushing too far ahead may be unproductive.

Swyx on memory. Context length may be the slowest-scaling part of language models and memory the largest constraint. The account notes roughly three years from 4,000-token to one-million-token windows, with Gemini's large window rarely fully used despite being available for two years. These are the discussion's temporal observations.

His next frontiers are memory/personalization and world models, the latter relevant to intelligence beyond robotics and games.

Karpathy's “animals versus ghosts” metaphor. These systems are not animals shaped by evolution, intrinsic motives and curiosity; he describes them as statistical simulation from pretraining with reinforcement-learning additions. Anger at a model is unhelpful. A better mental model helps people direct it more effectively.

19. Anti-pattern reference

Avoid	Prefer	Source
Treating AI only as a chatbot	Evaluate coordinated agents and the post-December-2025 workflow	Karpathy
Equating vibe coding with agentic engineering	Distinguish accessibility from professional quality	Karpathy
Assuming every application is a permanent product category	Ask whether a model can perform the job directly	Karpathy / MenuGen
Measuring output only in hours	Assess concurrent work and reliability	Lopopolo / Cherny
Fixing a permanent tool ranking	Reassess volatile tools and dated subsidies	Every / Swyx
Assuming universal harnesses make model swaps trivial	Evaluate switching whole model–harness combinations	Angela
Treating caching and prompts as the only hard problems	Check uptime, sandboxes and fault tolerance	Caitlin
Defaulting to training a model	First fix tool bugs; assess retrieval/ranking separately	Notion
Loading every tool into context	Use tool discovery and progressive disclosure	Notion
Repeated inference for deterministic work	Generate code for an explicit calculation or tool operation	Sachs
Exposing obscure internal formats	Use model-familiar SQL and Markdown where suitable	Simon Last
Providing instructions only for human operation	Provide agent-usable instructions and programmatic interfaces	Karpathy / Swyx
Applying greenfield autonomy claims to legacy systems	Check brownfield transfer separately	Lopopolo
Assuming outsourced thought removes the need to understand	Retain enough understanding to direct and validate	Karpathy
Treating a model as an animal with motives	Use an appropriate account of how it behaves	Karpathy

References and further reading

The original synthesis records complete reading of eleven podcast sources:

AI & I by Every: “Claude Code Can Be Your Second Brain” (Noah Brier); “Why We Switched From Claude Code to Codex” (Dan Shipper and Austin); “The Secrets of Claude's Platform” (Angela and Caitlin at Anthropic).
Latent Space: “Extreme Harness Engineering” (Ryan Lopopolo at OpenAI Frontier); “Monty” (Samuel Colvin at Pydantic); “Notion's Token Town” (Simon Last and Sarah Sachs).
No Priors / Training Data: the accounts of Karpathy on code agents and AutoResearch, the transition from vibe coding to agentic engineering, Boris Cherny's printing-press analogy, and how Cursor trained Composer with Federico and Dima.
Unsupervised Learning: episode 85, “Has AI Infra Stabilized,” with Swyx.

Related notes: the newtype AI-coding guide covers Huang Yihe's Chinese-language 2024–2026 practice. It complements these English-speaking builders' views on programming reasoning and sustained depth of thought. The Claude Code workflow note extends section 15's second-brain pattern.

History

June 5, 2026, version 1.0: created from complete follow-builders podcast digests in the coding-agents topic. Organized across episodes, highlighting four disagreements: Claude Code versus Codex, MCP versus CLI, harness difficulty and agents as infrastructure buyers.

September 26, 2026 addition: share execution infrastructure; design review and maintainer permissions separately

Evidence scope: locally archived, truncated interviews with Logan Kilpatrick (June 11 feed, through 07:18) and GitHub COO Kyle Daigle (June 17, through 08:01). This section is partial. Product details reflect statements made at interview time.

A harness can be shared across products to reduce development cost, while the final experience needs task-specific optimization. Logan estimates the common foundation at about 80%, distinguishing AI Studio coding from a persistent personal assistant. That is a spoken estimate, not an architecture acceptance threshold; the episode title alone does not establish that models will absorb every framework.

As generation becomes easier, review and contribution governance can become the bottleneck. Kyle describes GitHub legal and finance staff building small applications. More entry points bring submissions without automatically increasing maintainers' capacity. His sequence involves agent-assisted review, changes in response to comments, and merging only within permitted boundaries after CI and policy checks. Generated code, successful review and permission to merge are separate states.

Open source adds another layer: companies can constrain staff, whereas maintainers cannot necessarily control all outside contributors. Platforms need admission rules, contribution evidence and permissions that let communities choose their own arrangements rather than imposing one universal sponsorship system.

Questions for product managers: Which execution capabilities are shared? Which tasks need special treatment? Who can initiate, review and approve? How are failure and pending checks displayed? PR volume is not code quality. The interview's seventeen-million figure referred to agent-created PRs in March 2026; fourteen billion annual submissions was a forecast, not a result independently checked here.

September 26, 2026 full-text addition: design agents should support divergence, refinement and review

Evidence scope: the complete Matt Colyer/Figma interview, 00:00–33:52, read in full. The host disclosed owning Figma shares. Future user scale and proactive-agent designs are opinions or plans.

Chat is useful for initial intent but not necessarily for comparing alternatives side by side or positioning elements precisely. Matt uses divergence and convergence to explain the canvas: preserve alternatives, explore style, layout and accessibility, then cluster and choose. Divergent agents should create distinct directions, convergent agents support comparison, and direct manipulation lets designers refine. Some of this remains exploratory; a vision is not a shipped-feature list.

Built-in agents and external agents can be complementary. Design systems supply team components and standards; external agents connect with users' existing code environments. The interview's round trip is code page → editable canvas → design context → implementation branch and PR screenshots → human review. A reviewable implementation is a candidate deliverable, not automatic merge authorization.

Existing workflow context is valuable. The PMOS example combines organizational charts, Slack and project tools into onboarding information, making a manager's tacit relationships readable. Accessibility still needs task-appropriate authorization; it does not permit unrestricted use of all information.

As generation increases, review becomes harder. Screenshots, recordings and a second agent are possible interfaces, but people must understand what changed, why it meets the standard and what remains uncertain. Cheaper generation can make maintenance and acceptance more important. The guest bought more software after experiencing the maintenance burden of his own email agent. Scheduled summaries reduce checking effort, while email drafts still require approval one at a time. Proactivity does not imply unrestricted authority.

Check whether a design product preserves exploratory branches, obeys the design system, supports precise changes, shows implementation differences and separates generation from approval. Taste and curiosity help users challenge outputs rather than accept the first attractive answer.

September 26, 2026 full-text addition: remeasure review and maintenance as code generation accelerates

The AI Vibe Check panel discusses a migrating bottleneck: faster generation can leave teams constrained by understanding, review and upkeep. Measure total cost and elapsed time from requirement to stable delivery. Compare model-plus-environment results, rather than bare-model scores or lines of code.

At the same advertised price, output length, reasoning and retries can change the bill. Compare routing, smaller models and fallbacks on real tasks; rehearse which features degrade first under capacity constraints. The panel's API-outage, closed-model, acquisition and corporate-direction discussions are scenarios or unverified reports, not confirmed announcements. Convert forecasts into dependency exercises before using them to justify migration. Panel source.

September 26, 2026 full-text addition: data-cooperation boundaries; evaluate models and execution environments separately

An AI Vibe Check discussion archived on August 4, 2026 distinguishes ordinary API calls, domain customization, expert samples and shared failure evaluations. Each reveals different information to a supplier. The panel includes unverified company events and policy speculation. This section retains product-analysis questions rather than treating those stories as news facts.

Different depths of cooperation reveal different things. One call is not the same as an editing history, the version a user finally accepts or an expert evaluation dataset. Specify what enters the service, its permitted uses and which domain knowledge creates your advantage. This analysis does not assert that any supplier trains on customer data by default; actual terms need checking.

Value comes from additional information. User revisions, refusals and rare failures may add more information than repeated common successes. The speakers' argument for more data assumes equal quality. Quantity does not replace coverage or feedback quality.

Model selection. Test weights separately from tools, permissions, execution loops and evaluation. A model's results may change with its environment. Open weights do not establish license rights, deployment fitness or safety. A speaker explicitly says there was no evidence for a hypothesized covert supply-chain action; a risk discussion must not become a finding that a model class has a backdoor. Selection still depends on task correctness, actual cost, license text and required controls. Source discussion.

October 8, 2026 addition: track cloud reasoning and local execution separately

Based on remarks by Thariq and Boris Cherny in the October 6–7 Builders digests. This addition uses the captured digest text; it does not claim a fresh review of the original posts or complete podcast transcripts.

Sources for this addition

October 15, 2026 update: Validate a source-control migration together with review and operational dependencies

Evidence scope: Anthropic's public engineering post about Scion, read in full. Performance and staffing figures describe the vendor's internal experience, not benefits that ordinary teams can necessarily reproduce. This section focuses on migration and review boundaries.

Source: Anthropic: Redesigning source control.

Case: Use AI-generated tools to support learning and acceptance testing

October 21, 2026 addition: separate planning, isolated execution and independent challenge

Source links and related public notes

October 22, 2026: Match Code Understanding and Accountability to Consequences

AI lowers the cost of generating code without removing the consequences of maintenance, data leakage or incorrect deployment. A useful distinction in Shensi’s account of Guillermo Rauch’s remarks is between personal experimental tools and systems carrying other people’s data or critical operations. They require different depths of understanding and acceptance. The point is not that every user must rewrite all the code. Someone responsible for the consequences must be able to explain critical data flows, permission boundaries and failure behavior.

A practical project can list its worst plausible outcomes before choosing review depth. A prototype restricted to disposable test data in an isolated environment can use a lighter feedback loop. Once real user data, persistent writes or external services are involved, the team should identify critical paths, recovery behavior, permissions and an accountable handoff owner. This is the site’s suggested application; calling a project a small tool does not reduce its actual impact.

Deployment shares, migration times and forecasts of provably correct code have not been checked against the original interview in this batch. They are not treated as measured improvements or safety guarantees. Sandboxes, tests and proofs cover different properties, and passing a check supports only the conditions it covers. This complements independent challenger review by asking who bears the consequences and which parts must be explainable.

Source: Shensi’s Chinese account of an interview with Guillermo Rauch.