OpenAI Desktop App Secures 5 Million Users as Product Work Inverts

OpenAI桌面应用用户达500万，产品开发范式迎来反转 传统工程与设计壁垒的瓦解，使软件开发的决定性技能完全转向人工筛选与品味。 本次对话深入探讨了前沿AI模型如何通过将实现成本降至近乎为零来颠覆软件开发流程，使核心瓶颈从工程执行转向设计筛选与系统化整合。Ambrosino指出，Codex内部团队高度依赖兼具强自主性与高品位的人员，采用灵活的“区域联防”模式而非僵化的企业角色开展运作。他还分享了关于敏捷产品规划的实用洞见、围绕不断演进的模型能力进行原型构建的“烘焙”（bake）策略，并展望了未来愿景：AI将作为自主工作空间大本营，无缝协调Excel和Premiere Pro等专业原生软件的任务执行。 前沿 AI 模型将软件实现的边际成本推向接近零，彻底倒置了传统的产品开发流程；现代研发瓶颈已从功能开发的可行性转向对海量原型的筛选、框架构建与系统集成。 (2:30) AI 时代下“初始印记（primal mark）”现象极易误导团队，使利益相关者过度锚定在外观精致却缺乏战略一致性的原型上；因此“品味（taste）”演变为核心专业能力，要求产品人员具备严苛的系统性思维与筛选 AI 方案的甄别力。 (9:04) AI 模型在高阶设计能力上滞后于工程代码，原因在于设计缺乏客观代码编译式的反馈闭环，且大模型倾向于复现已知模式，难以处理深层代码抽象与创新结构。 (12:06) 团队逐步放弃耗时的传统研究与发散收敛设计流程，转向在真实生产环境或名为“baby codecs”的极简代码库中即时构建与高频测试。 (19:28) OpenAI Codex 团队内部展现出高度的职能交叉，并采用“区域联防（zone defense）”模式让产品经理最大化覆盖业务盲区，放弃僵化的自上而下长期规划，以敏捷且受品味驱动的机制推进项目。 (24:40)

Andrew Ambrosino argues that near-zero implementation costs driven by frontier AI models have inverted software development, shifting the primary product bottleneck from building features to exercising editorial taste, systems architecture, and fluid organizational coordination. Inverting the Traditional Product Development Cycle (2:33) Historically, software development prioritized upfront derisking through exhaustive product requirement documents (PRDs) and design mockups because implementation was the most resource-intensive phase. With frontier models dramatically lowering coding costs, implementation has become cheap and abundant. This ease of creation allows teams to pull fully functional software into the earliest stages of ideation, bypassing slow specification pipelines. However, this abundance introduces new operational friction. Tech companies increasingly encounter the '90-prototype problem,' where uncoordinated internal teams build parallel implementations of identical features. Furthermore, teams risk anchoring on the 'primal mark'—a production illusion where a surface-level prototype appears launch-ready despite lacking architectural integrity, commercial viability, or real user alignment. Taste and AI Limits in Design (9:04) Because code generation is largely commoditized, Ambrosino defines 'taste' as the critical modern product skill. Rather than superficial aesthetics, true taste represents systems thinking: evaluating dozens of model-generated variations, identifying reusable code abstractions, and deciding which directions warrant long-term architectural investment. Frontier models struggle with design far more than coding. Engineering benefits from structured, objective training loops where code either compiles or throws errors. Design, by contrast, relies on subjective human evaluation without automated grading. Furthermore, while models excel at predictable code patterns, compelling design requires structural novelty and shared systemic abstractions to avoid producing repetitive, generic user interfaces. Role Collapse and Organizational Zone Defense (24:40) The modern tech organization is undergoing functional overlap rather than a total elimination of titles. On the Codex team, designers routinely write code, product managers possess technical backgrounds, and individual contributors increasingly manage autonomous AI agents rather than typing syntax character by character. Ambrosino cautions against completely erasing specialized roles like product management, emphasizing that corporate depth and tested discipline frameworks remain essential. To prevent duplicated effort in fast-moving environments without rigid top-down roadmaps, the Codex team deploys a 'zone defense.' Product managers intentionally spread out to cover organizational gaps and empower product-minded engineers, ensuring autonomous execution without bureaucratic reviews. Roadmapping Around Model Capability Leaps (31:38) Pacing product roadmaps against frontier AI advancement renders distant planning ineffective. Ambrosino treats long-range, nine-month timelines with high detail as 'false precision,' reserving strict specificity only for immediate short-term sprints. Broader initiatives are sustained through a 'bake strategy,' where concepts are prototyped early and shelved until underlying model upgrades unlock their viability. According to Ambrosino, product success is dictated by underlying model intelligence rather than interface shape. For example, he claims that while the Codex desktop interface was identical between November and February, releasing in November would have failed entirely because the models at that time could not reliably support the user experience. Expanding Codex as an Operational Base (52:06) Initially built as a focused developer tool, Codex achieved unexpected internal adoption across non-technical groups at OpenAI, including finance, legal, and marketing, reaching 90% to 100% weekly company workforce penetration. Users favored its operational flexibility over specialized chat surfaces despite an interface that exposed technical elements like raw code blocks. OpenAI approaches the application not as an isolated container, but as a central digital home base that orchestrates external native software. Rather than rebuilding complex external environments inside the app, the tool relies on background integrations and autonomous actions—such as syncing with Microsoft Excel add-ins or writing, compiling, and installing a custom extension directly into Adobe Premiere Pro to manipulate project timelines. A persistent tension remains around interface complexity: while technical teams and early adopters readily coach open-ended models to automate multi-step workflows, Ambrosino notes that mainstream consumers are unlikely to configure autonomous systems from scratch, leaving open the challenge of translating customized user hacks into standardized product primitives.

OpenAI的Codex负责人Andrew Ambrosino指出，前沿AI模型将软件实现的边际成本推向接近零，彻底倒置了传统的软件开发流程；在此范式下，产品工作的瓶颈不再是功能构建本身，而是依靠高自主性人才的“品味”进行严密策划与系统集成，并根据底层模型能力的演进动态校准产品形态。 开发流程倒置与可交互原型泛滥 (2:33) 传统软件开发中，代码实现是成本最高、资源最密集的环节，团队通常依赖详尽的产品需求文档（PRD）和低保真草图来规避试错风险。前沿AI模型的普及使构建功能软件的边际成本骤降，任何人都能快速拉起可用功能。这种转变消除了前期的实现阻碍，但也引发了新混乱：多个缺乏协调的内部团队往往针对同一需求并行构建数十个互不相通的独立原型，导致资源分散与认知过载。 由于AI生成的原型往往具有极高的视觉保真度，极易造成“生产就绪”的假象，导致利益相关者误以为方案已成熟并催促上线，却忽视了其在战略目标或真实用户需求层面的脱节。Ambrosino认为，当前产品团队的核心挑战已不再是验证功能是否“做得出来”，而是精准判断何时该依靠严谨分析文档厘清逻辑，何时该借助极简代码库（如“baby codecs”）进行动态实验，以获取实质性的产品清晰度。 模型的生成局限与系统级“品味” (9:04) 尽管AI在代码编写上表现惊人，但在高阶产品设计领域仍面临结构性瓶颈。软件工程训练具备“代码能否编译运行”这一客观、闭环的反馈机制，而界面设计则高度主观，需要人在回路（human-in-the-loop）的审美裁决。此外，代码生成受益于遵循已知与可预测的代码模式，优秀设计却要求有意的随机性与结构创新；同时，顶尖设计需要深层抽象能力（如统一底层语义以驱动全局改版），而表面化模型往往只能机械修补孤立的UI组件。 因此，“品味”成为产品开发的关键分水岭，产品人的角色正从“构建者”转向“策展人”。Ambrosino强调，品味不仅指局部UI动效等视觉美学，更是严密的系统性思维。在面对AI瞬间生成的数十种方案变体时，具备品味的人才能够敏锐提炼核心结构，将碎片化组件整合进统一技术架构，并在无限生成的可能中精准甄别出真正具备长期投资价值的产品方向。 摆脱AGI狂热与“烘烤式”规划 (31:38) 在AI技术日新月异的环境下，传统的长期自上而下规划体系基本失效。Ambrosino指出，对9个月后的远期计划过度追求细节纯属“虚假精度”；团队转而采取短期计划高度详尽、远期规划保持模糊的策略。产品特性的成败主要取决于模型智能本身是否成熟，而非界面的视觉形态。例如，2月发布的Codex应用若提前至前一年11月发布必将遭遇失败，虽然其界面形态完全一致，决定性的变量仅仅是底层模型的推理水平。 基于此，团队践行“原型烘烤”策略：将未来一到两年的构想提前制作成原型，可行者立即上线，其余则搁置“烘烤”，待底层模型能力跃迁后再重新测试。这一过程也纠正了早期过度“沉迷AGI”（AGI pilled）的偏差——当时尝试推出全自动“委托后走开”的代理形态，但因模型能力不足而受挫；相反，以交互提问、伴随用户协同推进的形式，才真正匹配了现阶段的技术水位。 职能边界消融与“区域联防”机制 (21:11) AI工具正在加速技术团队内部的角色融合，Codex团队的设计师广泛涉足代码编写，产品经理也深度参与技术实现。然而，Ambrosino明确反对全面取消特定岗位的激进趋势。他指出，产品管理等专业职能沉淀了不可替代的实践框架，不能因代码编写门槛降低而废除岗位分工；工程师若轻视非技术工种，恰如认为会用Excel就能掌管企业财务一样不可取。 为了在保持组织弹性的同时避免资源重叠，团队推行“区域联防”模式：若两名产品经理在同一事项上过度重合，即被视为低效信号，团队会主动促成人员分散以覆盖组织空白点。在无限Token使得信息生成泛滥的时代，团队更看重具备自主行动力与严苛把关品味的人才。这类核心贡献者不再逐行敲击语法，而是以类似管理者的视角调度Agent并管理系统，从海量AI生成物中剔除“信息废料”，确保产品方向的高水准交付。 数字工作“母港”与跨软件协同 (56:14) Codex应用自推出以来，在OpenAI内部已渗透至近100%的员工，并扩展至文档草拟、硬核数据分析与邮件分拣等全场景，外部周活跃用户亦突破500万。令人意外的是，即便早期界面充斥着代码块与Git元数据，财务、法务和公关等非技术部门仍自发深度依赖该工具，甚至拒绝迁移至更为通用的知识工作应用，证明了其底层交互框架在深度垂直工作流中的吸引力。 团队将Codex定位为用户日常数字工作的“母港”，而非封闭的单一窗口。它不仅能通过自研浏览器与直接屏幕控制接管复杂网页交互，还能与本地专业软件无缝协同。例如在视频制作中，AI在遭遇API局限时，曾自主为Adobe Premiere Pro编写并安装扩展插件以操纵时间轴标记；在财务场景中亦可直连本地Excel。产品演进的核心正是通过打造底层原语，兼顾简易任务自动化与专业工具的无缝编排。 虽然Codex证明了AI作为工作流中枢的巨大潜力，但Ambrosino强调现有的聊天机器人交互范式仍有显著局限。OpenAI内部团队具备足够的技术兴趣与时间成本去通过对话反复训练AI，但普通大众用户很难有耐心从零配置复杂的工作流。如何在降低普通用户上手门槛的同时，继续满足硬核开发者对系统控制力与专业扩展的需求，并理顺与通用产品之间的生态定位，仍是该产品演进中悬而未决的现实挑战。

## Background 该视频由 Lenny's Podcast 频道于 2026 年 6 月 28 日发布在 YouTube 平台上。视频简介指出，本期节目专访了 OpenAI Codex 桌面端应用负责人 Andrew Ambrosino，深入探讨了 AI 如何颠覆传统的产品开发流程、为什么“品味”正在成为 AI 时代最核心的专业技能，以及 OpenAI 内部独特的团队架构与工作流自动化愿景。 ## TL;DR 在节目中，Andrew Ambrosino 揭示了 AI 时代产品开发的深刻变革，传统的“文档先导”模式正因实现成本骤降而倒置为“原型精选”流程。他深入拆解了包含系统思维与战略眼光的“品味”定义，指出当前 AI 在设计上由于缺乏文化新颖性与深度代码抽象而依然面临瓶颈。同时，他介绍了 Codex 团队打破传统职能边界的“均值化角色”模型与产品经理的“区域防守”战略，并强调在动态的 AI 浪潮中，从业者必须保持强大的个人能动性，执着于最终交付的结果而非固守特定的工具与流程。 ## Atmosphere & style 整个对话洋溢着一种硬核、前沿且充满思辨智慧的极客氛围。主持人 Lenny 与嘉宾 Andrew 之间的互动默契而有深度，既有关于产品方法论和 AI 技术底层逻辑的严肃剖析，又穿插着新手爸爸育儿趣事与内部 Slack 遭遇数千条痛骂的幽默调侃。听众能切身感受到一种置身于 AI 革命风暴中心的紧迫感与兴奋感，并在 Andrew 清醒、坦诚且富有自我认知的洞察中，体会到不断颠覆自我、重塑工作流的智力激荡。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=P3KDebPTUrw&t=0s) 在 OpenAI 内部，Codex 的普及率已达 90% 以上（全员每周使用），这促使传统产品开发流程发生“倒置”：实现成本极度低廉，真正稀缺和昂贵的是“品味”与筛选的过程。 - [06:32](https://www.youtube.com/watch?v=P3KDebPTUrw&t=392s) Andrew 反对“PRD 已死”的极端说法，强调在开发资源充沛的当下，核心能力在于根据目的为要表达的观点选择文档或原型等正确的沟通媒介。 - [06:32](https://www.youtube.com/watch?v=P3KDebPTUrw&t=392s) “初始印记（Primal Mark）”效应表明，过早抛出高保真原型会导致团队被其视觉完成度误导，从而过度锚定在一个尚未经过深度思考的错误方向上。 - [10:25](https://www.youtube.com/watch?v=P3KDebPTUrw&t=625s) 产品开发中的“品味”是系统性思维、战略眼光和信息呈现能力的综合体，而当前 AI 在设计上表现不佳是因为缺乏人类品味反馈闭环、设计更追求新颖性以及 AI 缺乏深度抽象能力。 - [15:45](https://www.youtube.com/watch?v=P3KDebPTUrw&t=945s) 传统设计流程之所以强调在动工前摸透问题，是因为过去工程实现成本高昂；但在 AI 时代，团队可以直接将完整的工程实现拉到最前端。 - [15:45](https://www.youtube.com/watch?v=P3KDebPTUrw&t=945s) 许多 AI 团队开始采用维护轻量化“婴儿版”代码库（Baby Version）的策略，以便极快地通过 AI 进行“氛围编码（Vibe Coding）”和创意试验。 - [21:35](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1295s) Codex 团队内部呈现出剧烈的岗位融合，形成了“均值化角色”模型，即个体的角色不再由传统职能围栏定义，而是取决于其投入时间的统计均值。 - [23:41](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1421s) 盲目取消“角色”和产品经理（PM）是危险的，因为许多职能是高度专业的并拥有最佳实践；AI 真正削弱的是工具壁垒，而非抹杀专业性。 - [27:22](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1642s) 在全员皆可编码的硬核团队中，产品经理应采取“区域防守（Zone Defense）”战略，充当品味输出者和过滤器，在公司覆盖面上散开并迅速补位。 - [31:38](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1898s) 在 AI 时代制定长期路线图是“伪精确”，短期计划越具体越好，而长期规划则必须保持模糊，因为功能成功与否核心取决于底层模型何时足够聪明。 - [35:16](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2116s) 超前构建当前无法正常运作的功能并等待模型跟上已成趋势，有些功能可能需要发布六次才能成功，而在这个过程中其形态甚至不需要发生任何改变。 - [39:17](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2357s) 行业风向已从有人监督的“驾驶 AI”演变为无人监督的自主软件开发，但在让开发完全进入自动驾驶时，当前 AI 模型普遍面临倾向于增加代码复杂性、不擅长删除代码的阵痛。 - [42:05](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2525s) Andrew 通过使用 Codex 编写自动化脚本和调度任务，实现了每日简报生成、PR 和 Slack 自动抓取等个人管理工作流的高度自动化。 - [46:52](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2812s) AI 的“电脑使用（computer use）”能力正激发用户构建专属系统，而团队需要不断在“满足个体独特工作方式”与“提炼出产品通用原语”之间进行权衡。 - [49:10](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2950s) Codex 的内置浏览器在路线上面临抉择：是仅作为供 AI 智能体快速控制、无延迟运行的后台工具，还是彻底成为一个面向用户的通用浏览器。 - [52:05](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3125s) Codex 最初定位为积极不友好的开发者工具，但因非技术部门疯狂自用，证明了开发者工具与通用知识工具之间没有鸿沟，未来方向是将其与 ChatGPT 融合成大本营（Home Base）。 - [57:20](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3440s) Codex 展现出通过现场自建插件来控制 Adobe Premiere Pro 等复杂专业工具的能力，证明了 AI 的破局方式可以无缝衔接，提示用户对待 AI 的野心不妨再大一点。 - [59:30](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3570s) OpenAI 内部推崇直接坦率的沟通文化，产品形态原型在内部经常遭遇包含数千条消息的痛骂毒打，这反向确保了最终发布产品的极高水准。 - [01:07:01](https://www.youtube.com/watch?v=P3KDebPTUrw&t=4021s) Andrew 建议新人在 AI 时代要“执着于交付的结果，而非固守精确的工作流程”，因为诸如 Figma 自动布局等硬执行技能极易被 AI 替代。 - [01:07:01](https://www.youtube.com/watch?v=P3KDebPTUrw&t=4021s) 在 AI 一线生存的人属于能够习惯频繁重塑工作流、高自我认知的极少数“自筛选”早期采用者，而频繁的重新学习对大众而言存在极高的门槛和挫败感。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=P3KDebPTUrw&t=0s) 重新审视产品的质量标准与产品团队的“倒置” 在 OpenAI 内部，Codex 的普及率已经达到了一个惊人的高度。几乎 100% 的员工（更准确地说是 90% 以上的全员，而不仅仅是工程师）每周都在使用 Codex。Andrew Ambrosino 作为 OpenAI 桌面端应用的主导者，曾在推文中表达过他的雄心壮志——要将 Codex 打造为“有史以来最出色的桌面应用，没有之一”。他认为，Codex 的质量门槛必须定得足够高，以至于用户在面临下一个任务时，会毫不犹豫、极其自然地首选打开它，就像如今人们习惯性地新建一个浏览器标签页一样。 这种高频且广泛的 AI 应用，正在深刻改变传统的产品开发模式，让现有的产品团队面临一种流程上的“倒置”。过去，行业长期遵循的研发流程是“研究—构思—可能做些原型—撰写文档”，即便告别了传统的瀑布流模式，其底层逻辑依然是“代码实现极其昂贵，因此必须在前期通过文档、研究和设计来对冲风险”。然而在 AI 时代，得益于近乎无限的 Token 供应，实现成本被压低到了极致。在 OpenAI 内部，每个人都极具行动力（Agentic）且想法涌现，这直接导致了开发流程的反转：实现不再是高昂的成本，真正稀缺和昂贵的是“品味（Taste）”与筛选（Curation）的过程。 - **Codex 内部数据**：在 OpenAI 内部，接近 100%（约 90% 以上）的员工每周都在使用 Codex，这涵盖了非工程职能的全体员工。 - **流程的倒置**：由于 AI 让代码实现（Implementation）变得极其廉价，传统通过文档和设计在前期对冲风险的模式被颠覆，产品开发变成了“先做一堆原型，再进行筛选与精简”的逆向过程。 --- ### [06:32](https://www.youtube.com/watch?v=P3KDebPTUrw&t=392s) PRD 真的死了吗？选择正确沟通媒介的品味 针对当下产品圈热议的“PRD（产品需求文档）已死，原型才是未来”的说法，Andrew Ambrosino 表达了鲜明的反对态度。他指出，正是因为在所有媒介上的实现成本都变得极为低廉，跳过思考直接做原型变得异常诱人，尤其是对于那些过去不懂代码、没时间写代码的非工程师而言。但硬币的另一面是，工程师们现在也很容易借助 AI 堆砌出大量“根本不值得一读”的冗长文档。 Andrew 强调，在开发资源充沛的当下，核心能力在于针对你想表达的观点**选择正确的媒介**。如果核心目的是在某个模糊的领域理清产品思路、达成共识，那么文档依然是最佳选择；如果目的是为了让人拿在手里实际体验、对某种交互模式进行压力测试，那它就应该是一个原型。 这里涉及到一个被称为“初始印记（Primal Mark）”的概念：当艺术家或设计师在画布上落下第一笔时，人们接下来的所有反应都会不自觉地受这一笔的牵引。如果团队在不成熟的时机抛出一个原型，哪怕它只是一个初步探索，但由于 AI 生成的外观太具有生产环境的完成度（Production-ready），人们就会产生“视觉上已经就绪”的错觉，从而过度锚定在这个错误的方向上。然而，它在底层逻辑上可能完全不符合研究走向、用户需求或商业利益。因此，决定何时用文档、何时用原型，这种判断力本身就是一种对“品味”的考验。 - **初始印记（Primal Mark）效应**：过早跳向高保真原型会导致团队被其视觉完成度误导，过度锚定在一个尚未经过深度思考、不符合长期业务或用户价值的探索性方案上。 - **媒介选择的品味**：优秀的品味不仅体现在美学上，还体现在知道如何呈现信息、选择最合适的沟通媒介（文档 vs. 原型）来达成特定阶段的产品目标。 --- ### [10:25](https://www.youtube.com/watch?v=P3KDebPTUrw&t=625s) 拆解“品味”：为何当前的顶级 AI 依然不懂设计 “品味”是一个经常被挂在嘴边却容易被误解的词。Andrew 引用了 Linear 产品负责人（Nan Yu）近期的一条推特以及对 Paul Graham 的讨论来以阐述：人们往往过度强调了品味中的“美学（Aesthetic）”成分，但事实上，Paul Graham 穿着工装短裤却显然拥有极高的品味。在产品开发中，真正的品味是一个综合体，它包含系统性思维（这个功能如何融入大系统）、战略眼光（我们走向何方、这属于哪个大主题）以及信息呈现的能力。它细致到能敏锐察觉出“某段交互动画的节奏太快，与它想要传达的语义不符”。 当谈到“为什么即便是目前最顶尖的前沿 AI 模型在设计上的表现依然不尽如人意”时，Andrew 从技术和文化的双重维度给出了他的深度见解。首先在技术和训练层面上，软件代码的好坏可以通过“能否编译成功”、“是否按预期运行”进行客观、低成本的自动化评测；而设计的好坏则极其依赖人类的品味作为反馈机制，建立这种训练闭环要繁琐、冗长得多。此外，各大 AI 实验室在历史投资上也更有动力优先提升模型的代码能力，因为“让模型写出正确的代码”能直接加速 AI 自身的研发飞轮，而设计能力在早期并不能带来这种直接的效率反哺。 除了这些可以随时间解决的工程问题，还有一些更深层的、AI 很难攻克的坎： 1. **设计的文化与时效性**：好设计具有极强的文化属性。比如去年几乎所有新网站都在抄袭 Linear 的设计风格。如果一个 AI 每次给出的都是完美的 Linear 风网站，这并不算解决了设计问题，因为设计对“新颖性（Novelty）”和一定程度的随机性要求极高。 2. **深度抽象的缺失**：真正的设计不止于视觉。如果公司明天要进行品牌重塑（Rebrand），肤浅的设计 AI 可能会选择去逐个更新 263 个组件的外观；而拥有深度抽象能力的人类设计师，则会在代码库和组件库之间建立高超的语义关联，通过底层的列表样式或语义抽象，实现牵一发而动全身的高效迭代。这种深度视觉设计与代码底层的互操作和抽象能力，是目前 AI 还远远无法企及的。 - **AI 设计的评级难题**：相比于代码有明确的编译和运行标准，设计质量的反馈机制极度依赖人类主观品味，导致训练闭环的构建成本高昂。 - **新颖性与代码抽象**：设计相比工程更追求反常态的“新颖性”；同时，高阶设计要求在视觉组件与底层代码库之间构建高度语义化的抽象层，而 AI 目前只能做到浅层的组件拼凑。 ### [15:45](https://www.youtube.com/watch?v=P3KDebPTUrw&t=945s) AI 时代的全新设计范式：“婴儿版”代码库与原型设计的演变 在谈到如何向用户传达复杂的交互模式时，Andrew Ambrosino 坦言，现有的技术抽象层依然让人觉得有些“触不可及”。回顾 OpenAI 的 Codex 团队历程，他们从去年 11 月开始开发这款桌面应用，起初并未全职使用，而现在它已经渗透到了团队工作的方方面面。这种转变不仅是工具层面的，更让团队在使用它时所做的事情发生了本质的变化。 Lenny 随后指出，Codex 应用刚推出时给人的感觉耳目一新，它既不是传统的终端（terminal），也不是标准的集成开发环境（IDE），而是一个能编写代码并直观展示代码的聊天界面。在这样的新范式下，AI 很难凭空创造出一套全新的编码逻辑，这恰恰证明了人类大脑在创新和独特性上的核心价值。Andrew 幽默地对此表示赞同：“让我们为人类的大脑欢呼吧，至少目前如此。” 随着话题转向设计的未来，Lenny 提到了 Anthropic（Claude 团队）设计负责人 Jenny Wen 先前表达的核心观点：在快速迭代的 AI 时代，“传统的设计流程已经死了”，因为事情发展得太快，根本没有时间按部就班地设计，只能一边建造一边调整。Andrew 对此有着深刻而独特的见解。他赞同 Jenny 关于“传统设计流程已死”的论断，并坦言自己在 AI 时代到来之前，就已经对那种教条、刻板的传统设计流程深恶痛绝。 --- > “传统的设计流程过于学术化。过去它之所以成立，是基于一个底层假设：**工程实现（implementation）的成本极其高昂，你往往只有一次推向市场的机会。** 因此，团队必须在动工前，耗费大量精力把整个问题空间和解决方案空间彻底摸透。” --- 在过去，像 Figma 和 Origami 这样的工具通过将“交互式原型”提前，加速了团队获取洞察的过程，甚至当时在管理层中还流行过一种迷思：“我们能不能只做一个原型，然后就指望它直接跑起来？”但在 AI 时代，真正的变革在于**团队能够将完整的“工程实现”直接拉到最前端**。 这种能力的提升也带来了一个有趣的冲突：当公司内部看到一个高度精致、看起来几乎可以立即面世的原创原型时，大家会兴奋地问：“我们现在能发布这个了吗？”但事实上，团队此时正处于最早期、最混乱的多人协作探索阶段（multiplayer exploration）。现在的设计流程已经不再局限于特定媒介或设计稿，而是直接在产品中进行调整、开展 A/B 测试，甚至直接把产品本身当成原型。 * **“婴儿版”代码库（Baby Version）：** 许多 AI 科技公司（如 Cursor、OpenAI 的 Codex）目前都采用了一种新策略——维护一个极度简化的、能模拟生产环境核心交互的轻量级代码库（如“Baby Codex”）。 * **氛围编码（Vibe Coding）：** 借助“婴儿版”代码库，团队可以极快地通过 AI 进行“氛围编码”，随时试验“如果侧边栏这样换”、“如果在这里加入群聊面板会怎样”等创意。 * **流程的意义：** Andrew 强调，如果一个人死守着过去的设计工具和日常细节，那他的设计生涯确实已经终结；但如果因此彻底抛弃设计流程中“明确当前所处阶段”的宏观框架，那将是极大的错误。在今天，这种宏观的掌舵和定位比以往任何时候都更加重要。 ### [21:35](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1295s) 角色解构与“均值化角色”理论 Andrew 的职业履历非常全面，横跨工程师、设计师、产品经理以及公司创始人。针对业界热议的“存在主义式角色崩溃（existential role collapse）”——即 AI 时代不再需要明确岗位划分的论调，Andrew 给出了来自一线团队的真实观察。他指出，虽然外界把“岗位消亡”炒得很热，但类似现象在其他行业并未普遍发生；不过在 Codex 团队内部，岗位的融合确实比其他组织更为剧烈。 这种深度融合很大程度上源于 Codex 本身的属性：它是一个面向工程师的硬核技术产品。因此，团队里的设计师天然“懂工程语言”，产品经理也具备深厚的技术背景并能亲自动手写代码。例如，团队里的 Alexander 甚至拥有计算机科学硕士学位。 为了描绘这种新型的协作模式，Andrew 提出了一个生动的**“均值化角色”模型**： <Image alt="以二维坐标散点图展现的‘均值化角色’模型，展示了设计、工程与产品工作高度重叠，个体通过其工作重心的统计均值（Dots Cluster）来定义自身角色" caption="均值化角色模型示例" src="image_agent_tag_1"/> 在 Codex 团队中，明确区分设计到哪里结束、工程从哪里开始的“职能围栏”正在消失。每个人都在一个巨大的交汇地带工作。如果你把团队里某位设计小哥一周内写代码、做产品规划和画 UI 的所有行为做成散点图，他的工作重心可能依然偏向设计那一侧。也就是说，**你现在的角色，取决于你把时间投入在哪里的“统计均值”。** 如果这段时间你主要在解决产品策略，那你现在就是个 PM。 这种高度灵活的组织形态也离不开全员的“吃狗粮（dogfooding）”机制。整个 Codex 应用的每一次迭代，都是被团队高强度的日常自用所驱动的。他们甚至会故意“不带目的性地劣化或不优化现有的内部流程”，逼迫自己必须通过把产品打磨得更好，来解决自己遇到的高难度工作痛点。这种状态虽然让人感到“极度不舒适”，但产品也因此在周复一周地发生着惊人的质变。 ### [23:41](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1421s) 为什么取消“角色”和“产品经理”是危险的 当 Lenny 提到 OpenAI 采用的“技术人员（Member of Technical Staff, MTS）”这一打破常规的统一职衔是否代表了未来全员“建设者（Builder）”的趋势时，Andrew 展现出了清醒的理性，并对盲目追赶潮流的极端做法提出了警告。 --- > “有些公司太喜欢走极端了，一听到外面吹什么风就立马跟风。**盲目取消‘角色’概念最危险的地方在于，它会危险地抹杀掉一个事实：许多职能是高度专业的，并且拥有经过时间检验的、可知的最佳实践（knowable best practices）。**” --- Andrew 强烈反对一些公司“彻底砍掉产品经理（PM）角色”的做法。他认为，产品管理是一门积累了大量实战经验、明确知道哪些路走不通的严谨学科。如果仅仅因为“我现在能用 AI 写几行代码了”，就狂妄地认为可以把整套产品科学抛之脑后，公司很快就会付出代价。 * **技能门槛依然存在：** 工程师往往容易陷入一种傲慢，觉得只有写代码才是硬技术，其他角色只是在“靠感觉混日子（just people vibing）”。Andrew 辛辣地反驳道：“这就好比你虽然会用 Excel，但不代表你能直接去财务部上班。” * **AI 真正削弱的是“工具壁垒”：** 现在的变革并不是消灭专业性，而是降低了跨界和学习的门槛。一个人不再需要因为记不住 TypeScript 的古怪语法或对汇编语言不感兴趣，就被剥夺当软件工程师的资格。过去很多角色存在严重的“看门人（gatekeeping）”现象——把“精通某个特定工具”等同于“擅长这个角色”。现在，这种由工具筑起的壁垒正在被 AI 彻底瓦解，人们可以更专注于思维模型和核心痛点。 * **管理层不会消失：** 无论是从任务的广度还是深度来看，指望每个人在同一时间包揽所有事情都是不现实的。分工与协作依然需要被组织和管理。 ### [27:22](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1642s) Codex 团队的架构与产品人的“区域防守”战略 当被问及 Codex 桌面应用团队的具体人员编制时，Andrew 给出了一个看似玩笑却充满哲理的回答：“在 10 个人到几千人之间。” 这个数字背后的逻辑是：从广义上看，整个 OpenAI 在模型底层研究、安全对齐（RLHF）、浏览器自动化能力（computer use）以及前端基础设施上的所有尖端成果，最终都会注入并体现在 Codex 这款产品中。但从狭义的日常业务来看，他们并不是一个臃肿的组织，核心团队由**两位数的工程师、大约折半的设计师以及极少数的产品经理**组成。整个团队的人才画像具有极高的同质性：**强自主性（Agency）与顶尖的品味（Taste）**，其中很大一部分人曾是创业公司的创始人，或者在大厂里担任过独当一面的核心角色。 在谈到产品经理在这样一个高精尖、全员皆可编码的团队中如何生存时，Andrew 提出了著名的**“区域防守（Zone Defense）”**模型。 根据 Andrew 和团队产品负责人 Alexander 的拆解，在全新的研发模式下，如果两个 PM 还在像过去那样紧密地盯着同一个细分功能，往往是一个糟糕的信号。在 top-down（自上而下）的长周期年度规划彻底失效的 AI 时代，产品经理的核心职责不再是写晦涩的 PRD，而是充当“品味输出者（taste makers）”，在信息和创意的无序丛林中扮演过滤器。 产品团队需要像足球或篮球比赛中的“区域防守”一样，在公司和业务覆盖面上完全散开，彼此之间保持恰当的空间，看清哪里有断层和核心漏勺（gaps），然后迅速补位。他们需要确保招聘进来的工程师本身就具备极强的“产品思维（product-minded）”，这样就不需要安排一整个团队去逐行审核代码是否符合产品逻辑。 同时，Andrew 重新定义了**个人贡献者（IC）与管理者（Management）**的关系。他认为管理并没有消失，而是两者的边界模糊了：现在的 IC 同样是管理者——你不再需要逐个字符地敲键盘敲出所有代码，你是在管理 token、管理 AI 智能体（agents）、管理交织在一起自动化运转的流水线。在无限算力、无限 token 带来的巨大信息噪音中，判断什么是真正的“信号”、什么是纯粹的“垃圾（slop）”，成为了最核心的壁垒。 <FollowUp label="想深入了解 Andrew 提到的 AI 时代“品味 (Taste)”作为专业技能的完整定义吗？" query="在 Lenny 对 Andrew Ambrosino 的采访中，Andrew 详细阐述了在 AI workplace 中“品味 (Taste)”为什么是最核心的专业能力？请结合前后的上下文为我详细拆解。"/> ### [31:38](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1898s) AI时代的动态规划与Codex的发布时机 当Lenny问及在瞬息万变、频繁交付的AI时代如何规划产品路线图时，Andrew Ambrosino坦言他的团队在规划上面临很大挑战，经常让周围的人感到挫败。他表示团队在规划上并没有什么颠覆性的“高招”，而是遵循一个朴素的原则：短期计划越具体越好，而9个月以后的长期规划则必须保持模糊。Andrew指出，在当前环境下给长远规划增加任何精确度都是一种“伪精确”，纯属浪费时间。虽然研究端（Research）可能有所不同，但在应用端（Applied Side）和产品端，任何在去年11月制定的计划，可能只在12月适用，之后便会完全脱轨。 在前一家公司时，Andrew就经历过这种因模型驱动功能而导致传统产品流程失效 my 的转变。当时的应对策略是：列出未来一两年内所有感兴趣的想法，进行原型设计，挑出当下可行的部分落地，其余的则“搁置孵化”。每当模型能力实现新的跨越，就把新模型替换进去重新测试。因为这些功能成功与否的核心前提在于模型是否“足够聪明”，而不是功能本身的外在形态。 * **Codex的生死时机**：Andrew分享了一个关于OpenAI Codex桌面的绝佳案例。他非常确信，如果在2025年11月就将2026年2月发布的Codex桌面版推向市场，该产品绝对会以失败告终。两者的产品形态完全一致，唯一的变量就是中间这几个月内模型能力的提升。仅仅几个月的时间差，就彻底改变了产品的命运。 --- ### [35:16](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2116s) “功能孵化”与避免过度的“AGI狂热” Lenny提到，先构建当前无法正常运作的功能、并等待模型跟上的“超前构建”模式，以及追求更宏大野心的态度，正成为行业的一种趋势。Andrew对此表示赞同，但他强调，团队必须清晰地认识到这属于设计流程的哪一个阶段。很多开发者有肌肉记忆，觉得“代码写完了就应该发布”，但实际上，现阶段的代码只是一个“资产（Artifact）”，用来在未来出现更强模型时进行测试。 这种迭代在OpenAI内部屡见不鲜。从最初在ChatGPT中尝试Operator，到Atlas内部的Agent，再到如今的Codex桌面版，其底层功能逻辑一脉相承。然而，正是因为注入了不同层级的智能，最终的产品结局完全不同。Andrew常告诫团队不要死板地认为“现在行不通就是个烂功能”，它可能只是“还没到时候”。 > "你可能需要把同一个功能发布六次它才能成功，而在这个过程中，它的形态甚至不需要发生任何改变。" 不过，Andrew也指出了另一个极端——在研究文化浓厚的团队中，大家往往追求终极的宏大愿景，陷入“AGI狂热（AGI-pilled）”。以最初的Codex Web版为例，其产品形态是让用户交付一个任务，模型离线完成后带回结果。这个方向在今天看来很合理，但在当时因为模型写代码的能力还不够强，导致这种高阶形态直接失败了。相反，后来出现的Cloud Code等工具完全基于本地，不承诺能全自动解决生活一切问题，而是通过不断向用户提问、协同打满补丁来推进，反而获得了巨大的成功。因为那才是当时模型能力所处的真实物理阶段。 --- ### [38:13](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2293s) 组织内部的颠覆与自下而上的探索 在面对已有产品时，团队很容易陷入修复小缺陷（Paper cuts）和进行局部优化的惯性中。Andrew认为这些优化非常必要，推特（X）上的用户也经常热心提醒他们去修复这些体验瑕疵。然而，为了防止团队在维护现有质量的同时丧失破坏性创新的能力，OpenAI极力推崇一种“自下而上（Bottoms-up）”的探索文化。 正如Codex桌面版在某种程度上颠覆了原有的ChatGPT体验一样，未来的某项新尝试也必然会颠覆现有的Codex。Andrew认为，同一个团队很难同时兼顾“颠覆性创新”与“维护现有产品质量”这两项完全不同的工作。因此，在组织架构上，必须设计出一种能够容纳并平衡这两种力量的流程。 --- ### [39:17](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2357s) 软件构建的新前沿：从手动编写到自主循环 谈到AI对产品构建方式的冲击，Lenny和Andrew总结了其惊人的发展轨迹：从人类手工敲击的“手艺人代码”，到AI编写100%的代码。Andrew对此提出了一个更有趣的视角——现在的编程更像是“驾驶（Steering）AI”。衡量AI编写代码比例的真正指标，不再是代码行的数量，而是“你必须纠正、引导模型多少次”。 面对Lenny关于“Agent和Loops（循环）是否是当前最前沿”的提问，Andrew幽默地回应：“Loops已经是上周的旧闻了，老兄（Loops are so last week, man）。”他表示，如果沿用去年的标准，现在团队100%的产品代码都已经是由AI编写的了。现在的行业风向已经从“有人监督（Supervised）”演变为“无人监督（Unsupervised）”的自主软件开发和安全测试工程。 * **模型的删除代码困境**：在探索让开发完全进入“自动驾驶”的过程中，Andrew指出了当前所有AI模型面临的一个共同阵痛：**它们倾向于增加代码的复杂性**。Andrew隔空向所有公司的研究团队喊话：“如果研究人员在听，请让模型更擅长删除代码（Please make the models better at deleting code）。” * **自主改进的距离**：目前要让模型完全自主运行——比如自动监听推特、Slack和邮件反馈，然后直接决定构建哪些功能、忽略哪些需求、如何抽象架构并自动优化App——团队正在努力实现，但客观上尚未达到完全放手让其“自行赚取十个亿”的水平。 --- ### [42:05](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2525s) Andrew如何用Codex实现自我工作自动化 Andrew打趣道，自己现在拥有世界上最好的工作。在开发Codex桌面版初期，他的个人目标非常纯粹：把这个工具打造得足够好，以至于他可以用Codex来编写Codex本身。这种极短的“吃狗粮（Dogfooding）”闭环让他能迅速发现痛点、修复痛点，从而解锁更多功能。 随着团队扩大，Andrew的角色从纯开发转向了产品规划与团队管理，他需要做更多的产品探索、追踪各项目的进度并纠正偏差。于是，他开始改变自己使用Codex的方式，让其匹配自己当下的管理工作。比如用它构建复杂的业务模型表格，或者对某一研究领域的历史沉淀进行深度盘点。 * **Vibe Coding与发布管理**：在2026年5月左右的一次更新中，Codex引入了应用内浏览器、计算机控制（Computer Use）以及资产创建（Artifact Creation）功能。Andrew透露，那是他们第一个真正意义上的“Vibe Coding”发布版本。当时他手里只有一个记录待办事项的Notion文档，他利用Codex编写自动化任务，自动去抓取各个Pull Request和Slack频道的更新，并实时更新产品状态追踪器。在当时，这让他感觉自己站在了产品发布管理的“刀锋边缘”，而如今这已成为OpenAI内部的日常。 * **日常工作流自动化**：现在Andrew每天早晨起床，会收到一份由Codex自动生成的每日简报。AI会从他加入的3000多个Slack频道中筛选出真正需要他关注的事项。他可以直接对AI说：“给我总结5个需要我回答的问题”，然后直接回复。 对于普通用户如何复刻这一极具吸引力的工作流，Andrew承认目前由于整个行业仍处于探索阶段，他自己是通过编写定制化的自动化脚本和调度任务来实现的。在运行的前几次，他需要像教练一样对AI进行微调（例如：“下次运行时多关注这个，淡化那个工作流”）。Lenny指出，许多人可能并没意识到，Codex桌面的表现其实非常类似于OpenClaw，用户只需通过自然语言对话，就能让它去调用Slack连接器（Connector）并设置复杂的日常自动化。Andrew最后总结道，虽然“不懂就问AI，让AI帮你配置”是目前产品的底线，但这绝不是终点，OpenAI正在全力探索更直观的产品形态，让非技术用户也能轻松驾驭。 ### [46:52](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2812s) 自动化个人工作流与产品原型的确立 Lenny 分享了他如何使用 OpenAI Codex 构建一个小程序来过滤收件箱中的垃圾邮件。在这个过程中，其中一个步骤需要进入繁琐且响应缓慢的 Google Cloud Console 组合控制台，去配置各种 Pub/Sub API 触发器。Lenny 灵机一动，直接尝试让 AI 代劳，对它说：“帮我把这个搞定。”随后，他见证了极具冲击力的一幕：Codex 直接接管了他的电脑，像人类一样开始在屏幕上点击并最终完成了配置。Andrew 笑称，AI 的态度就像是“哥们儿，我才不在乎你有没有直连的 API 插件，老子直接开点就完了”。 这种“电脑使用（computer use）”的能力，正激发着所有人去构建专属的个人系统。当被问及这些各不相同的个人工作流中哪些能沉淀为正式的产品功能时，Andrew 透露，团队一直在通过“切身体会”来界定各种连接器（如应用内浏览器、Chrome 插件与原生电脑控制）之间的决策边界。例如，许多人曾通过 Obsidian 或 Notion 来费尽心思地搭建自己的“记忆宫殿（mind palace）”，但 Andrew 认为用户不应该承担这种复杂的配置成本，于是通用性的“记忆（Memory）”功能便应运而生，成为了产品的一等公民（first-class experience）。团队需要不断在“满足个体独特工作方式”与“提炼出产品通用原语（primitives）”之间进行权衡，这高度依赖前面提到的审美与判断力。 --- ### [49:10](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2950s) 浏览器自动化的产品形态与全套 SaaS 的整合畅想 Lenny 提到此前 Dan Shipper 在播客中曾做出一个大胆预测：未来人们甚至不需要打开 Chrome 浏览器，而是直接在 Codex 内部去运行 Notion、Linear 和 Salesforce 等所有 SaaS 应用，让 AI 智能体全程辅助。Andrew 笑着回应说，Dan 每天都在 Slack 上发私信向他要各种功能。事实上，OpenAI 已经尝试过多种类似浏览器的交互形态，从早期的 Operator、ChatGPT 智能体模式（agent mode），到后来的 Atlas 浏览器、桌面端应用内浏览器，再到与 Chrome 互联的插件。 在迭代过程中，团队遭遇了大量既枯燥又棘手的工程和产品细节。最初 Codex 作为一个 Electron 应用，其内置浏览器非常简陋，仅定位为供开发者测试前端的工具。随后，团队切换到了驱动 Atlas 浏览器的 Owl 技术栈，引入了多标签页和企业级安全登录等功能。然而，核心的路线之争依然存在：这个内置浏览器应该仅仅作为一个供 AI 智能体快速控制、无延迟运行 Playwright 的后台工具，还是应该彻底成为一个面向用户的通用浏览器？如果是后者，键盘快捷键（keyboard shortcuts）的映射就会变成一场灾难——究竟是该遵循 VS Code、Chrome 还是 Linear 的肌肉记忆？这些细微的产品亚形态（subshapes）让产品设计的挑战呈指数级上升，因为 Codex 必须同时兼容毫无开发经验的普通人，以及像 Peter 这样试图用 OpenClaw 疯狂硬核编码的超级权力用户（power user）。 --- ### [52:05](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3125s) Codex 的愿景演变：从开发者工具到全能“大本营” 回顾发展历程，Codex 最初只是一个命令行界面（CLI），随后团队怀着极大的决心将其打造为一款桌面应用。它被精准定位为一个“尺寸合适”的界面：既像聊天机器人，又能展示代码，但最初并不允许用户直接编辑代码。在 2026 年 1 月和 2 月正式发布前，OpenAI 内部开展了大规模的“吃狗粮（dogfooding）”测试。当时，Codex 在工程和研究团队的日常工作流中已经表现出极高的内部 PMF（产品市场匹配度），大家爱不释手。 然而，更令人意想不到的转折发生了。公司内部的非技术部门——市场、公关、财务、法务等团队，竟然也开始疯狂使用 Codex。要知道，当时的 Codex 界面对非技术人员堪称“积极地不友好”（actively hostile），满屏幕都在蹦代码，还不断弹窗请求允许在终端运行 `rm -rf` 这种高危指令。为了改善他们的体验，OpenAI 曾尝试把 Codex 的能力抽离并融入到 ChatGPT 桌面端或 Atlas 浏览器中，试图分流这些非技术人群。结果却让人啼笑皆非：根本没有人愿意离开 Codex。这让 Andrew 意识到，开发者工具与通用知识工作工具之间并没有绝对的鸿沟。虽然财务人员不想看到 Git 仓库信息，但只要构建出正确的通用模型与可扩展原语（extensibility primitives），简单起步，随需求加深复杂度，Codex 就能横扫所有垂直领域。Lenny 总结道，既然 Codex 如此好玩好用，未来的方向显然是将其与 ChatGPT 融合成一个“大本营（home base）”。Andrew 坦言有人将其称为“超级应用（super app）”，导致他现在每天都要在公司听一百遍这个词。 - **工作流的协同模式**：Codex 作为一个工作大本营，不意味着所有操作都要被限制在它那一个矩形窗口里。 - **与专业工具深度绑定**：比如处理财务建模时，Codex 的内置表格不够用，它会直接与用户桌面上的 Microsoft Excel 插件通信，办完事后用户直接关闭 Excel 即可。 --- ### [57:20](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3440s) 视频编辑器的惊艳案例与“更具野心”的 AI 任务 为了展示这种极具张力的“连接器”模式，Andrew 分享了一个发生在录音室现场的真实故事。在 Codex 首次发布时，OpenAI 内部的开发者体验（DX）录像师 Brent 负责编辑宣传视频。Brent 出于好奇，尝试让 Codex 帮他剪辑视频。虽然 Codex 本身没有任何视频编辑的 UI 界面，但它迅速理解了 Brent 正在使用 Adobe Premiere Pro。 Codex 的破局方式令人震撼：起初它通过直接修改 Premiere Pro 的底层工程备份文件来实现剪辑，但发现有些高级操作无法完成。于是，Codex 现场“自己给自己编写了一个 Premiere Pro 插件”并自动安装了进去。通过这个量身定制的插件，Codex 得以直接向 Premiere Pro 发送指令，例如“请在应用内修改这个标记点（marker）”。这种 AI 自发通过编写扩展去控制复杂专业工具的硬核操作，彻底惊艳了在场所有人。Andrew 指出，这证明了 AI 与现有工具的交互可以通过“电脑使用”或“自建插件”实现无缝衔接，也向所有人传递了一个信号：对待 AI，你的胃口和野心不妨再大一点，尽管放手去让它尝试。 --- ### [59:30](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3570s) 失败角落：数万条 Slack 痛骂与 15 年的底层蛰伏 Lenny 将话题引向了播客的固定保留节目——“失败角落（Failure Corner）”。外界看 Andrew 的履历往往觉得他一路高歌猛进、全是高光，但 Andrew 却坦言，其实他有 10 到 15 年的时间一直在经历各种失败，甚至笑称“这可能是我职业生涯里第一次觉得自己没有在搞砸”。在加入 OpenAI 之前，他做过很久的创业公司创始人，由于身处重度监管的行业，最终只能把公司“拆成零件”贱卖变现，那几年对他而言是一场漫长而痛苦的苦役。随后他加入另一家做 AI 工具的初创公司，同样因为行业合规问题屡屡碰壁。 即便是在当下备受瞩目的 OpenAI，将 Codex 的能力与 ChatGPT 融合的过程中，团队也经历了无数次微观层面上的惨烈失败。Andrew 极为赞赏 OpenAI 内部那种毫无保留、直接坦率的沟通氛围。每次他们在 Slack 频道里丢出一个觉得“很酷”的产品形态原型，往往会瞬间引来一个包含 2000 多条消息的超级长帖，里面全是同事们毫不留情的大骂：“这玩意儿简直太蠢了！”、“这个设计烂透了！”。Andrew 调侃说，正是因为产品在内部被自己人狂虐、经历了一轮又一轮“2000 条痛骂”的毒打，最终发布给外部用户的产品才能保持如此高的水准。他的经历证明，在迎来真正的爆发之前，持续学习并熬过那些不顺遂的时光是每个从业者的必修课。 --- ### [01:01:50](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3710s) 闪电问答：硬核产品经理的育儿生活 节目进入最后的闪电问答环节，Lenny 抛出了第一个经典问题，询问 Andrew 平时最喜欢向别人推荐哪两三本书。已经成为年轻新手爸爸的 Andrew 瞬间从科技精英切换到了育儿模式，笑着大倒苦水，表示自己现在天天泡在孩子的世界里，脑子里全是童书。他脱口而出推荐了一本名为《咕噜牛》（*The Gruffalo*）的绘本，表示自己每天晚上都在给孩子们读这个。Lenny 听到后产生强烈共鸣并兴奋地惊呼，自己的孩子最近也彻底迷上了《咕噜牛》，家里甚至还做了一个专门的睡前奖励图表。 ### [01:02:13](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3733s) 睡前读物与打破常规的“能动性” 对话从轻松的育儿日常切入。Andrew Ambrosino 分享了自己陪孩子入睡的固定流程：穿睡衣、刷牙、读故事书，最后盖上小毯子。他提到目前正陪孩子看英国著名绘本《咕噜牛》（*The Gruffalo*），并觉得这类风格的童书很棒。Lenny 随即开玩笑地吐槽说，几乎每本儿童读物其实都隐喻着“死亡”或暴力——总有角色想把别的角色吃掉，或者密谋杀戮。Andrew 笑称确实如此，即便是那些孩子听起来不觉得暴力的词汇，也是为了制造剧情的起伏和刺激感。随后，Andrew 透露自己手头其实还积压了一大堆书单等着去读。 当被问及还有什么推荐的儿童读物时，Andrew 展现出了对童书领域的熟稔。他极力推荐了一本名为《大橙斑》（*The Big Orange Spot*）的经典旧书。他幽默地表示，如果你讨厌“业主工会”（HOA），那一定要读这本书。故事讲述了一个叫 Mr. Plumbeam 的人住在一条所有房子都一模一样的整洁街道上。一天，一只鸟把一大家大罐橙色油漆滴在了他的屋顶上，他索性决定打破常规、“彻底豁出去”。他买了更多的油漆、吊床甚至鳄鱼，把房子改造成了特立独行的模样。邻居们一开始为了所谓的房产价值和社区规范而群情激奋，但当他们一个个跑去和 Mr. Plumbeam 喝了一种“非常有说服力”的柠檬水并进行长谈后，邻居们竟然也受到启发，纷纷开始改造自己的房子（比如有人把房子改成了船的形状）。Lenny 从这个故事中敏锐地总结出了一个核心词——“能动性”（Agency），Andrew 强烈赞同，并直言：“你只需要动手去做就行了。” - Andrew 强烈推荐经典童书《大橙斑》（*The Big Orange Spot*），认为其传递了打破墨守成规的核心价值。 - 故事通过邻居们被说服并各自改造独特房子的情节，展现了极强的个人能动性与创造力。 --- ### [01:04:01](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3841s) 闪电提问：电视节目、最爱产品与职业三驾马车 进入播客的闪电问答环节，Andrew 提到最近在 Netflix 上重温了全新动画版的《神奇校车》（*The Magic School Bus*），新版中原先的 Frizzle 小姐变成了 Frizzle 教授，并由 Kate McKinnon 为主角 Frizzle 配音。当谈到看剧习惯时，Andrew 透露自己其实抽不出大块时间看电影，但他有个奇特的习惯：喜欢把一小时一集的 Netflix 剧集一集接一集地连着刷完。Lenny 打趣说，这种死活坐不住看一整部电影，却能连续看好几集一小时剧集的行为，确实有一种让人上瘾的魔力。 在聊到最近发现并喜爱的产品时，Andrew 打趣说天天都在发现自家的新产品，不过除了自家产品外，他此前最爱的软件产品绝对是 Linear。Lenny 顺势询问 OpenAI 团队是否也是理论上用 Linear 来做规划的，Andrew 报以会心一笑。随后，Lenny 询问 Andrew 是否有经常挂在嘴边的座右铭，Andrew 表示自己其实不是一个鸡汤座右铭型的人，但往往是身边共事的人总会提醒他，他其实经常重复说一些连他自己都没意识到的金句。 最后，Lenny 抛出了一个极具火药味的问题：“你当过产品经理（PM）、设计师，也当过工程师。在这三驾马车中，哪一个角色最难当？” Andrew 坦言这三个角色截然不同，对一个人来说是坎的技能，对另一个人来说可能轻而易举。现在科技界关于“设计师是否完蛋”、“设计师要不要写代码”、“PM 是不是凉了”、“工程师是不是不需要了因为 PM 都能写代码”的争论铺天盖地。但 Andrew 认为，当下正在发生的职能融合与流动性是非常令人振奋的，尤其是对于那些拥有极强能动性、只想把事情做成的人来说。虽然有些核心特质不应消失，但人们应该找到真正值得投入的事物，并主动去摸索解决之道。 - Andrew 个人非常推崇项目管理工具 Linear，在投身目前的 AI 核心项目之前，这是他最爱的软件产品。 - 面对“PM、设计师、工程师谁最难”的世纪难题，Andrew 认为 AI 正在打破这些职能的绝对边界，带来令人兴奋的 Fluidity（流动性）。 --- ### [01:07:01](https://www.youtube.com/watch?v=P3KDebPTUrw&t=4021s) 花絮与幕后：与 AI 共生的极度自我认知 在节目尾声的幕后闲聊（BTS）中，Lenny 提到了他们的播客制作人 Brent 利用 Codex 在 Premiere Pro 里做视频剪辑扩展的趣事。Lenny 透露，自己其实也在视频剪辑中尝试使用过这类 AI 工具，用来做一些简单的粗剪工作，比如“把这段对话里的三次停顿切掉”。Codex 能够完美理解这种指令。Andrew 总结道，现在几乎所有的工作流演变都始于这样的故事：产品最初并非为此专门设计，它只是一个能写代码的空白聊天框，理论上它无所不能，但关键在于“人们能用它做出什么有用的东西”。这需要用户对项目保持极大的好奇心，拥有明确的预期目标，并把 Codex 当作一个试错的平台——反正成本极低，只需要消耗几个 Token。Lenny 也开玩笑说，当然，如果你在 OpenAI 工作，那连这点 Token 成本的顾虑都更少了。 Andrew 接着分享了他对职业发展的深度思考。他经常被问到新人在 AI 时代需要什么技能，或者如何看待“极具天赋的应届生（Cracked New Grad）”。他给出的唯一一条核心建议是：“千万不要固守于你现有的、精确的工作流程。你应该执着于那些只有你才能交付的‘结果’，然后为了这个结果不断去改变和尝试新的流程。” 如果你只是自诩为“全世界最懂 Figma 自动布局（Auto Layout）的人”，那毫无疑问 AI 很快就会超越你。Lenny 赞叹 Andrew 总是能随口说出极具洞察力的观点，并感叹“要在 AI 时代获得成功，所需的自我认知（Self-awareness）高得惊人”。 Andrew 对此表示赞同，但也流露出了一丝清醒的担忧。他表示自己很少断言未来一定会怎样，因为像他的父母这样虽然思想开明、专注事业的人，可能根本无法适应这种剧烈的行业变革。现在能在 OpenAI 这种环境里留下来的人，都是一种“自筛选（Self-selecting）”的结果——他们是那群“总是能自己搞清楚下一步该做什么”的人，而世界上大部分普通人其实并不会成为这种超前早期采用者（Early Adopter），毕竟“一直被逼着去重新学习新事物，真的很让人沮丧”。Andrew 坦言自己极其讨厌重复，这也是他不擅长面对媒体或当一个合格创始人的原因（因为创始人需要充当“首席重复官”）。但他非常享受每天都能用截然不同的方式来完成工作的状态，Lenny 总结道：“那你简直是为你的工作找到了完美的产品市场契合度（Product Market Fit）。” Andrew 笑着承认，这也是他无法在薪资或职位上妥协谈判的原因，因为他根本不想换别的任何工作。 - 面对 AI 冲击，Andrew 建议从业者要“执着于结果，而非固守流程”，像 Figma Auto Layout 这样的硬执行技能极易被 AI 替代。 - Andrew 认为能在当下 AI 一线活下来的人属于极少数能够“自我筛选”并习惯频繁重塑工作流的早期采用者，而频繁的学习对大众而言存在极高的门槛。 ## Notable quotes > [00:00](https://www.youtube.com/watch?v=P3KDebPTUrw&t=0s) 代码实现极其昂贵，因此必须在前期通过文档、研究和设计来对冲风险。 — Andrew Ambrosino > [15:45](https://www.youtube.com/watch?v=P3KDebPTUrw&t=945s) 传统的设计流程过于学术化。过去它之所以成立，是基于一个底层假设：工程实现（implementation）的成本极其高昂，你往往只有一次推向市场的机会。因此，团队必须在动工前，耗费大量精力把整个问题空间和解决方案空间彻底摸透。 — Andrew Ambrosino > [15:45](https://www.youtube.com/watch?v=P3KDebPTUrw&t=945s) 让我们为人类的大脑欢呼吧，至少目前如此。 — Andrew Ambrosino > [21:35](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1295s) 你现在的角色，取决于你把时间投入在哪里的“统计均值”。 — Andrew Ambrosino > [23:41](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1421s) 有些公司太喜欢走极端了，一听到外面吹什么风就立马跟风。盲目取消‘角色’概念最危险的地方在于，它会危险地抹杀掉一个事实：许多职能是高度专业的，并且拥有经过时间检验的、可知的最佳实践（knowable best practices）。 — Andrew Ambrosino > [23:41](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1421s) 这就好比你虽然会用 Excel，但不代表你能直接去财务部上班。 — Andrew Ambrosino > [27:22](https://www.youtube.com/watch?v=P3KDebPTUrw&t=1642s) 在无限算力、无限 token 带来的巨大信息噪音中，判断什么是真正的“信号”、什么是纯粹的“垃圾（slop）”，成为了最核心的壁垒。 — Andrew Ambrosino > [35:16](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2116s) 你可能需要把同一个功能发布六次它才能成功，而在这个过程中，它的形态甚至不需要发生任何改变。 — Andrew Ambrosino > [39:17](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2357s) 如果研究人员在听，请让模型更擅长删除代码（Please make the models better at deleting code）。 — Andrew Ambrosino > [46:52](https://www.youtube.com/watch?v=P3KDebPTUrw&t=2812s) 哥们儿，我才不在乎你有没有直连的 API 插件，老子直接开点就完了 — OpenAI Codex > [59:30](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3570s) 这可能是我职业生涯里第一次觉得自己没有在搞砸 — Andrew Ambrosino > [59:30](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3570s) 这玩意儿简直太蠢了！、这个设计烂透了！ — OpenAI 员工 > [01:02:13](https://www.youtube.com/watch?v=P3KDebPTUrw&t=3733s) 你只需要动手去做就行了。 — Andrew Ambrosino > [01:07:01](https://www.youtube.com/watch?v=P3KDebPTUrw&t=4021s) 千万不要固守于你现有的、精确的工作流程。你应该执着于那些只有你才能交付的‘结果’，然后为了这个结果不断去改变和尝试新的流程。 — Andrew Ambrosino > [01:07:01](https://www.youtube.com/watch?v=P3KDebPTUrw&t=4021s) 一直被逼着去重新学习新事物，真的很让人沮丧。 — Andrew Ambrosino ## Mentioned OpenAI, Codex, Andrew Ambrosino, Lenny, Lenny's Podcast, Linear, Nan Yu, Paul Graham, Figma, Origami, Cursor, Jenny Wen, Anthropic, Claude, Alexander, WorkOS, Mercury, ChatGPT, Operator, Atlas, Cloud Code, Slack, Notion, OpenClaw, Google Cloud Console, Obsidian, Dan Shipper, Salesforce, Chrome, Playwright, VS Code, Peter, Brent, Adobe Premiere Pro, Netflix, The Gruffalo, The Big Orange Spot, Mr. Plumbeam, Kate McKinnon [Source](https://www.youtube.com/watch?v=P3KDebPTUrw)

[0:00] Andrew Ambrosino: 代码实现极其昂贵，因此必须在前期通过文档、研究和设计来对冲风险。 [15:45] Andrew Ambrosino: 传统的设计流程过于学术化。过去它之所以成立，是基于一个底层假设：工程实现（implementation）的成本极其高昂，你往往只有一次推向市场的机会。因此，团队必须在动工前，耗费大量精力把整个问题空间和解决方案空间彻底摸透。 [15:45] Andrew Ambrosino: 让我们为人类的大脑欢呼吧，至少目前如此。 [21:35] Andrew Ambrosino: 你现在的角色，取决于你把时间投入在哪里的“统计均值”。 [23:41] Andrew Ambrosino: 有些公司太喜欢走极端了，一听到外面吹什么风就立马跟风。盲目取消‘角色’概念最危险的地方在于，它会危险地抹杀掉一个事实：许多职能是高度专业的，并且拥有经过时间检验的、可知的最佳实践（knowable best practices）。 [23:41] Andrew Ambrosino: 这就好比你虽然会用 Excel，但不代表你能直接去财务部上班。 [27:22] Andrew Ambrosino: 在无限算力、无限 token 带来的巨大信息噪音中，判断什么是真正的“信号”、什么是纯粹的“垃圾（slop）”，成为了最核心的壁垒。 [35:16] Andrew Ambrosino: 你可能需要把同一个功能发布六次它才能成功，而在这个过程中，它的形态甚至不需要发生任何改变。 [39:17] Andrew Ambrosino: 如果研究人员在听，请让模型更擅长删除代码（Please make the models better at deleting code）。 [46:52] OpenAI Codex: 哥们儿，我才不在乎你有没有直连的 API 插件，老子直接开点就完了 [59:30] Andrew Ambrosino: 这可能是我职业生涯里第一次觉得自己没有在搞砸 [59:30] OpenAI 员工: 这玩意儿简直太蠢了！、这个设计烂透了！ [62:13] Andrew Ambrosino: 你只需要动手去做就行了。 [67:01] Andrew Ambrosino: 千万不要固守于你现有的、精确的工作流程。你应该执着于那些只有你才能交付的‘结果’，然后为了这个结果不断去改变和尝试新的流程。 [67:01] Andrew Ambrosino: 一直被逼着去重新学习新事物，真的很让人沮丧。

Andrew Ambrosino: the best desktop app that has ever existed, full stop. [9:04] Andrew Ambrosino: People overemphasize the aesthetic part of what taste means... Paul Graham clearly has great taste and wears cargo shorts... We got to tease out what taste means a little bit. [15:45] Andrew Ambrosino: give it up for the human brain—for now [16:51] Jenny Wen: The design process is dead. Here’s what’s replacing it. [21:11] Andrew Ambrosino: somewhere between 10 and a few thousand. [24:40] Andrew Ambrosino: this isn't your lane [31:38] Andrew Ambrosino: false precision [35:16] Andrew Ambrosino: too AGI pilled for the moment. [42:05] Andrew Ambrosino: I think I have the best job in the world right now. [42:05] Andrew Ambrosino: The least that we can do is make it so that if you don't know how to do something in the app, they can just ask it... I don't think that's enough, but I think that's the least we can do. [46:52] Lenny Rachitsky: I don't care if you don't have a connector, man. I'll just start clicking. [52:06] Andrew Ambrosino: nobody would leave the Codex app for the apps that were allegedly for these other personas. [52:06] Andrew Ambrosino: super app [59:18] Andrew Ambrosino: perhaps the first time I've not felt like I was failing. [62:52] Andrew Ambrosino: you can just do things. [65:24] Andrew Ambrosino: everybody's cooked and everybody's so back [67:01] Andrew Ambrosino: repeater in chief.

[0:00] 90% of people at Opening Eye use Codex. [0:03] Not 90% of engineers. That's 90% of the [0:05] entire company. [0:06] >> Yeah. This tweet the other day where you [0:07] said that you intend to make Codex the [0:10] best desktop app that has ever existed. [0:12] >> Yeah. The quality bar for Codex had to [0:14] be so high that there was never like a [0:17] hesitation that you have opening this [0:19] app to do the next thing that this was [0:20] your natural choice. Just like people [0:22] have kind of come to open a browser tab, [0:24] right? [0:24] >> That's true. I know there's numbers [0:26] constantly coming out about the records [0:27] you guys are setting for usage. [0:28] >> I don't know. Like we'll see. A lot of [0:30] people seem to like the app. [0:31] >> Why do you think AI and the top frontier [0:34] models are just not good at design? [0:36] >> I think design's a little bit harder to [0:37] grade because the human aspect of taste [0:39] is like part of the feedback mechanism [0:42] you need. That is still feeling a little [0:44] bit out of reach with the current [0:45] technology. [0:46] >> What does the shape of product team look [0:47] like now versus a couple years ago? [0:50] >> Everybody at OpenAI is very agentic, has [0:52] great ideas, and so everybody's building [0:54] everything. And it's not that people are [0:55] doing fundamentally different roles or [0:57] focusing on different things. It's that [0:59] it's backwards. The implementation is [1:00] actually not the expensive part anymore. [1:02] It's dare I say taste. [1:05] >> You feel like there's this collapse [1:06] coming where everyone's everything and [1:07] that's just the future or do you think [1:08] we're going to continue to be mostly [1:10] divided up? [1:11] >> There are some things that I'm afraid [1:12] of. I've heard a lot of companies be [1:13] like we're getting rid of the product [1:14] role and everybody's just going to be a [1:16] builder and then what happens is [1:22] >> today my guest is Andrew Ambercino, [1:24] product and engineering lead for the [1:25] Codex app at OpenAI. Codeex is quickly [1:28] becoming people's go-to app for building [1:30] products and also for non-product work [1:33] like organizing files in your computer, [1:35] drafting documents, doing data analysis, [1:37] reading your emails, and a lot more. If [1:39] you stick around for the end of this [1:41] episode, we actually have a little clip [1:42] from after we stopped recording where [1:44] the producer in the room started talking [1:46] about how he uses Codeex in his editing [1:48] work. Since this January, Codeex usage [1:51] has grown 6x. They currently have over 5 [1:54] million weekly active users. I suspect [1:56] this number is quickly going to be out [1:58] of date. Internally at OpenAI, nearly [2:00] 100% of their employees use Codeex [2:03] weekly. And that is not just the [2:05] engineers. Andrew is a designer turned [2:08] engineer turned product manager who is [2:10] building the app that more and more of [2:12] the world is using to build their own [2:14] products. Before we get into it, don't [2:16] forget to check out lenny's [2:17] productpass.com [2:18] for a year free of the hottest and most [2:21] well-crafted AI products in the world [2:23] available exclusively to Lenny's [2:25] newsletter subscribers. With that, I [2:27] bring you Andrew Ambersino. [2:33] Andrew, thank you so much for being [2:35] here. Welcome to the podcast. [2:37] >> Thank you for having this is a rare [2:39] in-person podcast. I rarely do this kind [2:41] of thing. We'll see how it goes. [2:42] >> We'll see. [2:42] >> We'll see people like these more. When [2:44] we were preparing for this chat, I asked [2:45] you what's the biggest thing you want [2:47] people to get out of this conversation [2:49] and you said that it was how AI is [2:51] changing the shape of product work. [2:52] You're working at maybe the most [2:54] bleeding edge AI pill software team [2:57] there is. So you have a really [2:59] interesting lens into where things are [3:00] heading, where other teams are going to [3:02] be and in a year or two or or more. What [3:05] does the shape of product team look like [3:07] now versus a couple years ago? One of [3:09] the the hardest things to do right now [3:12] as a leader [3:15] building these products is just sort of [3:17] the inversion of the process in my mind [3:19] which I think a lot of people have [3:20] talked about which is that anybody can [3:23] build anything right like I I generally [3:26] believe now that starting from scratch [3:29] if you talk to these models ours anybody [3:32] else's really um [3:35] you can stand up whatever feature you [3:37] want right And that's not necessarily a [3:40] hard part of software, but that's like [3:42] that's really cool. And I think that has [3:45] created an environment where [3:48] people are making all of this, right? [3:50] You give people unlimited tokens. [3:52] Everybody at OpenI, OpenAI is is very [3:54] agentic, has great ideas, and so [3:56] everybody's building everything. Whereas [3:58] I think, you know, you look back at [4:00] product process that we've all run for a [4:02] long time, and it's been a little bit [4:05] opposite, right? It's been kind of [4:07] research ideation maybe there was some [4:09] prototyping but it was you know even [4:13] when we got past waterfall it was still [4:15] kind of flavored of like [4:18] the implementation is expensive and so [4:20] you what you want to do is you want to [4:21] derisk all implementation up front [4:24] through documents through research [4:26] through prototypes because prototypes [4:27] and designs are cheaper was kind of the [4:30] the assumption there uh and that's [4:32] changed that's like totally changed and [4:35] right now I'm sure there are 90 [4:37] different explorations for there's this [4:41] feature that we desperately need to do [4:43] that I'm sure there are 90 different [4:45] uncoordinated teams like implementing [4:47] and trying, right? [4:48] >> Um, [4:50] >> so I guess the short answer is like it's [4:51] it's backwards and it's not that people [4:53] are doing fundamentally different roles [4:55] or focusing on different things or that [4:57] even skill sets have vanished or that [4:59] roles have just disappeared. It's that [5:01] it's backwards, right? The [5:02] implementation is actually not the [5:03] expensive part anymore. It's dare I say [5:06] taste. Um but it's the curation process. [5:08] It's like of those 90 attempts like [5:11] what's good about these? What should we [5:12] fold into other aspects of this? Right? [5:15] How should we frame this? Should it be [5:16] part of this other feature? Right? How [5:18] many segments should be in the toggle? [5:20] Um you know all of those things. This [5:23] episode is brought to you by our [5:24] season's presenting sponsor, WorkOS. [5:27] What do OpenAI, Anthropic, Cursor, [5:30] Versell, Replet, Sierra, Clay, and [5:33] hundreds of other winning companies all [5:34] have in common? They are all powered by [5:37] work OS. If you're building a product [5:39] for the enterprise, you've felt the pain [5:40] of integrating single signon, skim, [5:43] arback, audit, logs, and other features [5:45] required by large companies. Work OS [5:48] turns those deal blockers into drop-in [5:50] APIs with a modern developer platform [5:52] built specifically for B2B SAS. [5:55] Literally every startup that I'm an [5:57] investor in that starts to expand up [5:59] market ends up working with Work OS. And [6:01] that's because they are the best. [6:03] Whether you are seedstage startup trying [6:04] to land your first enterprise customer [6:06] or a unicorn expanding globally, work OS [6:09] is the fastest path to becoming [6:10] enterprise ready and unblocking growth. [6:13] It's essentially Stripe for enterprise [6:15] features. Visit works.com to get started [6:18] or just hit up their Slack where they [6:19] have actual engineers waiting to answer [6:21] your questions. Work OS allows you to [6:24] build faster with delightful APIs, [6:26] comprehensive docs, and a smooth [6:27] developer experience. Go to works.com to [6:30] make your app enterprise ready today. [6:33] Taste such a such a buzz word. I want to [6:35] come back to that. Uh this idea of 90 [6:37] prototypes. So interesting. So just to [6:39] make sure I understand that. So there's [6:41] an idea out there floating around [6:43] OpenAI. What people used to do is write [6:45] docs. Yeah. Here's what we're going to [6:47] build. Here's the feature. Here's the [6:48] strategies. P. Today what you're [6:50] describing which makes all the sense is [6:52] people just create a prototype and what [6:54] you're saying is people across the [6:55] company have kind of similar ideas and [6:57] now instead of a dock they create their [6:59] little prototype and that leads to kind [7:01] of 90 different things people can look [7:02] at and maybe pick here's a direction we [7:04] want to go down. Is that idea? [7:06] >> There's a lot of this um and you know [7:09] it's not just happening here like you've [7:11] seen many product leaders say PRDS are [7:14] dead prototypes are in and I actually [7:16] don't believe this at all. I think that [7:18] one of the interesting things that is [7:20] happening right now is that because [7:23] implementation has gotten so cheap [7:26] across every medium. It's very tempting [7:29] to jump straight to a prototype, [7:32] especially if you're not an engineer, [7:34] right? Especially if you've never been [7:35] able to write code or never been [7:37] interested or never had the time. It's [7:40] really tempting to say like PRDs are [7:42] dead. Let me just show you what I mean. [7:44] Right? What I've also noticed though is [7:47] that for engineers, it's really tempting [7:49] to write a lot of documents, a lot of [7:51] documents that are not worth reading. [7:53] Um, this is no shade on people writing [7:56] documents. It's that if implementation [7:58] is abundant, [7:59] then it's really important to pick the [8:01] right format for the point you're trying [8:04] to make. If that point is product [8:08] clarity around a vague area, then it [8:12] might actually be a document. If what [8:14] you're trying to do is get something in [8:16] people's hands to try out and to stress [8:18] test an interaction pattern, it's a [8:20] prototype. But I think like this is kind [8:23] of the funny thing now, which is that [8:26] like it's really important to pick the [8:28] medium. [8:28] >> There's this uh term that a podcast [8:31] guest shared that I think about when you [8:32] say this uh which is it's called the [8:34] primal mark. when a designer or a [8:36] painter or an artist just creates the [8:38] first mark on on a painting or a piece [8:40] of art, [8:42] that mark is what you start to respond [8:43] to. And so everything kind of trickles [8:46] down from that first mark you make. And [8:48] what I'm hearing you saying is sometimes [8:49] the prototype is the wrong first thing [8:51] to do because then you're just [8:52] responding to this prototype versus a [8:55] different idea versus a bigger idea. So [8:56] I love hearing this. So like everyone's [8:58] just like, "Okay, forget it. No more [8:59] writing, no more docs, no more [9:00] purviews." You're saying they're [9:01] actually still useful for specific use [9:03] cases. [9:04] >> Yeah. I I I think too there's this part [9:06] of the previous world was that the [9:09] medium implied it had baked in a lot of [9:14] a lot of signal around where in the [9:16] process something was right. So if [9:18] you're seeing something that feels like [9:20] the app in production that means that [9:24] it's late in the process that [9:26] assumptions have been derisked that you [9:28] know design is looked at this that this [9:29] is a good business goal right and now [9:32] those things are sort of divorced right [9:34] and the reason it was that way is [9:35] because it was hard to get resources to [9:37] build the thing until it was properly [9:38] derised and now that's like just out the [9:40] window right and so I think it's really [9:43] important to start saying look we can [9:45] have prototypes we can have documents Is [9:48] it are we clear around what this is [9:51] doing? Right? Because to your point, you [9:52] do not want to over anchor on this thing [9:54] that was meant to be an exploration, but [9:56] now it looks so production ready that [9:59] like, oh, visually it's ready for prod, [10:01] but it's not actually the right model of [10:03] of where the research is going or what [10:05] users are asking for or what's right for [10:07] the business, right? Not to overdo the [10:09] taste thing, but it's like it's once [10:11] again it's like the taste to know like [10:14] what to work on, how to present that [10:16] information, like how to achieve the [10:18] goals, what medium to use is emerging as [10:22] like the most important thing to do. And [10:24] that's it. That's that's in every field. [10:26] What is taste when you talk about good [10:28] taste? Is it is it what you describe [10:31] deciding here's the thing we're going to [10:32] invest in? Is it also once you have a [10:35] thing, is this right? Is this the thing [10:37] to ship? talk about when you think about [10:39] what is good taste, good judgment, what [10:40] is what does that concretely? Cuz people [10:42] hear this word, they're like, "Oh, I [10:43] have good taste. I know it. What does it [10:45] look like in practice?" [10:46] >> Yeah. Um, it's funny. There was a tweet [10:50] I'm too online. There there was a tweet, [10:51] I think it was yesterday from the head [10:53] of product at linear. I might be getting [10:54] that wrong. Sorry to anybody who said [10:58] people overemphasize the aesthetic part [11:00] of what taste means. and they used um [11:03] Paul Graham's Craig, but they used him [11:05] as an example saying Paul Graham clearly [11:07] has great taste and wears cargo shorts, [11:09] right? Like, you know, we gota we got to [11:11] like tease out what taste means a little [11:13] bit. Um and and there's a lot of nuance [11:15] here. I think it's all of the above to [11:17] to what you mentioned. It's it's the [11:19] like there is an aesthetic part to it. [11:22] Um but there's also a a systems thinking [11:25] part of it. Like how does this fit in [11:26] the system? There's a where are we going [11:30] and how like what what theme is this [11:32] part of? There's how to present this. A [11:35] lot of it is wider context and you know [11:38] obviously there are parts of taste that [11:40] are like okay this interaction animation [11:42] doesn't fit in the semantic meaning it's [11:45] supposed to, right? Like it's too snappy [11:47] for what it's actually trying to convey. [11:49] And that's incredibly important and I [11:50] focus probably too much on that. Um, but [11:53] there's there's like the the like what [11:56] should what should this be like if we [11:58] can build anything like what's what's [12:00] the what's the goal here and how do we [12:01] how do we get there that I think is like [12:04] actually the real taste question here. [12:06] >> When I when I hear things like this I [12:08] always wonder where will human brains [12:09] continue to be valuable as AI becomes [12:11] stronger and better and doing and doing [12:13] more of of the work and it feels like [12:16] taste is is a part of it. Something I [12:18] think about along these lines is just AI [12:19] is still very bad at actual design. [12:22] Like the output of AI is not great. [12:24] >> Yeah. [12:24] >> Rarely is it like this is it, they [12:26] nailed it. Y and it's always like, oh, [12:28] this is cloud design. This is codeex [12:30] design. Why do you think AI and the top [12:33] frontier models are just not good at [12:35] design today? Yeah. [12:36] >> And do you think they'll get there? Do [12:37] you think we'll get to a place of like, [12:39] holy moly, we're done? [12:40] >> Yeah. I tend to to think that there are [12:43] some practical reasons why it's lagged [12:46] and also some harder problems to crack. [12:49] I'm not in our research or like I'm sure [12:51] I'll get yelled at for saying this. I [12:53] think design's a little bit harder to [12:54] grade um than than software and that you [12:58] know creating a loop where you can train [13:00] the model on like what's good design and [13:01] what's bad design is just a little bit [13:02] more tedious and ownorous than you know [13:04] does the code compile does it you know [13:06] do do what it's supposed to right it [13:09] because the human aspect of taste is is [13:12] like part of the feedback mechanism you [13:14] need I also think that uh the labs [13:18] historically invest in making their [13:19] models good at things that accelerates [13:22] AI research and that in the era the [13:26] early era of coding models is very clear [13:28] that the model being able to write [13:30] correct code would accelerate research [13:34] right in a way that [13:36] you can't really make the same case for [13:38] design. Not that getting good at design [13:40] isn't important, it's that it's not [13:42] directly in that that flywheel, right? [13:45] Um those are practical reasons and I you [13:48] know those will go away like these [13:51] models will get pretty good at design. [13:53] There are some kind of murkier things [13:55] that is is going to be really tough. Um [13:58] like I have kind of a short list of [13:59] them. One is there is an aspect of of [14:03] culture to what is considered good [14:05] design in that you remember it was [14:09] probably what last year where like every [14:11] new website that came out was just a [14:13] copy of linear's website right like [14:15] linear's website great design great [14:18] taste like if a model did that I'd be [14:19] like wow this is incredible leaps here [14:22] right if I have a model that outputs [14:25] linear's website every time that's not [14:27] the challenge here right um there's 's [14:29] an amount of like novelty that is more [14:33] important in design than it actually is [14:35] in software engineering. Like software [14:36] engineering, you almost you almost want [14:38] it to overindex unknown patterns, right? [14:41] Whereas design it's like no, there's an [14:43] element of randomness here and and [14:45] novelty, right? There's also the you [14:48] know to me like I I spent a lot of time [14:50] writing code or you know supervising [14:52] code on the early codeex app and even as [14:56] the models get good at design there's [14:58] sort of a an abstraction layer that is [15:02] an interplay between the software design [15:05] and the code it's being written. Like [15:06] this thing over here in this corner [15:08] should share x y and z in the codebase [15:11] with this thing down here. Right? And [15:14] that's a little bit different than [15:16] saying the model needs to be a better [15:18] designer especially on the like you know [15:19] that's not visual that is visual design [15:21] but it is significantly deeper. It's [15:23] about the abstractions in that like oh [15:25] if tomorrow our company did a rebrand. [15:28] The shallow version of this is that we [15:30] have to you know update 263 components [15:35] one by one. The deep version is like the [15:38] semantics between these two things that [15:40] look different like they're both in list [15:43] that have the like this style that [15:45] convey this interaction pattern to the [15:47] user and I think like that is still [15:49] feeling a little bit out out of reach [15:51] with the current technology right that [15:53] abstraction layer. So I think you know [15:55] as as we've gone through this process [15:57] right of you know we started the Codex [16:00] app in uh November and [16:04] we weren't using it full-time now we use [16:07] it for everything that's been a journey [16:09] but now it's like the things that we [16:11] actually do while using it are different [16:13] things. So what was the question? [16:16] >> I know that was that was an amazing [16:17] answer. Uh, speaking of design and being [16:20] creative, the Codex app when it came [16:22] out, it's like such a new thing. Yeah. [16:24] That nobody has had seen before. It's [16:26] like not a terminal thing. It's not an [16:28] ID thing. It's like this chat thing that [16:30] codes and you could see code. [16:31] >> Yeah. [16:32] >> To your point, it feels like it'd be a [16:33] hard for AI to be like here's a whole [16:35] new paradigm for how to code. And that [16:37] feels like where human brains continue [16:39] to be valuable for now is like [16:41] creativity almost and coming up with [16:42] something new versus like a patterns of [16:45] things that have been done before. [16:47] >> Yeah. I mean, I totally agree. Let's [16:48] give it up for the human brain [16:50] >> for now. As we were getting ready for [16:52] this, you said that you were listening [16:54] to the episode of Jenny, who is the head [16:56] of design for clock code and co-work and [16:58] such, and she had this whole kind of [17:00] thesis that the design process is dead. [17:02] There's no time for design. Things are [17:04] moving too fast. [17:05] >> Uh, just build now and design is kind of [17:07] steering things as things move along. [17:09] You're implying you have kind of a [17:10] different perspective on the design [17:12] process. [17:13] >> We probably agree on on a lot of this, [17:16] Jenny and I. I wasn't a fan of the [17:18] design like the design process proper. I [17:21] agree with with her take that it is it [17:24] is dead and I genuinely was not a fan of [17:26] this process before AI like I I [17:28] >> can you describe the process real quick [17:30] just from people think about the design. [17:31] So I mean I when I read a startup a [17:34] number of years ago, we we would you [17:36] know do design hiring and there was this [17:39] sort of snarky article that came out [17:40] about like the case study factory and it [17:43] was it was like midsurp era stuff, [17:46] right? And it was that designers are [17:49] being taught about this process and [17:51] valuing that above all else, above all [17:54] outcomes even, right? And if something [17:56] went through this process that two [17:58] things were true. one, it would be good [18:02] and the process would guarantee quality [18:04] and guarantee impact and also that if [18:07] something the thing was good if it went [18:10] through that process even if you don't [18:11] like it and nobody uses it. It's like [18:14] the process was you know of of user [18:17] research and the divergence and the [18:18] convergence. It's the right framework. [18:21] It was always a little academic, but I [18:23] think [18:25] I think this is really exposing some [18:28] areas where it falls down, especially [18:30] because of the speed of implementation. [18:31] And like once again, like that process [18:34] is sort of predicated on the assumption [18:36] that implementation is expensive and [18:39] that you can really only afford to build [18:41] once. And so you need to fully like [18:46] exhaustively go through the problem [18:47] space and the solution space before [18:50] implementing, right? And that you and [18:52] and then like kind of we saw with like [18:54] you know Figma and Origami and all of [18:56] these tools that you can fast forward [18:59] some of the insights by pulling [19:01] interactive prototypes earlier into the [19:03] process, right? that you can, you know, [19:06] simulate production and like, you know, [19:08] there ended up being sort of a meme [19:10] about executives just being like, well, [19:12] can we just do a prototype and then like [19:13] expect it to, you know, work. But, but [19:15] this thing was real, right? That this [19:17] became part of the the design process [19:20] proper, right? We pulled prototyping [19:22] into that. The problem now is that you [19:24] can pull all of the implementation into [19:26] that. [19:28] And there's a mismatch between I think a [19:30] lot of assumptions again like you see [19:32] this fully polished prototype that looks [19:34] like it's ready to go out the door and [19:36] enough people at a company see that and [19:38] they're like can we can we release this [19:40] now but the appropriate like we're [19:43] actually in that early design process [19:44] stage and nobody's just saying that [19:46] right like this is this is where we are [19:48] with like a bunch of like multiplayer [19:50] exploration right you know 90 people [19:53] will have this idea it'll look really [19:55] polished but it's like no this is [19:57] actually that that's the design process [19:59] now, right? Tying the design process to [20:02] mediums, media, uh like that's the scary [20:06] part. It's that designers have more [20:09] tools now to do this process with, [20:12] right? You can put stuff into the [20:13] current product and you can AB test it [20:16] or just, you know, use that as a [20:17] prototype. Um many companies right now [20:19] have this idea of like a baby version of [20:22] the product like baby cursor. You've [20:24] seen this on Twitter like we have baby [20:25] codecs, right? a dramatically simplified [20:28] codebase that approximates all of the [20:31] interactions of the production app and [20:33] therefore is a lot quicker to vibe code [20:36] over, right? Because you can be like, [20:37] well, what if the sidebar worked like [20:39] this or what if a pain came in and had [20:40] like a group chat here? What if XYZ, [20:42] right? That's like a huge tool that's [20:44] part of the design process. So to say [20:46] the design process is dead, I feel like [20:48] it's both true and false, right? It's [20:50] that if you are if you are tied to the [20:53] tools in the ex like the spec the exact [20:56] like day-to-day specifics of the process [20:58] then yeah it's dead like you're not [21:00] going to have a good time but to throw [21:02] the process out completely or throw like [21:05] the overlay of the process the like hey [21:07] we're at this point in the process like [21:09] that is still more important than ever [21:11] it's it's really interesting because you [21:13] have a background in every function if [21:15] people look at your LinkedIn it's like [21:16] engineer designer product manager [21:18] founder uh now You oversee the desktop [21:21] app and I think design is not under your [21:22] perfume. Is that right? Is there like a [21:24] separate design team or are they under [21:25] your [21:26] >> depends on the week? [21:26] >> Okay, good. [21:27] >> We work very closely together. Like we [21:29] believe in all sitting together being [21:31] embedded like I reporting lane. I don't [21:35] >> they sh the shift weekly. What does the [21:36] design process look like on on the [21:38] codeex? [21:38] >> Yeah, there's been a lot written about [21:40] ro collapse, existential role collapse. [21:42] There are no roles anymore. We haven't [21:44] seen that. Um we've we have seen more [21:48] role collapse in the codeex org um than [21:51] I think other parts of the company and [21:53] other parts of the economy. I think part [21:54] of this is that this was a technical [21:58] product for engineers and so our [22:00] designers speak engineer right our [22:04] product managers speak technical [22:06] language and write code. Alexander has a [22:10] master's degree in computer science, [22:11] which is I do not have a master's degree [22:13] in computer science. Like, so we've seen [22:14] a lot of role collapse and and I think [22:16] that, you know, one of [22:19] one of the ways that we describe how the [22:22] groups work together is that there's [22:25] significantly more overlap in the roles [22:26] than there used to be. And everybody's [22:29] sort of defined less by the fence and [22:31] the boundaries of where design stops and [22:34] engineering starts, but more the average [22:36] of where they're working, right? So [22:37] like, you know, if you average up all of [22:39] the things that somebody on our design [22:42] team does, there's plenty of codew [22:44] writing things. There's plenty of things [22:45] that are product work, but on average, [22:47] like their dots over here, right? If you [22:49] draw you draw it out on a diagram, and [22:52] this sort of speaks to the process, too. [22:54] Um, especially because [22:57] the entirety of the critics app has been [22:59] informed by the dog fooding loop. There [23:02] is a desire among all of us to try to do [23:05] as much as possible in the app even when [23:07] it's not the best tool so that it can [23:09] become the best tool. And so a lot of [23:12] design we all work on by using the app [23:15] and say okay what's broken about this? [23:17] This is a whole thing we do which is [23:18] that we we often don't improve our [23:21] process so that we can make the product [23:23] better to do it which is a deeply like [23:26] uncomfortable place to be in but you [23:28] know week to week it's changing. I love [23:30] this point so much that uh like what are [23:33] you? It's your role is the average of [23:35] what you spend your time on. If most of [23:37] your work is PM work, then okay, you're [23:39] a PM for now. [23:40] >> Yeah. [23:40] >> If it's engineering, you're an engineer [23:41] for now. [23:42] >> I feel like was OpenAI the first company [23:44] to uh call people member of technical [23:46] staff. [23:46] >> No, I I believe that this this might [23:49] have started with Xerox. First company I [23:51] interned at, it was a company called Up [23:52] There did the same thing. [23:54] >> This has been around, but it's it's it's [23:55] much more common now. you know, it is [23:57] kind of a tradition in research focused [24:00] companies, [24:01] >> right? Okay, got it. So, it emerged from [24:02] research, but I feel like it's such a I [24:04] don't know sign of where things might be [24:07] headed. This idea of uh we're just going [24:08] to call everyone me member of technical [24:10] staff. Your function isn't set. You're [24:13] not like in this bucket of the PM or [24:15] theorg of the design or do you feel like [24:17] that's where we all head long term? Do [24:19] you feel like functions will continue to [24:21] exist? Like there's still the PM skill [24:24] set and the NG skill set and the design [24:26] skill set. [24:27] >> Yeah. [24:27] >> And people are I'm a designer or do you [24:29] think this is like like people call it [24:31] builder? Do you feel like there's this [24:32] collapse coming where everyone's [24:34] everything and that's just the future or [24:35] do you think we're going to continue to [24:36] be mostly divided up in? There are there [24:40] are some things that I'm afraid of. And [24:41] I think that, you know, some some [24:43] companies [24:46] like to be very extreme about getting [24:49] onto the bandwagon of whatever people [24:52] say is going to happen. And I think part [24:56] of the danger in eliminating the concept [24:59] of roles is that it can dangerously [25:02] eliminate the idea that things are [25:05] specialties with knowable best [25:08] practices, right? I I've heard a lot of [25:11] companies be like, we're getting rid of [25:12] the product role, which I think is, by [25:13] the way, a terrible idea. Um, and [25:16] everybody's just going to be like a [25:18] builder. And then what happens is they [25:21] don't like this whole discipline of [25:24] product that's been built up and has [25:26] like real best practices, real things [25:28] that have been tried and failed and like [25:30] real processes like that just gets [25:32] abandoned because people are like, "Oh, [25:34] I wrote some code, right?" Like that's [25:36] not a great place to be in. I think that [25:38] the boundary of like so and so like this [25:41] isn't your lane. I I welcome that part [25:45] going away, but there's a balance here [25:48] where it's like not everyone can work on [25:51] everything for one, both in terms of [25:54] breath and depth, right? Like this is [25:56] why managers are not going to go away. [25:57] Um, not everybody can work on everything [26:00] and also like every discipline has a [26:05] skill component to it, which I think a [26:08] lot of engineers are guilty of not [26:10] recognizing that like well engineering [26:11] is a skill to it. it's writing code and [26:13] like other roles are just people vibing. [26:15] It's like no that's not how it works, [26:16] right? Um like yes, you can use Excel [26:19] you but you cannot work on the finance [26:21] team, right? That is like that kind of [26:23] stuff, right? [26:24] >> Yeah. I think there's also just like do [26:26] you want to be doing this work? Do I [26:27] want to be [26:28] >> I think more of it that actually now is [26:30] like it's easier to switch roles. It's [26:32] easier to learn the best practices. It's [26:35] easier to not tie your effectiveness in [26:37] a role with the ability to use the exact [26:40] tool, right? It's more of like can you [26:43] get yourself into this mindset, learn [26:45] which things work and which don't and [26:48] then like focus on it, right? Like I I [26:52] spent so long feeling like I should not [26:55] be a software engineer because I didn't [26:57] care about like assembly language or [27:02] memorizing TypeScript syntax, you know? [27:05] And it's like there have always been [27:07] parts of these roles that are that sort [27:10] of gatekeeping that are like, well, no, [27:12] this like being good at this role is [27:14] being good at this tool. And I think [27:16] that's what's kind of starting to erode. [27:18] I just don't I I think people take this [27:20] they hyperbolize all of this. [27:22] >> What does your team look like on on on [27:24] the Codeex team? How many engineers, [27:26] designers, PMS? What's kind of like the [27:28] makeup of the team right now? [27:29] >> Every time people ask me like how many [27:30] people are on the Codex team, do you [27:32] remember my answer to this? Yeah, I I'm [27:34] like it's somewhere between 10 and a few [27:36] thousand. I mean, it's like a fake [27:38] answer, but it's it's real in that we do [27:41] see this as the culmination of [27:43] >> what everybody works on here. Like [27:45] everything that goes into model [27:46] research, everything that goes into how [27:48] you know models are good at kua and [27:51] browser use, everything about how you [27:53] know model personality, all of the [27:56] product work around you know front-end [27:57] infrastructure, all of the user like all [27:59] of it is this product. At the same time [28:01] we are not accepting PRs daily from [28:03] thousands and thousands of people on [28:05] whatever they want. Um so we got a team [28:08] uh double digits of engineers probably [28:10] half that on the design side. um you [28:13] know few product people although you [28:15] know product tier is kind of more of his [28:16] own defense play and I think one thing [28:19] that is very common around among [28:22] everybody on the codics side or or on [28:24] the desktop side is agency and taste [28:28] right a lot of former founders or people [28:31] who were at larger companies doing [28:33] founder shaped things um a lot of people [28:36] with with immense taste at openi we let [28:39] teams get very large so we haven't that [28:42] hey there's no management but like the [28:43] teams are quite large right it's mostly [28:45] IC's um and I think that's good [28:47] >> you use this term zone defense for [28:50] product work and I think that's really [28:51] interesting it kind of maps to the [28:52] design kind of shift also just like [28:54] you're there to kind of manage and [28:56] coordinate talk a little bit more about [28:57] what that looks like what does zone [28:58] defense look like for a product person [29:00] >> yeah and I I have had a lot of [29:02] conversations with with Alexander about [29:03] this this analogy which is that like if [29:06] two product people are working too [29:08] closely that's often not a good signal [29:11] And that like you kind of want like as a [29:15] product or you sort of want to do this [29:18] like forced directed activity where [29:20] you're like where are the gaps [29:22] especially in this new world where [29:23] curation and like you know steering and [29:26] alignment is a lot of things where [29:27] you're like there's a ton of chaos [29:28] happening on people throwing ideas all [29:31] over the place right the whole like top [29:33] down you know year-long planning thing [29:35] not going to work and so now it's like [29:37] we need the taste makers to guide things [29:39] from incept ception to what the product [29:42] should be. And that means you basically [29:45] want company coverage. And so you spread [29:48] out and you say, "All right, who's like [29:49] who's best at what? Let's create some [29:51] space between us so that we got full [29:53] coverage, right?" And that's kind of how [29:54] it goes. And then you fill in the gaps [29:56] and you're like, "Look, like we want to [29:58] hire engineers who are product minded. [30:00] Like we don't we don't want it to be [30:01] that, you know, we've got a bunch of [30:03] people writing a bunch of code that [30:05] needs like full team reviewing it for [30:07] like product coherence, right? Like we [30:09] want everyone to have these skills, but [30:10] I think like what people go deep on has [30:13] to change, right? [30:14] >> This is definitely a thread I've been [30:15] noticing over and over with talking to [30:18] folks like you is the the most valuable [30:20] person right now, one of the most [30:22] valuable is someone that could take an [30:24] idea from idea to done with the taste to [30:27] know this is great. Just like shephering [30:29] throughout this obsession with making it [30:31] awesome like this kind of high agency, [30:33] high taste person. Exactly. as you [30:35] described, is that is that kind of the [30:37] way you think about here's who we're [30:38] hiring, here's who's going to do really [30:39] well in this new world? [30:40] >> Yeah, I think that that's that's the [30:42] core piece right now. And it it also [30:45] speaks to how I sort of see IC versus [30:48] management, which is that it's not that [30:50] management is going away. It's not that [30:54] everyone's an IC, but like everyone's [30:56] kind of both now, right? If you're an [30:58] IC, you're not typing code out character [31:01] by character, right? like you are [31:03] managing something you're managing [31:05] agents you're managing you know like [31:08] you're managing work that is happening [31:11] right that comes together to do a [31:13] certain thing if you're a manager of [31:14] teams you're doing the same thing just [31:17] at a different like different [31:19] granularity right I generally look for [31:22] like obviously command over the [31:25] discipline but then the taste to say [31:27] like hey you're going to have unlimited [31:29] tokens and I don't like we can't just be [31:31] doing slop like you need to be able to [31:33] determine what's signal, what's noise, [31:35] like in a world of just infinite [31:37] content. [31:38] >> Mentioned planning uh at the pace things [31:41] are moving. It's become very hard to [31:43] plan road maps. Yeah, [31:44] >> I imagine especially in our world. [31:46] >> Uh [31:47] >> people are very frustrated with me all [31:48] the time on this. Yes. [31:49] >> Because things are just constantly [31:50] shipping, things are changing, right? [31:52] How do you plan on on on your team? [31:53] What's kind of like how far ahead are [31:55] you thinking and what does a plan look [31:57] like? Is it like a spreadsheet? Is it an [31:58] MD file? What what's kind of the output [32:00] of a plan? Yeah, I I don't think we do [32:02] anything revolutionary on that. We're [32:03] not clever about planning. I think like [32:06] the basic gist is the shorter term [32:09] something is, the more detail it needs. [32:11] And then it's not that we don't plan for [32:14] 9 months out, it's that that just has to [32:16] stay very hazy because any amount of [32:18] precision that you add to a 9-month plan [32:20] right now is false precision. And like [32:22] you're just going to waste time. Like [32:24] you can say stuff, right? But like [32:27] nothing that we planned. I think [32:28] research is different. So I'm not [32:29] speaking for research here but like on [32:31] the applied side when we do product like [32:34] anything that you could have planned in [32:36] November may have been true for December [32:39] but like isn't what happened right so [32:42] it's hard like it is really hard to do [32:43] planning we generally need to know like [32:46] what do we think models are able to do [32:48] on what timeline and my last company I [32:52] kind of saw this shift where we were [32:55] starting to use the models to drive [32:58] features and the product process fell [33:01] down. It basically had to be like, let's [33:04] list out all of the things that we think [33:06] we are interested in doing for the next [33:09] year or two. Let's prototype all of [33:12] them, decide which things are ready now, [33:14] and then just let the others sit and [33:17] bake, and then every time there's like a [33:19] new leap in models, let's try that thing [33:21] again with it swapped out. because like [33:23] the whole premise of whether features [33:25] were good or not were based on whether [33:27] they were smart enough, not the shape of [33:30] them. [33:31] >> So this is a great story about the Codex [33:32] app. I like I am very confident that the [33:35] Codex app that we released in February, [33:38] if that had been ready in November, it [33:41] would have absolutely failed in the [33:43] market and that that the only difference [33:45] was the models between November and [33:48] February, right? And I I think like [33:51] there's a lot to that that this product [33:55] with the exact same shape I think would [33:58] have like it's it's outcomes were [34:00] totally different depending on just a [34:03] few months of timing. This episode is [34:05] brought to you by Mercury. Radically [34:07] different banking loved by over 300,000 [34:10] entrepreneurs and now with command. I've [34:13] been a customer of Mercury's for over 6 [34:14] years. I have never once thought about [34:16] leaving. Mercury is basically what [34:18] happens when banking is built by product [34:21] people, not by bankers. They make it so [34:23] easy, dare I say fun, to send invoices, [34:27] move money around, set up virtual cards [34:29] for folks on my team. Does your bank [34:31] have an API, a terminal native CLI or an [34:34] AI ready MCP server? I don't think so. [34:38] And just recently, they launched [34:39] Command, a conversational interface [34:42] built directly into Mercury, which acts [34:44] as your financial operator. I've been [34:46] using Command to transfer money around [34:48] to figure out what categories I've been [34:50] spending the most money in, analyze my [34:52] cash flows, and just today I used it to [34:54] find out how much I've made from a [34:56] specific sponsor over the past year. I [34:58] just ask, "How much have I made from X [35:00] over the past year?" 10 seconds later, I [35:02] have an answer. It is so freaking cool. [35:05] Visit mercury.com to learn more and [35:07] apply online in minutes. Mercury is a [35:09] fintech company, not an FDICsured bank. [35:12] banking services provided through Choice [35:13] Financial Group and column NA members [35:15] FDIC. [35:17] This is definitely a thread on this [35:19] podcast is build things that are not yet [35:22] working then will work when the model [35:25] gets better. And there's this kind of [35:28] other thread of ambition. Be more [35:29] ambitious with the things you take on. [35:31] So is this just like a way you approach [35:33] things just like let's just build a [35:34] bunch of things that may not work yet. [35:36] We'll just have them around and wait for [35:37] a model to catch up. Is that kind of the [35:39] approach? [35:39] >> Yeah, I think we have a lot of that. I [35:41] think sometimes the challenge is like [35:42] you have to be very clear again about [35:44] what stage of the design process that's [35:46] in. People still have this muscle memory [35:47] of like, oh, I wrote the code for this [35:49] thing, therefore we should put it out [35:50] there. It's like, no, no, no, that means [35:52] you have an artifact now that we can [35:54] test against for into future models, [35:55] right? Um, this happened with the inapp [35:58] browser in the app that we have, right? [36:00] Like we had a a kind of a working [36:03] version. I mean, go back to Atlas, we [36:05] had agent working inside of Atlas and, [36:08] you know, that was pretty cool. We had [36:10] operator before that in chatbt, right? [36:12] That didn't work out. Very cool idea. [36:14] Like there's some thread that you can [36:17] draw between operator atlas codeex [36:20] chatbt that's like fundamentally the [36:23] same feature, but the re-releasing of it [36:25] with different intelligence totally [36:27] changes the outcome here. And so I push [36:30] people not to be stubborn about like no [36:32] this isn't working so it's a bad [36:34] feature. Like no, it might not be ready [36:35] yet. Um there's also this aspect of [36:39] especially in research there's always a [36:42] desire to be the most ambitious and to [36:45] say okay but at the limit the model can [36:48] just do this and it just doesn't work on [36:50] the product side like if you if you go [36:52] back to the original Codex release [36:54] basically what it was is it said it was [36:57] codex web and it wasn't good for [36:59] interacting with it was like you give [37:02] the model a task and it's going to go [37:04] off do the task come back to you with [37:06] finished like doesn't sound that [37:07] radical. The problem is like it didn't [37:09] do the task that well. Like it wrote [37:10] code. It was it was it was good but it [37:13] was like that form factor was too early [37:15] and then the cloud code comes out [37:17] totally local like not hooked up to the [37:19] cloud. Um doesn't pretend to be as it's [37:22] not as agipel right it's like going to [37:24] ask you questions it's going to sit [37:26] there you can't just delegate your life [37:27] to it. That worked way better right [37:29] because that's the point that the models [37:31] were at there right? So we were like we [37:33] were too agi pilled for the moment. And [37:35] I think like I I think about that lesson [37:37] a lot on this stuff. It used to be that [37:40] you know Bailey and market told you all [37:43] these things about the shape of the [37:45] product about the communication of the [37:47] product and now it's like no you might [37:48] need to release this thing six different [37:50] times before it works and that might [37:53] like the shape might not change at all. [37:55] There's like it's so interesting to hear [37:56] about all the variables you have to [37:58] think about building product. Now [37:59] there's the timeline for the models and [38:01] the research and how smart it gets. [38:02] there's like people's ability to even [38:04] understand this is how you could build [38:06] software in the cloud and this is the [38:07] future like get people prepared for this [38:10] new future and then just uh what you can [38:12] build as a team and I love that codeex [38:14] example cuz comes back to this idea of [38:16] ambition and I want to hear if there's [38:17] anything there for you of just this [38:18] threat of just be more ambitious because [38:20] these models can do so much more than [38:21] you even imagine and sometimes it's too [38:24] ambitious for the market and they're not [38:26] ready for it but you think about that at [38:27] all just like pushing your team to be [38:28] more ambitious because it's so much [38:30] easier to just do things that may be [38:32] felt crazy hard in a fast. [38:34] >> Yeah, this is a core challenge. Once [38:36] once there's a product that exists or a [38:39] feature that exists, it's really easy [38:41] for people to find paper cuts and [38:43] >> optimize [38:44] >> and they should and people on Twitter [38:45] like to remind us of this and I thank [38:47] them for that. Like people should be [38:49] focused on the features that exist and [38:50] making them more reliable and better. [38:51] But this, you know, this is why we also [38:53] have a culture of bottoms up exploration [38:55] here because sometimes in the same way [38:59] the Codex app came and disrupted Chachup [39:01] T in some way, right? This thing will [39:02] get disrupted by a future effort and [39:04] that's that's part of the design is that [39:07] like you can't always as one team be [39:10] good at both the disruptive piece and [39:12] the like maintaining a product and its [39:14] quality piece. Some point to design a [39:17] process that allows for both. kind of [39:19] zooming out a little bit. If you think [39:21] about the progression that we've been on [39:23] of uh AI impacting how we build product, [39:26] it's like insane how far we've come [39:28] from, as you said, we used to write all [39:30] our code by hand, like artisally created [39:32] human code to AI writing 100% of our [39:35] code to you actually put it this way [39:37] that now like coding is steering the AI [39:41] and like when you think about what [39:42] percentage of my code is written by AI, [39:44] it's almost like how many times did I [39:45] have to steer it in the right direction [39:46] is the AU version of coding. And now [39:48] that there's like agents and loops and [39:51] all these things, what's kind of the [39:54] latest frontier from what you've seen of [39:57] how people are building is is it loops? [40:00] Is there something else of just like the [40:02] most AI AI forward teams? Here's how [40:05] they operate now that people may not be [40:06] aware of. [40:07] >> Yeah, I mean loops are so last week, [40:09] man. I mean, we we talked about this. [40:11] Um, you know, one of the big questions [40:13] is always, well, how much of the product [40:14] is AI written? And [40:17] it's always hard to answer that question [40:19] cuz if you're using the goalposts from [40:22] last year, it's like, well, 100% of our [40:24] product right now is AI written code. So [40:27] the question is more like, well, okay, [40:29] fine. Is is the code written supervised [40:32] versus unsupervised, right? And that's [40:34] like a totally different thing. I [40:36] welcome the moving of goalposts because [40:37] that means we're making product [40:38] progress. There have been a lot of [40:40] explorations here around like autonomous [40:43] autonomously developed software. um a [40:46] lot of like harness engineering stuff, a [40:48] lot of different explorations. I'm like, [40:49] okay, well, what if you came in [40:51] overnight and did garbage collection of [40:52] the codebase to clean it up, right? One [40:54] thing that I think all models suffer [40:56] with right now is just they they usually [40:59] increase complexity. If research is [41:02] listening at any company, please make [41:04] the models better at deleting code. Um [41:07] but you know, that becomes a problem [41:10] right now when you try to put [41:12] development completely on autopilot. Um, [41:14] and it's both on the the human side and [41:17] the codebase side. So like feature [41:18] requests, right? You know, how do you [41:20] teach a model which features to build, [41:24] which ones to ignore, which ones to kind [41:25] of like group together and reframe a [41:27] little bit? How do you teach a model how [41:29] to build the right abstractions, right? [41:31] Like all of this is getting better. Um, [41:33] I don't think we're at a place yet where [41:35] we're like, we're just got to set up a [41:37] loop that's like improve the app, you [41:40] know, and listens to Twitter and listens [41:42] to Slack and listens to email and like [41:45] we're not there yet, but we are we are [41:48] we're trying to make it happen. [41:49] >> Do you think we'll get there? Do you [41:51] think we'll get to a place where it's [41:52] just like grow like win [41:54] >> slashgoal make money like make me a [41:56] billion dollars? [41:57] >> Win win the market. [41:58] >> I don't know, man. Like I [42:00] >> I am not in the business of saying [42:03] >> never or always or whatever. [42:05] >> Yeah. How are you using AI in your work [42:08] as product leader, engine leader? [42:10] >> What are some ways that you use it that [42:12] maybe people may not be aware they can [42:14] use the app for? [42:15] >> Yeah, I I think I have the best job in [42:17] in the world right now. Um, but one of [42:19] the things that makes it very fun is [42:22] that when we were developing the [42:23] original codeex app, the goal for me [42:26] personally was to make it the thing that [42:29] I wrote the code with, right? I was [42:31] like, I need to make this so good at [42:33] development that I can build the code [42:35] app with this. And the codeex app at [42:37] that time was a development tool, right? [42:39] And we did that like super quick dog [42:42] fooding loop because you got your [42:43] personal dog fooding loop where you're [42:45] like, oh, like I can't do this thing. I [42:47] should fix that. so that I can do the [42:49] thing. Now I can do the thing. Now I can [42:51] do more things, right? Um you know we [42:53] released that and then the next [42:54] challenge was hey people are starting to [42:56] do some different shaped things with [42:58] this right and now I you know need to [43:01] grow this and so I need to hire a few [43:02] people and help. So then like my role [43:04] changed at the same time that the role [43:05] of the app needed to change. So I'm like [43:07] okay I need to do more product discovery [43:09] here. I need to figure out the right [43:12] loops for seeing what everybody's [43:14] working on and steering things that are [43:16] off track. And so all of a sudden that's [43:18] what I started using the Codex app for, [43:19] right? I did still write code. Like I've [43:22] I've tried to align my own usage of it [43:24] with the problem that we're trying to [43:26] solve, right? And now I'm like, I need [43:28] to build a spreadsheet that models this [43:30] out. I need to kind of do a, you know, [43:34] internal deep research on all of the [43:36] efforts that have gone into this area of [43:38] research for the next version of this. [43:41] There's a release or a series of [43:42] releases in Mayish that introduced the [43:46] inapp browser computer use and artifact [43:49] creation to the Codex app. That was I [43:52] think our Codex's for almost everyone [43:55] release and everybody knows the term [43:58] vibe coding. I think that was like our [43:59] first five coordinated release where [44:01] like I had a a you know notion doc [44:03] somewhere with everything that needed to [44:05] happen and I was like automating like [44:08] going out to gather updates from pull [44:11] requests from Slack channels and like [44:13] updating the status tracker and like now [44:16] this is pretty common place. Um but at [44:18] the time I felt like I was at the [44:19] bleeding edge of like how to manage a [44:22] product release. In short, like the way [44:23] that I use the Codex app is basically [44:27] like what what has my job grown into and [44:30] how do I make this thing able to do [44:32] everything I need to do? Um, I will get [44:35] up in the morning, I will see the daily [44:36] brief that I have from like everything [44:39] from the 3,000 Slack channels that I'm [44:42] in, like which things need my attention. [44:44] I can kind of message back and be like, [44:46] "All right, give me five questions and [44:47] I'll answer them and I can, you know, do [44:49] that." [44:49] >> How do you set that up? what's like the [44:50] workflow to for somebody to set that up [44:52] because that sounds amazing. [44:53] >> Again, I I think we're still in the like [44:55] discovery phase on on a lot of this. And [44:57] and so right now it's like I'm making an [44:59] automation that says or scheduled task [45:02] that says like I go through my Slack [45:04] channels. These are the things that I [45:06] care about and think are most important, [45:09] you know. So I'm still kind of defining [45:10] that like these are things to watch out [45:13] for different categories like here's [45:14] some context and you know I'll I'll you [45:17] know that'll get set up as a automated [45:19] task and then first few times it runs it [45:22] might need some steering and luckily [45:23] with this app you know I don't have to [45:25] find out how to edit the instructions I [45:27] can just be like hey next time this runs [45:28] like can you please worry about this [45:30] instead or can you deemphasize this [45:32] workstream or hey this thing happened [45:34] and it didn't come up in a brief like [45:36] can you make sure that stuff in the [45:37] shape so I can kind coach it along the [45:39] way. It'll update the way that it it [45:42] notifies me, stuff like that. Amazing. I [45:44] think in the future though, like this is [45:46] this has been a core problem with the [45:47] the chatbot shape, right? Is that I know [45:51] how to set this up. I have time to set [45:53] this up because for me it's product [45:55] discovery to set it up. But if you're [45:58] not working at OpenAI, not developing [45:59] this, like you don't want to have to [46:01] figure out all this stuff. Like we we we [46:03] need to like figure out that that shape [46:05] of things. [46:06] >> Yeah. What I'm hearing is I don't think [46:07] people realize that uh your app can act [46:10] a lot like open claw. [46:12] >> Yeah. [46:12] >> You was was people were so excited about [46:14] like you just talk to it, set up this [46:16] thing, check on this thing for me every [46:18] day and then tell me what's going on [46:19] like like it's starting to become a part [46:21] of all these all the products. [46:23] >> Uh which is amazing. So the way somebody [46:25] would set this up is they just talk [46:26] within the app and say I want to set up [46:28] an automation to do this. Look at my [46:30] Slack and these are the things I I want [46:31] to do. [46:32] >> Yeah. Great. [46:32] >> Yeah. And the app will say you know [46:34] >> Yeah. It'll set it up for you. If it [46:37] doesn't have a Slack connector, it'll [46:38] say, "Can I add the Slack connector?" [46:41] Yes or no? You can hit yes to that. Like [46:43] the least that we can do is make it so [46:46] that if you don't know how to do [46:47] something in the app, they can just ask [46:49] it, right? Yeah. [46:50] >> I don't think that's enough, but I think [46:51] that's the least we can do. [46:52] >> Yeah. A good example is I built this [46:54] little app that filters spammy email [46:56] forbox. So every email that comes in and [46:58] I built this in codeex. Uh every email [47:00] that comes in, it looks at it and [47:02] decides is this uns unsolicited kind of [47:04] cold email stuff that I don't want to [47:06] look at and labels it and puts it [47:07] somewhere else. And to set that up, one [47:10] of the steps was you have to go into [47:11] like the Google cloud console and set up [47:13] all these pups subhub API things and [47:16] triggers. I don't know if you've ever [47:17] used that interface. It's like so [47:19] annoying and slow, right? So I was like, [47:21] wait, what if I ask you to do it? And I [47:23] was like, okay, cool. Do this for me. [47:25] And it just you describe computer use. [47:27] I've never actually seen this happen on [47:28] my computer before. It just takes over [47:30] my computer and starts going there. [47:32] >> It's like I don't care if you don't have [47:33] a connector, man. I'll just start [47:34] clicking. [47:35] >> Yeah. And it figures it out. It's crazy [47:37] just to like watch it doing its thing. [47:39] >> Designing the decision boundary between [47:41] connectors. When to use the inapp [47:43] browser versus your Chrome extension [47:46] that's connected versus computer is [47:48] interesting and all done through just [47:50] like feeling it out. I saw a great [47:52] Twitter thread the other day where they [47:54] describe all these three and what you [47:55] use it for. [47:56] >> Yeah. [47:56] >> So, this person described it really [47:57] well. [47:58] >> These personal workflows are really [48:00] interesting because [48:03] some of them really click like some of [48:06] you know people are trying all sorts of [48:08] stuff. Everybody's making these personal [48:09] systems. You ask everybody here what [48:11] they do and everything's going to be [48:12] different and then like certain themes [48:14] arise and we're like you know what that [48:16] should be a first a first class [48:18] experience on the app. like we should [48:20] take this thing that everybody seems to [48:21] be setting up and just make that work. [48:23] And I think memory is sort of in the [48:25] shape where we've had a lot of people [48:28] and a lot of people at other companies [48:29] too are like well I set up an obsidian [48:32] base or a notion area and I tell it how [48:35] to basically build my mind palace and [48:37] how to put it's like I don't know if [48:39] everyone like you shouldn't have to do [48:40] that like there should be a memory [48:42] feature that does that for you right [48:44] that's pretty generic. So that's you [48:45] know that's one but then there are other [48:46] things like they're your process of your [48:49] job and there's something that like yeah [48:51] you should set that up but I think this [48:52] is we're constantly waiting through like [48:54] what's working for individual people [48:56] like what should what should enter the [48:58] product versus stay like no that's just [49:00] how you do your job right what should [49:02] become a primitive what shouldn't um [49:06] >> yeah this is the the taste and judgment [49:08] you spoke of earlier you know citing [49:09] these things I want to talk about this [49:11] browser use piece a little bit because I [49:12] think people don't realize how powerful [49:14] this is and what it could be used for. [49:17] Reminds me, I don't know if you watched [49:18] uh when Dan Shipper was on the podcast, [49:20] he had this from every he had this [49:22] prediction that we're going to start [49:24] using codeex to run our SAS apps inside. [49:28] >> Yeah. [49:28] >> So, instead of going in Chrome, [49:29] >> I know he slacks me about this every day [49:31] asking for stuff. [49:33] Do you feel like this is where things go [49:35] where we're just working within the [49:36] codeex app using notion and linear and [49:40] Salesforce inside with your agent kind [49:42] of helping you along or do you think [49:44] that's a kind of a different direction? [49:46] >> It's been Yeah, it's been really [49:47] interesting because obviously we've had [49:48] a few attempts at browser shaped [49:51] activity, right? And operator and tragic [49:54] de agent mode and atlas and now we have [49:58] the inapp browser inside of the desktop [50:00] app. We also have the the ability to [50:02] install a Chrome extension where the app [50:04] connects to Chrome. Like we've had a lot [50:07] of shapes at this and I think we've [50:09] we've learned a lot of different things. [50:11] There's there's a lot at play. There's a [50:13] lot of really boring things at play. [50:14] Like you know, we originally launched [50:17] the app. It's an Electron app. The [50:18] things that you can do with inapp [50:20] browsers and there it's it's like kind [50:21] of janky. So we had the the inapp [50:24] browser was for development. It was for [50:25] testing your front end on development. [50:28] And we were like it's not really for [50:29] anything else, guys. like it's it's a [50:31] developer tool, right? And then we we [50:33] switched over to our owl owl stack which [50:36] had powered the Atlas browser and so now [50:38] you know multitab and we've got [50:40] enterprise security so that you can [50:41] actually log into all your websites if [50:43] you're you know so uh we've been [50:45] iterating on this. I think the tough [50:47] thing has always been what should the [50:48] shape of this browser be like is this [50:50] something that is only for the agent [50:53] right that like you've got Chrome you [50:55] open Chrome you you know do your thing [50:57] in Chrome if you ask the desktop app it [51:00] opens up this browser that it can [51:01] control really quickly doesn't have the [51:03] latency of playright whatever but that [51:05] you know or are we trying to say this [51:07] app is for everything and like we want [51:09] you to use this as a browser and those [51:11] have a lot of trade-offs it's not super [51:14] you know welltraveled [51:16] path, right? Like most browsers are [51:18] browsers at the top level that got [51:20] browser tabs. Um, this creates a lot of [51:23] really boring but tedious problems like [51:25] keyboard shortcuts, right? Are we trying [51:28] to do key mapping to VS Code or to [51:29] Chrome or to our own thing or to linear [51:32] or like, you know, we want to have some [51:34] sort of muscle memory that carries over [51:36] but got all these things that have shape [51:38] like subshapes of different products out [51:40] on the market. What do we do? And this [51:43] just highlights how extra challenging [51:46] this app is where you have to allow it [51:48] to work for somebody that's never built [51:50] anything [51:51] >> from like the more basic user to like [51:53] power like Peter [51:56] >> Open Claw trying to code with it. [51:57] >> I I'm not convinced I'm going to get [51:59] Peter to use the app. I think he might [52:01] be the last terminal terminal hold out. [52:04] Okay. [52:04] >> But I'm going to I'm going to keep [52:05] trying. [52:06] >> Okay. Let me uh let me zoom out for a [52:08] moment and talk about kind of the big [52:09] picture of where you're taking all this. [52:12] What's the what's kind of the vision for [52:14] for Codex? Where does this go? What's it [52:15] going to look like? You know, I don't [52:16] know, a year or two, 10 years. [52:18] >> We had Codeex as a CLI, right? And then [52:21] we decided to build this app. And, you [52:24] know, we were we were a little uncertain [52:25] about the app and um but had a lot of [52:28] conviction in what it could be as to [52:33] start a developer tool, right? That [52:35] >> Yeah. [52:35] >> and it wasn't going to be an IDE. It was [52:37] going to be this right-sized surface [52:39] where it was like sort of a chatbot, but [52:41] it was more than that and you could see [52:43] the code, but we weren't going to let [52:44] you edit the code. There's a really [52:46] interesting thing that happened at [52:48] OpenAI in January in February, and it [52:52] was before we actually released the [52:54] Codex app, which is that we'd started to [52:56] dog food the Codex app. And [53:00] what we were finding like we were [53:01] converging on some pretty clear internal [53:03] PMF on engineering right and research [53:07] workflows. They were thrilled. They were [53:09] loving it. We were like all right we [53:10] just got to get the quality bar up [53:12] before we release it to the world. We're [53:14] convinced that this will be a thing. But [53:15] then at the company we spun up a few [53:17] other workflows to say hey like this [53:20] Codex effort is onto something with [53:22] these coding agents and we have people [53:25] from marketing from comms from finance [53:28] from legal from basically every [53:29] discipline who are using this codeex app [53:32] even though it is actively hostile to [53:34] these people right it is like trying to [53:36] show them code it's trying to ask for [53:38] approval to run RG on the you know it's [53:41] like it's doing all of these things that [53:43] are actively not the right product [53:45] surface for them. So why don't we take [53:48] our other surfaces and add codecs to [53:51] them? Like let's add it to the chatd [53:52] desktop app. Let's add it to the atlas [53:54] browser, right? And let's essentially [53:57] take the lessons of codeex and make it [53:58] more general for a general knowledge [54:00] work tool, right? And those efforts went [54:04] for a little bit and the the most [54:06] annoying problem happened which is [54:09] nobody would leave the Codex app for the [54:11] apps that were allegedly for these other [54:13] personas. And I think the lesson in all [54:16] of this was just that like the whole [54:18] developer tool versus general knowledge [54:21] work tool like there's a lot of nuance [54:23] here that isn't just one or the other. [54:25] And I think we really we believe really [54:27] strongly in this and that there are [54:29] certainly in the same way that we talk [54:31] about the average of your role is like [54:32] what your role is now. This is true on [54:35] the product side too. People who are [54:37] doing Excel work don't want to see git [54:40] repository information. We know that. [54:42] But we also know we can tell a lot from [54:44] what they're doing about what kind of [54:46] work they do and we can start simple [54:49] grow the product complex as we feel is [54:52] needed. Right? Doesn't mean we don't [54:53] have modes, right? You might want some [54:55] modes for organizing your stuff and to [54:58] sort of be like legible about the the [55:00] ways that you enter the experience, [55:01] right? But we really believe strongly [55:03] that what we've built here is the right [55:07] shape to take take on like really deep [55:10] vertically focused things, right? We [55:14] work deeply with our finance team with [55:16] our team working on science team working [55:18] on legal, right? And and we say like if [55:22] we can build the right extensibility [55:25] primitives in the right general model, [55:28] then you can do anything with this, [55:29] right? And then our challenge is well [55:31] how do you you know how do you [55:32] generalize it? But this is kind of going [55:34] back to like the best desktop app that [55:37] we can build like what does that look [55:38] like? Um and so you know was Codex the [55:42] developer tool chatpt like where does [55:45] this go? This is how we think about it. [55:48] >> It is so interesting the point you made [55:49] that the Codex app was so like you did [55:52] such a good job getting people to be [55:53] aware it existed and so good to use and [55:55] fun to use that everyone's starting to [55:56] use that versus the chat GPT app. So [55:58] clearly the direction is combine them so [56:00] that you're not creating this confusion [56:02] which I know is you know things people [56:04] have been talking about this idea of com [56:05] bringing them together. [56:06] >> Somebody called it a super app and wish [56:09] they hadn't said that cuz now I have to [56:10] hear about the super app all day every [56:12] day. We'll get past it. Great. [56:14] >> Okay. But is that is that kind of the [56:16] not let's not call it a super app but [56:17] the idea is like one place people go to [56:20] do all the things. Is that the general [56:21] idea or TBD? [56:23] >> Yeah. I think what we see here is that [56:26] it's a great home base. It's a great [56:28] place to keep track of all of the things [56:30] that you have to do across different [56:31] surfaces and some of those things you do [56:34] all of it in the app. Some of those [56:36] things the app opens other apps to to do [56:40] right the app can connect to Excel so [56:43] that you know yes it has a spreadsheet [56:45] editor inside the app. Is that good [56:49] enough for people doing financial [56:50] modeling at OpenAI for raising billions [56:53] of dollars? Like probably not. Um, and [56:56] so the app talks directly to the addin [56:59] in Microsoft Excel on your desktop. When [57:02] it's done, you can close Excel, right? [57:03] And so it's not just about, hey, we're [57:05] drawing a rectangle on the screen and [57:07] everything needs to happen in that [57:09] rectangle. It's this thing should be a [57:12] home for you where you start work, you [57:15] end work, you automate work, and it uses [57:18] whatever you need to do. Right? There's [57:20] a there's a great story about we had [57:23] some videos that we shot in this room [57:26] for the original launch of the Codex app [57:28] and our in-house DX videographer Brent [57:32] then was tasked with editing all these [57:34] videos, right? And he edited all the [57:36] videos with Codex which was one of the [57:39] early like whoa what are people doing [57:41] with this thing, right? And the process [57:43] for why he decided to start using Codex [57:45] was really interesting. He started just [57:48] because he was curious if Codex could [57:50] edit videos. And so Codex is not a video [57:52] editor per se, right? It doesn't have [57:54] any of that UI in it, but um it was able [57:58] to understand that he used Premiere Pro. [58:01] It could do some edits by editing the [58:03] files that were backing what was on [58:05] screen in Premiere Pro, but it couldn't [58:07] do everything. So naturally, what Codex [58:09] then did was built itself an extension [58:13] that could be installed into Premiere [58:15] Pro that it could then talk to and say, [58:18] "Hey, Premiere Pro extension, can you [58:20] please change this marker inside of the [58:23] Premiere Pro app." That was pretty nuts [58:25] when we saw that happening. Um, [58:28] it's a great model, right? there are [58:29] these like specialty tools that [58:32] specialize in things and so we're trying [58:34] to do two things at once with Codex and [58:36] with now with chatgbt one is how can we [58:39] seamlessly [58:41] interact with these tools that you're [58:43] already using and say like we don't we [58:44] don't need to build a better video [58:45] editor for you right but like codeex and [58:48] chatd can use that video editor right it [58:50] can interact can hand stuff off to it [58:52] right so how can we do that and that's [58:53] often through um connectors or computer [58:56] use or even extensions in this case [58:58] right And then there is, you know, Dan [59:01] Shepard's thing, which is, hey, I have [59:03] these web apps that you can click around [59:06] and use, but I want to be able to open [59:08] these in codecs and have codeex do extra [59:11] stuff with it, right? And so those are [59:13] kind of like two models that are almost [59:14] inverse of each other that we're doing a [59:16] lot with both at the same time. [59:18] >> This premiere story is interesting to me [59:21] because it's another example of just be [59:23] more ambitious with these AI jobs. Like [59:25] you may may not know, maybe they could [59:27] do this thing. It's almost just like go [59:29] try go try out see if it figures it out. [59:31] I'm going to take us to a recurring [59:33] corner on the podcast that I call fail [59:35] corner. [59:36] And so the question for you is people [59:39] see people like you just like killing [59:41] it, just growing. Everything's winning. [59:43] Codeex is doing so great. This crazy [59:45] career, everything's up and to the [59:48] right. People may not see the times that [59:51] things didn't work out and things that [59:52] you launched that were failures. And so [59:54] these stories are really important for [59:55] people to hear that it's not all just a [59:57] win all the time. What's a story of a [60:00] time you failed in your career that [60:02] taught you something really important? [60:03] It's funny to hear that description [60:05] played back at me and like this is [60:08] perhaps the first time I've I've not [60:10] felt like I was failing. I mean, I was a [60:12] startup founder for a long time. I ended [60:15] up selling the company for parts [60:18] essentially, right? And it was just it [60:20] was years. It was a slog. It was heavily [60:22] regulated spaces. The whole thing felt [60:25] like a constant failure. Um I went to [60:28] this other startup and we were trying to [60:31] do some AI tools and in this also like [60:34] pretty locked down regulated industry [60:37] and that felt like just time after time [60:39] of trying things and it not working. So [60:41] to me it's been like I've failed [60:43] actually quite a lot and you know [60:44] sometimes it's just a point in time [60:46] where things line up like skill set [60:48] passion point in the market line up we [60:53] know with this project to bring what [60:56] we've learned with the codeex app and [60:58] marry it with chachi bt there have been [61:02] I don't know how many micro failures on [61:04] this where we're like this is the shape [61:05] it should look like and then throw that [61:08] in slack and there's like a 2,000 [61:10] message thread about how stupid we are [61:12] and it's like that this is the thing I [61:14] love about opening eye is people will [61:15] just tell us that right there's there's [61:17] no uh there's no holding back on like [61:20] when we fail with product things [61:21] internally it's why the external product [61:23] has been pretty great is because it goes [61:25] through these cycles of like [61:27] >> 2000 this sucks [61:28] >> I failed for like I don't know somewhere [61:31] between 10 and 15 years before getting [61:33] to this point so I'm still surprised [61:35] every day that things are going well [61:36] like and I know it I like but [61:38] >> I think this is really important for [61:40] people to [61:41] that you can have a lot of things not [61:43] work out and then things start to work [61:44] out super well and it's just keep going [61:46] and keep learning I imagine is is a [61:48] lesson. Well, with that we're uh we [61:50] reached our very exciting lightning [61:51] round. I've got five questions for you. [61:53] >> Great. Here we go. Uh what are two or [61:56] three books that you find yourself [61:58] recommending most to other people? [61:59] >> See man, I'm I'm a parent now. I'm a [62:01] parent of young kids, so I I'm like I [62:04] don't know. There's one called The Gruff [62:06] to my kids. I Oh my god. Our kid just [62:09] got obsessed with the Gruff. [62:10] >> Yes. [62:10] >> Uh we have like a a bedtime chart and [62:13] now it's like pajamas, brush teeth, [62:15] books, gruff uh on blankie. [62:18] >> Yeah. [62:18] >> Yeah. It's so good. [62:19] >> So other books I'm reading right now are [62:21] like that style. I'm like actually The [62:23] Gruff is not a terrible one. I feel like [62:25] there's some less. [62:26] >> So sweet. Yeah. Although every kids book [62:28] is about death. Like someone's eating [62:30] someone, someone's killing. There's [62:31] always like bad like murder. [62:34] >> Yeah. Yeah. And and destruction [62:36] >> like violence [62:37] >> even when it doesn't feel like violence [62:38] to them that like the words that there's [62:40] like [62:40] >> it creates like an arc and excitement. [62:42] >> Yeah. [62:42] >> Yeah. Okay. Great choice, Gruffle. [62:44] >> I currently have a book backlog. I I [62:46] need like I need to read all of them. [62:49] >> Any other children's books that that [62:50] your kid likes? [62:52] >> Okay. So, yes, actually um I am well [62:54] versed on children's space. My favorite [62:57] children's book ever is a very old one [63:00] and it's called The Big Orange Spot or [63:03] some something along those lines. Look [63:05] it up. It's great. Go get it. Um if you [63:07] hate HOAs, go get it. It's about um this [63:11] guy, Mr. Plumbing, who lives on a street [63:13] where all the houses are the same. It's [63:15] very neat street and then one day a bird [63:17] drops a large can of orange orange paint [63:20] on his house and he says, "F it." Like [63:22] I'm going all in. So he goes to the [63:24] store, he gets paint, hammocks, [63:26] alligators, and he like totally redo his [63:28] house, and the neighbors like they're up [63:30] in arms, right? Like, you know, HOA [63:32] property value, whatever, whatever. Um, [63:34] it's not about HOAs, but I very anti-HOA [63:37] person. It's just really cool. And then [63:38] like one by one, the neighbors go talk [63:40] to them, have uh what they refer to as [63:43] lemonade, but like it's a very [63:44] convincing lemonade because one by one, [63:45] they all start redoing their house. Like [63:47] one guy does like a boat, right? I think [63:50] I think that's a good book. I think [63:51] people need to read this when they're [63:52] especially, you know, newbies. [63:54] >> What I hear from this is agency. [63:56] >> Agency. Exactly. You can just do things. [63:59] >> Just do things. Amazing. Okay, we'll [64:01] keep going. Uh favorite recent movie or [64:03] TV show you really enjoyed if you've had [64:05] any time. [64:05] >> So, The Magic School Bus is back um on [64:08] Netflix. It's It's a new animated. It's [64:10] got Kate McKinnon because Miss Frizzle [64:12] is now Professor Frizzle and she's, you [64:14] know, around but she's not the main [64:16] Frizzle now. Kate McKinnon plays the [64:17] main Miss Frizzle. Yeah, I always liked [64:19] the magic school bus. [64:21] >> I've never used it. [64:24] >> Personally, like I don't have time for [64:26] movies. So, what I do is watch hourong [64:29] Netflix things back to back. You know [64:31] that thing that people do like [64:33] >> Oh, I couldn't sit I couldn't sit down [64:35] and watch a whole movie and then like [64:37] watch hourong episodes and keep Yeah, [64:39] >> I did. Some There's something addicting [64:40] about that. [64:41] >> Favorite product you've recently [64:42] discovered that you really love. [64:44] >> What was a terrible answer? I feel like [64:46] I'm discovering our product every day. [64:49] Beautiful. [64:50] >> That's so [64:50] >> I think linear linear does a great job. [64:52] Like linear until until this linear was [64:56] like my favorite at least software [64:59] product. [64:59] >> Is that what you guys used to to plan [65:01] in? [65:01] >> Well, in theory. [65:03] >> Do you have a favorite life motto that [65:05] you find yourself coming back to in work [65:06] or in life? I want to ask everyone who [65:08] works with me this because I I I feel [65:11] like I'm not a motto person and then [65:14] people tell me stuff I say all the time. [65:16] >> Yeah. Like when we were chatting ahead [65:17] of this, there's so many little nuggets [65:19] that stood out to me that I've [65:20] integrated into this chat. So I I [65:22] totally hear that. Okay, last question. [65:24] You've been a PM, you've been a [65:26] designer, you've been an engineer. Which [65:29] is the toughest role of the three? Which [65:32] is like the hard to start a war? [65:35] >> Yes. I know. I I think they're all very [65:38] different. I the things that make it [65:40] tough for one person make it easy for [65:43] others. There's a lot there's so much so [65:47] many takes on this and like this triad. [65:50] What's going to happen with this triad? [65:51] Like designers are done or like should [65:53] designers code? Are PMs cooked? Like are [65:57] engine do we not need engineers anymore [66:00] because PMs are going to write all the [66:01] code? Or are designers going to PM now? [66:03] And like everybody's cooked and [66:05] everybody's so back and I don't know [66:08] like there's some convergence. There's [66:11] some fluidity that is being introduced [66:13] that I think is refreshing and great [66:16] especially for people with agency that [66:18] want to be able to just like do the [66:20] thing that needs to get done. Um and at [66:22] the same time like we talked about there [66:24] are some things that shouldn't go away [66:26] but I think people should find the stuff [66:28] that's worth working on and go figure [66:30] out what to do on those things. That is [66:32] a beautiful way to end it. Andrew, thank [66:34] you so much for being here. [66:35] >> Thank you. Bye everyone. [66:38] Thank you so much for listening. If you [66:40] found this valuable, you can subscribe [66:41] to the show on Apple Podcasts, Spotify, [66:44] or your favorite podcast app. Also, [66:46] please consider giving us a rating or [66:48] leaving a review as that really helps [66:50] other listeners find the podcast. You [66:52] can find all past episodes or learn more [66:54] about the show at lennispodcast.com. [66:58] See you in the next episode. [67:01] I love that thing about Brent in the [67:03] Premiere. [67:04] >> Yeah, [67:04] >> that's cool. I've actually used edit [67:07] edits as well. It's basically [67:09] >> simple stuff like, oh, could you just [67:11] cut this into the three breaks, you [67:14] know, like if there's a pause in [67:16] conversation like the second and CEX [67:19] understands it. Basically, every job we [67:22] feel like starts with a story like this, [67:23] which is the product's not designed for [67:25] it, but it's sort of a blank chatbot [67:28] that can write code. So, it can do [67:30] everything, but like what [67:32] >> what are the useful things for it to do, [67:34] >> right? I mean, people just have to have [67:35] curiosity about the project. They they [67:38] have to, [67:39] >> you know, have an in an intentional [67:41] outcome and use codeex as the platform [67:43] for that just to see what happens, [67:46] >> you know, because there's no risk at [67:47] all, [67:48] >> right? just a few tokens. [67:49] >> Few tokens. [67:50] >> But of course, if you're working for [67:52] OpenAI, there's less risks on that [67:54] regard. [67:55] >> Yeah. You asked um [67:58] >> one of them like what or a lot of them [67:59] actually like what skills are important [68:01] and like then then you've also had [68:03] conversations about like the cracked new [68:05] grad versus the [68:06] >> like [68:07] >> I don't know if you're married to the [68:10] exact process you have right now like [68:13] that. I don't know what advice to ever [68:15] give, but if there's one piece, it's [68:16] like do not get married to your exact [68:19] process. Get married to like the [68:22] outcomes that you are uniquely able to [68:24] deliver [68:25] >> and then do things like change your [68:26] process to try things. Like [68:28] >> you just keep [68:29] >> I'm the best at understanding Figma auto [68:31] layout like [68:32] >> right [68:33] >> what are you doing, [68:33] >> right? Cuz AI is going to be better at [68:35] that also. [68:36] >> You just keep spouting interesting [68:38] things. [68:38] >> Keep it in. It's crazy the level of [68:40] self-awareness that's required to like [68:43] be successful with AI. [68:45] >> It is. [68:45] >> Yeah. [68:46] >> It's also why I'm nervous to ever say [68:48] like this is how something's going to be [68:49] cuz I think about like my parents are [68:52] open-minded people. They are into their [68:53] careers but just like the stuff that [68:56] works here is just not going to it's not [68:57] going to work with everybody. There's no [68:59] nice way of saying that, [69:00] >> you know, but like the people who are [69:02] here are self- selecting for [69:05] like, oh, I'm somebody who just figures [69:07] out the next thing to do and that's just [69:09] not like most of the population will not [69:11] be an early adopter of things. [69:13] >> And there's also just like it's kind of [69:14] like a a bummer to have to relearn [69:17] things all the time. Yeah. [69:18] >> You know, it's like god damn it [69:19] >> just to learn a new thing again. [69:21] >> Yeah. Like I I hate repetition. This is [69:23] like a me thing. I don't. This is why [69:26] I'm like not ever the best media person [69:28] either cuz I just like I hate repeating [69:30] myself. [69:31] >> Perfect. [69:31] >> Um sucks to be a founder when you hate [69:33] repeating yourself cuz you you like have [69:35] to [69:35] >> repeater and chief. [69:36] >> Um and so like to me I'm like if I can [69:38] come in and do my job in a different way [69:40] every day. Love it. [69:42] >> But like that's not [69:44] >> You found product market fit for your [69:45] job. [69:46] >> Yes. Yeah. No, that's how that's I like [69:49] can't negotiate because I'm like well I [69:51] don't want other jobs. [69:53] Amazing, [69:55] man.