Concise Summary简洁概述
OpenAI's Codex team runs on almost no process: specs cap at ~10 bullets, roadmaps skip the middle distance entirely, and a 50-100 person team had one PM until recently.
This works because the team is its own user — developers building for developers — which collapses the coordination overhead that normally justifies PMs, specs, and roadmaps.
OpenAI Codex 团队几乎不依赖流程：spec 最多 10 个要点，规划直接跳过中期，50-100 人的团队长期只有一个 PM。
这套方法之所以成立，是因为团队本身就是自己产品的用户——开发者为开发者构建产品，从根本上消解了通常需要 PM、spec、路线图来化解的协调成本。
Infographic信息图
10-bullet specs, not 10-page docs
10 个要点的 spec，而非十页文档
Codex barely writes specs; when multi-person coordination is unavoidable, the doc still caps at ~10 bullets. The premise: since AI agents absorb most coding work, one person's scope expands enough that fewer people need to sync at all — 'let the person closest to the metal decide.'
Codex 团队几乎不写正式 spec，只有涉及多人协调时才写，且长度控制在约 10 个要点。前提是：大部分编码工作已能委派给 AI Agent，一个人能独立处理的范围随之扩大，需要协调的人自然变少——核心原则是「让离金属最近的人做决策」。
Near-term or long-term, never medium
只做近期或远期，从不做中期
OpenAI's internal rule: plan concrete 8-week sprints, or hold a directional 'vibes' sense of a year-plus future — skip the roadmap in between. This only works because model capability shifts fast enough that medium-term plans go stale before they ship.
OpenAI 内部规划哲学是：要么做 8 周以内的具体冲刺目标，要么做一年以上的方向性「感觉」判断，中间的产品路线图基本不存在。这套方法成立的前提是模型能力变化极快，中期计划还没落地就已经过时。
A 50-100 person 'pirate ship'
50-100 人的「海盗船」
Codex ran with a single PM until recently, deliberately minimizing cross-functional handoffs and reporting layers. It works because the team builds developer tools while being developers themselves — the classic dog-fooding condition that removes the need for translation between user and builder.
Codex 团队长期只有一位 PM，刻意维持极低的跨职能协调和极简的汇报结构，即所谓「海盗船」式运作。这之所以行得通，是因为团队本身就是自己产品的用户——开发者为开发者构建工具，天然省去了用户与构建者之间的翻译环节。
Design for power users, then simplify
先为高阶用户设计，再做简化
Because the Codex core is open source, cutting-edge users fork it and enable unshipped features before the team decides how to expose them — turning power-user behavior into a live signal for what to build next, then layering simplicity on top like game-level unlocks.
因为 Codex 核心开源，最前沿的用户会直接 fork 源码启用未发布的功能，团队据此观察真实使用方式，再决定如何将其简化并逐层开放给普通用户，就像游戏一样层层解锁。
Detailed Summary详细解读
The interview's headline numbers — a 10-bullet spec, one PM for 50-100 people, no medium-term roadmap — read as productivity flexes, but they're downstream of a single structural fact: Codex's builders are its users. Alex frames this explicitly through 'let the person closest to the metal decide,' arguing that AI agents have expanded what one person can independently explore, shrinking the population that needs to sync. This isn't a general claim about AI making teams leaner; it's a claim that holds specifically when the gap between builder and user is already near zero.
The planning philosophy — near-term sprints of 8 weeks or less, long-term 'vibes,' nothing in between — is presented as an OpenAI-wide rule, attributed to an internal researcher's advice. Its logic depends entirely on model capability being unpredictable at the 3-6 month horizon. A medium-term roadmap becomes a bet on a moving target you can't see; better to commit to a short concrete sprint or a loose directional guess. But this assumes capability gains keep arriving at the current cadence — the piece itself flags that if progress slowed, the whole justification for skipping the middle distance would weaken.
The Codex desktop app's origin story is the piece's best concrete evidence: a viral photo of a developer running ~18 terminal windows in parallel signaled unmet demand, GPT-5.2 Codex's December 2025 release crossed a capability threshold enabling long, autonomous task execution, and the team debated whether a standalone app was even necessary before shipping one built on a shared Rust core with the CLI and IDE extension. The launch trajectory — 1M+ developers in the first month, 2M+ weekly active users by March 2026 — grounds the abstract management philosophy in a real product outcome, which is what elevates this from a generic 'AI makes teams faster' anecdote.
The PM debate is where the piece is most careful to avoid overclaiming. Alex's position — PM is a 'fill-in-the-gaps' role, not a leadership position, and can be collapsed if you're already your own user — is immediately qualified: teams that aren't close to their users, or that are large enough, may still need someone dedicated to that gap, whether or not the title is 'PM.' Romain's Stripe comparison (250 employees, zero PMs, pre-dating any AI tooling) is used to isolate the real variable: distance from the user, not AI capability per se, is what determines PM necessity.
The piece's closing move is its sharpest contribution: it names the tension the interview subjects themselves gesture at but don't fully resolve. As OpenAI pushes Codex toward ChatGPT's 900M users and positions it as the entry point to the entire developer platform, the builder-equals-user shortcut that justifies minimal specs, no PM, and no medium-term roadmap starts to erode. Alex's own hedge — 'PM is just a label' — reads less like a resolution and more like a deferral of a question the team hasn't had to answer yet.
访谈中的标志性数字——10 个要点的 spec、50 到 100 人团队一个 PM、不做中期路线图——乍看是效率上的炫技，但其实都源于一个结构性事实：Codex 的构建者就是它的用户。Alex 明确用「让离金属最近的人做决策」来概括这一点，主张 AI Agent 扩大了个人能独立探索的范围，从而缩小了需要协调的人群。这不是一个「AI 让团队变精简」的普遍论断，而是一个只有在构建者与用户之间的鸿沟已经接近于零时才成立的特殊结论。
这套「8 周以内做近期冲刺，一年以上做方向性感觉判断，中间不做规划」的哲学被描述为 OpenAI 全公司的通行做法，来源于一位内部研究员的建议。它的逻辑完全依赖于一个假设：3 到 6 个月尺度上的模型能力变化不可预测。中期路线图因此变成了对一个看不清的移动目标下注，不如直接押注一个具体的短期冲刺，或者维持一个宽泛的方向性猜测。但这一切都建立在能力提升会持续以当前节奏到来的假设上——文章本身也指出，如果进展放缓，跳过中期规划的整套理由都会站不住脚。
Codex 桌面应用的诞生过程是文章中最具体的证据：一张开发者同时运行约 18 个终端窗口的照片在社交媒体上广泛传播，暴露了未被满足的需求；2025 年 12 月发布的 GPT-5.2 Codex 跨过了支持长时间自主任务执行的能力门槛；团队甚至在内部争论是否真的需要一个独立 app，最终推出的产品与 CLI、IDE 插件共用同一套开源 Rust 核心。发布后首月超百万开发者使用、到 2026 年 3 月周活跃用户超两百万的数据，把这套抽象的管理哲学落到了具体的产品结果上，这也是本文超越「AI 让团队更快」这类泛泛之谈的关键。
关于 PM 存废的讨论，是全文最克制、最不轻易下结论的部分。Alex 的立场——PM 不是领导岗位而是「填补空缺」的岗位，如果团队本就是自己产品的用户，这个岗位就可以被工程师和设计师吸收——随即被他自己限定：如果团队离用户较远，或者规模足够大，可能仍然需要专人负责理解用户，无论这个人是否叫 PM。Romain 举的 Stripe 例子（250 名员工零 PM，且早于任何 AI 工具出现）用来分离出真正的变量：决定 PM 是否必要的，是团队与用户的距离，而非 AI 能力本身。
文章结尾是全文最锐利的部分：它点出了访谈双方自己有所触及、但并未真正解决的张力。当 OpenAI 把 Codex 推向 ChatGPT 的 9 亿用户，并将其定位为整个开发者平台的入口时，支撑「极简 spec、无需 PM、不做中期路线图」的「构建者即用户」这一捷径开始动摇。Alex 自己那句「PM 只是一个标签」，与其说是一个解答，不如说是把一个团队目前还没被迫回答的问题暂时搁置了。
FAQ常见问答
Why doesn't Codex's minimal-spec approach collapse under coordination failures?为什么 Codex 的极简 spec 做法不会导致协调失败？
Because coordination need scales with builder-user distance, not team size. Codex engineers and PMs are developers building developer tools, so most decisions can be made locally without translation between roles.
因为协调需求取决于构建者与用户之间的距离，而非团队规模。Codex 的工程师和 PM 本身就是开发者，在为开发者构建工具，多数决策可以就地做出，不需要跨角色翻译。
Does the 'no medium-term roadmap' rule assume AI progress never slows down?「不做中期路线图」的规则是否假设 AI 进展永远不会放缓？
Yes, implicitly. The rule's justification is that 3-6 month capability is unpredictable; if progress plateaued, medium-term plans would become forecastable again and the case for skipping them would weaken.
隐含地，是的。这条规则的理由是 3 到 6 个月尺度的能力发展不可预测；如果进展放缓，中期计划会重新变得可预测，跳过它的理由也会随之削弱。
Is Stripe's 250-person, zero-PM structure comparable to Codex's situation?Stripe 250 人零 PM 的结构和 Codex 的情况可比吗？
Partially — both share the 'team is its own user' condition, but Stripe achieved it without any AI tooling, which suggests the real driver is builder-user proximity, not AI-enabled productivity per se.
部分可比——两者都满足「团队即自己产品的用户」这一条件，但 Stripe 是在没有任何 AI 工具的情况下做到的，说明真正的驱动因素是构建者与用户的贴近程度，而非 AI 带来的生产力提升本身。
What happens to this management model as Codex expands beyond developers?当 Codex 扩展到开发者以外的用户时，这套管理模式会怎样？
The piece flags this as the key open risk: once users are unfamiliar with the product's domain, the team can no longer rely on being its own user, and Alex himself concedes more PM-like work may be needed.
文章将此列为最主要的未解风险：一旦用户不再熟悉产品所在的领域，团队就无法再依赖「自己就是用户」这一条件，Alex 本人也承认那时可能需要更多类似 PM 的工作。
Is 'PM is a fill-in-the-gaps role' a general claim about the profession, or specific to Codex?「PM 是填空岗位」是关于这个职业的普遍论断，还是仅适用于 Codex？
Alex frames it as general, but his own caveats — team size, user distance — narrow it back to conditions Codex happens to meet, making it more a description of Codex's situation than a portable rule.
Alex 将其表述为普遍论断，但他自己给出的限定条件——团队规模、与用户的距离——又把它收窄回 Codex 恰好满足的特定条件，因此这更像是对 Codex 现状的描述，而非一条可以照搬的通用规则。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece dissects a Behind the Craft interview with OpenAI Codex's product lead and dev-experience lead, extracting a set of management practices that only make sense once you see the load-bearing assumption underneath them.
本文拆解了 Peter Yang 对 OpenAI Codex 产品负责人和开发者体验负责人的一次访谈，从中提炼出一套管理实践，并指出这套实践背后有一个不易察觉但至关重要的前提假设。
- Concrete product evidence有具体产品案例支撑The Codex desktop app origin story (viral 18-terminal photo, GPT-5.2 threshold, shared Rust core, real adoption numbers) grounds abstract management claims in a traceable, falsifiable product outcome.Codex 桌面应用的诞生过程（18 个终端窗口的传播照片、GPT-5.2 能力门槛、共用 Rust 核心、真实的采用数据）把抽象的管理主张落到了可追溯、可验证的产品结果上。
- Self-aware caveats from the subjects受访者本身有自省性限定Alex repeatedly qualifies his own claims — PM necessity depends on team size and user distance, medium-term planning depends on capability unpredictability — rather than presenting them as universal rules.Alex 反复对自己的论断加上限定条件——PM 是否必要取决于团队规模和与用户的距离，中期规划的取舍取决于能力发展的不可预测性——而不是把它们当作普适规则来宣扬。
- Named comparison case (Stripe)引入了可比较的对照案例（Stripe）Romain's Stripe example isolates builder-user proximity as the real variable behind the zero-PM structure, independent of AI tooling, strengthening the causal claim rather than letting it rest on Codex alone.Romain 举的 Stripe 例子分离出「构建者与用户的贴近程度」这一真正变量，证明零 PM 结构与 AI 工具无关，让因果论断不必只依赖 Codex 这一个案例。
- Structural framing over feature listing聚焦结构性归因，而非功能罗列The piece resists treating the interview as a grab-bag of tips, instead organizing every practice around one load-bearing precondition — which is a stronger editorial move than most 'lessons from X team' write-ups.文章没有把访谈处理成一堆零散技巧的罗列，而是围绕一个承重的前提条件来组织所有实践，这比多数「某团队的经验」类文章的编辑立场要更强。
- Single-source, self-reported claims单一信源，且为自述All numbers and characterizations come from the two subjects themselves, with no independent verification of team size, PM count, or internal deliberations — flattering self-narrative risk is real.所有数字和描述都来自两位受访者本人，团队规模、PM 人数、内部决策过程均无独立验证，存在美化自述的风险。
- Survivorship bias in the 'AI reduces coordination' claim「AI 减少协调需求」的论断存在幸存者偏差Codex succeeding with minimal process doesn't establish that AI agents generally reduce coordination needs — it may simply be that a team already primed for low coordination (dev tool for devs) adopted AI well.Codex 用极简流程取得成功，并不能证明 AI Agent 普遍降低了协调需求——更可能的解释是，一个本就适合低协调运作的团队（为开发者做开发工具）恰好很好地采用了 AI。
- The 900M-user tension is raised but not resolved9 亿用户带来的张力被提出却未解决The piece correctly flags that Codex's expansion toward ChatGPT's broad user base threatens the builder-equals-user premise, but neither the interview nor the analysis offers evidence for how this will actually play out.文章准确指出 Codex 向 ChatGPT 广泛用户群扩展会威胁「构建者即用户」这一前提，但无论是访谈本身还是本文分析，都没有给出这一趋势将如何实际演变的证据。
- Time-bound snapshot of a fast-moving situation快速变化局势下的时间快照Adoption figures, team structure, and the 'no medium-term roadmap' rule reflect a specific moment (April 2026); given Codex's stated trajectory toward mass consumer use, these specifics may already be dated by the time this is read.采用数据、团队结构以及「不做中期规划」这条规则反映的是一个特定时间点（2026 年 4 月）的状态；考虑到 Codex 明确表示要走向大众消费者，这些具体细节到读者阅读时可能已经过时。
Worth reading for anyone managing a small, technically homogeneous team building tools for people like themselves — the pirate-ship model is a genuine, evidence-backed alternative to spec-heavy process. But treat the 'PM is obsolete' and 'no medium-term roadmap' claims as conditional on that homogeneity, not as general lessons for teams whose users differ from their builders.
如果你在管理一个技术背景高度同质、为「和自己一样的人」构建工具的小团队，这篇文章值得一读——海盗船模式是一种有真实证据支撑的、对重流程 spec 的替代方案。但「PM 已过时」「不做中期路线图」这类论断，应被理解为建立在这种同质性条件之上的结论，而非适用于构建者与用户不同的团队的普遍经验。
Original Text原文
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
The OpenAI Codex team's product spec document has only 10 bullet points. That's not to say each feature's documentation has only 10 bullet points—the entire product's spec is that short. Designers write more code than engineers did six months ago. A team of 50 to 100 people only got its second product manager recently.
These figures come from Alexander Embiricos, head of product for OpenAI Codex, and Romain Huet, head of developer experience. The two spoke in detail on Peter Yang's Behind the Craft show about how the Codex team builds products using their own product, why medium-term roadmaps don't work at OpenAI, and how the PM role may be shifting from "leader" to "gap-filler."
Original video: https://www.youtube.com/watch?v=9qXc-THAvc0
Alexander Embiricos (hereafter Alex) is Codex's head of product, with five years of prior experience building pair-programming products as a founder. Romain Huet is OpenAI's head of developer experience, previously head of developer platform product at Stripe.
Key takeaways:
The Codex team almost never writes product spec documents—only when multi-person coordination or major decisions are involved, and even then it's usually just 10 bullet points long
OpenAI's internal planning philosophy is to only plan near-term (within 8 weeks) or long-term (a sense of direction), and never a medium-term product roadmap
The launch of GPT-5.2 Codex in December 2025 was a key turning point—the model's capability crossed the threshold of being able to work independently and reliably for long stretches, directly giving rise to the Codex desktop app
The Codex team deliberately operates like a "pirate ship"—a team of 50-100 people went a long time with just one PM, and cross-functional coordination is minimal
Alex believes the PM role isn't a leadership position but a "gap-filling" one—and that in the AGI era, the most important human qualities are curiosity and agency
10 bullet points are enough
Peter Yang got straight to the point: do you still write specs?
Alex's answer was blunt: the Codex team almost never writes product spec documents. They only write one when a problem is too complex for a single person to hold in their head and requires coordination across multiple people. And even then, it's astonishingly short.
"We write very, very few specs on the Codex team. We're talking like 10 bullets or something, and then that's it."
He explained the logic behind this: since most coding work can already be delegated to AI agents, the scope one person can handle has expanded enormously. Things that once required three people to coordinate can now be explored by a single person using Codex. The core principle is "let the person closest to the metal make as many decisions as possible."
Romain added a more concrete example. He demonstrated Codex's plan mode live on the show: given an in-progress iOS app project and no specific instructions, just asking "what should we do next?", Codex automatically analyzes the state of the codebase and proposes several directions for a human to choose from.
This scenario reveals a new way of working: product planning is no longer humans thinking things through first and then writing a document—instead, humans and AI agents explore possibilities together at the code level.
PMs use AI for "thought exploration," then share the thinking with engineers
Alex described three modes in which he, as a PM, uses Codex.
For simple changes, he just dives in directly, using Codex to generate code, write tests, and submit a PR (pull request).
"For a small change, it's often faster to send a PR than it is to communicate to someone and get them to prioritize that task when they have 10,000 other things to do."
For medium-complexity changes, he has Codex draft an implementation plan first.
The most interesting is the third mode: sometimes he has a vague idea, without even having worked out the specific feature, and he'll just talk to the model directly inside Codex, letting it explore the codebase, ask questions, and generate proposals. He often doesn't actually use these proposals, because the changes are too complex for him to plan to maintain himself. But through this process he gains a better understanding of the problem, and then shares that understanding—rather than the plan itself—with engineers.
In Alex's own words: "I'm not writing code, I'm building a mental model."
On the designer's role, Alex said:
"The designers on the Codex team write more code now than was written by an engineer six months ago."
He went on to say that team members joke about the number of PRs he's submitted. He didn't reveal a specific number, only saying "it really should be more." But he thinks that's no longer the point. The key question now isn't "can you generate code" but rather "are you choosing to do the right thing" and "how do you ensure quality."
He specifically pointed out that although the vast majority of the Codex team's code is generated by AI agents, they invest heavily in systems thinking and quality control. Vibe coding can be used to say "the whole app was written by AI," but that's not how the Codex team operates.
Only plan near-term and long-term, never medium-term
Peter Yang asked: do you have an annual roadmap?
Alex said neither. He mentioned advice given to him by an OpenAI internal researcher named Andre:
"At OpenAI, you either plan near-term or long-term, but you never plan medium-term."
Near-term means within 8 weeks—8 weeks at most—and it needs to be a concrete goal the team can rally around and focus on. Short-cycle team sprints like this are exactly what OpenAI excels at.
Long-term is more of a "feeling." For example: a year from now we'll have smarter models, users won't want to lend their own computer to a model (since that only allows one thing to be done at a time), there will be an unlimited number of models working independently and in parallel, verifying their own results, even deploying and monitoring their own code, and users may not need to actively type prompts at all.
What about the middle stretch—the product roadmap? Basically nonexistent. What they have is a long-term direction plus specific projects they believe will push them toward it.
This planning approach assumes that model capability is changing rapidly. When you're not sure what the model will be able to do three months from now, a medium-term roadmap turns into guesswork. But that assumption itself is worth questioning: what if model progress slows down?
The birth of the Codex App: from 18 terminal windows to one desktop app
Alex used the development of the Codex App to illustrate how this planning method plays out in practice.
Long-term vision: users need an interface that makes multi-agent collaboration feel natural. It can't be tied to a specific folder or IDE (for example, VS Code can only open one workspace at a time), because in the future users will delegate multiple tasks to multiple agents at once.
The problem emerged: after GPT-5.2 Codex launched in December 2025, model capability crossed a critical threshold—it could take on longer, more complex tasks and finish them in one go. Users started running large numbers of Codex sessions simultaneously using tmux (a terminal multiplexer). A widely circulated photo appeared on social media: Peter Steinberger running roughly 18 terminal windows of Codex across three monitors at once.
GPT-5.2 Codex launched in mid-December 2025 and was OpenAI's most capable coding model at the time, supporting long independent work sessions and large-scale code changes. According to OpenAI's official figures, Codex's overall usage doubled after the launch.
But Alex realized that only the top 1% of engineers would work this way, in parallel across terminals. How could this be made intuitive for everyone?
There was actually internal debate about this: the IDE extension was already popular—should they just focus on making that great? There was strong demand for the CLI too. Did they really need a standalone desktop app?
What ultimately got the project greenlit wasn't a spec, but a document explaining "why we think building an app is a good idea." The app's actual shape took form gradually during the building process.
Romain added a key technical detail: the Codex App, IDE extension, and CLI all share the same open-source Rust core underneath (the Codex harness), which lets the three product forms share code and capabilities.
The Codex App officially launched in February 2026, first supporting macOS before expanding to Windows. According to OpenAI data, over 1 million developers used Codex in the month it launched. As of March 2026, Codex has more than 2 million weekly active users.
Let the most cutting-edge users pull you into the future
Alex talked about a core principle of Codex's product design: build configurability for power users first, then simplify for ordinary users.
Because Codex's core is open source, users go straight into the source code to modify it. Alex shared something that actually made him happy: before the team had even shipped a certain feature to production, people on Twitter were already complaining that the feature was hard to use. Users had forked the source code themselves and enabled the unreleased feature on their own.
He sees this as a product advantage: the most cutting-edge users are exploring the future together with the team. How they actually use the product is itself a signal of product direction. Take sub-agents, for example—Codex already supports this at the underlying level, and users can enable and experiment with it themselves, but the product layer doesn't proactively trigger it yet. The team is watching how users use it before deciding how to simplify it.
"The cutting edge of your users are just absolutely living in the future with us and pulling us into that future."
But Alex also admitted that if you build only for these users, the product becomes very hard to understand. So their design philosophy is: keep the core interaction extremely simple—in his words, "make the product nearly invisible, and let the model's capability show through naturally"—and then let power users discover the deeper features themselves through layering. He used an analogy: using the Codex App is like playing a game, unlocking features layer by layer.
A "pirate ship" of 50-100 people
Peter Yang asked: you're Codex's only PM, and the team has 50 to 100 people—what does your day look like?
Alex said he didn't know how to answer that question at first, but after thinking about it he realized he has a few different "modes."
Execution mode: before a product launch, he uses Codex heavily—to catch up on Slack feedback, to have Codex summarize feedback and post it to Linear (the project management tool), to understand the state of the codebase, and to submit code changes directly through Codex. He said one sign of whether he's in execution mode is how much he's posting on Twitter. Posting a lot = being in launch rhythm.
Coordination mode: when planning new directions, he spends more time thinking and communicating, and uses Codex more for writing text than for writing code.
The team deliberately operates with low friction. Alex said they "deliberately act like a pirate ship," with minimal cross-functional coordination. They only got a second PM recently. Most people are engineers, and the reporting structure is extremely flat.
But he also mentioned an emerging challenge: more and more non-technical teams inside OpenAI are now using the Codex App for non-coding work too. This means Codex's positioning is expanding from a "developer tool" toward something more general-purpose, which requires more cross-functional coordination with the ChatGPT team.
In April 2026, according to Reuters, competitive pressure from Anthropic's Claude Code pushed OpenAI to shift more resources toward Codex and enterprise tools. In a recent interview with Sources, Codex product lead Alex said the ultimate goal is to bring the Codex agent to ChatGPT's 900 million users.
Developer experience: Codex becomes the gateway to all developer platforms
Romain added another observation from the developer experience angle. His team now positions Codex as the entry point to OpenAI's entire developer platform, not just for coding.
A year ago, when OpenAI launched GPT-5, they had to hand-write a mountain of guides to teach developers how to use the new model's reasoning capabilities. Now their strategy has changed: they teach developers directly to use Codex together with the corresponding Skill (a skill plug-in) to complete integrations. Whether you want to hook up Imagen (image generation), Sora (video generation), or Speech-to-Speech (voice conversation), Codex can be the starting point.
He also mentioned an example: a friend used Codex's Linear Skill to automatically turn a pile of product ideas into Linear tasks, then before going to bed told Codex, "Go implement all of these." The next morning when he woke up, they were all done.
On the community-building side, they've already built a network of Codex ambassadors across multiple cities and countries, with local developers spontaneously organizing events and teaching sessions. Alex added that the best part of the Codex team is this community. Because the project is open source, the team has become very transparent to the outside world, and the community reciprocates with active participation.
Peter Steinberger: from "never gonna use it" to primary tool
Talking about Peter Steinberger joining OpenAI, Alex shared a story. In October 2025, he and Peter were walking at Fort Mason in San Francisco. He didn't directly say the team was considering building a standalone app, but started tentatively talking about "some kind of new interface that makes delegation feel natural." Peter's reaction at the time was: he would never use something like that. Recently, Peter posted on Twitter that the app was "actually pretty good."
Peter Steinberger is an Austrian developer, creator of OpenClaw (formerly named Clawdbot, Moltbot). OpenClaw is an open-source personal AI assistant that can autonomously operate apps, browsers, calendars, and more. Steinberger joined OpenAI in February 2026 to help drive the development of the "next-generation personal agent." The OpenClaw project was moved to an independent foundation, remaining open source.
Romain added a deeper observation. Throughout 2025, Peter built more than 40 open-source projects, each centered on the same vision: building command-line interfaces for everyday tools (calendar, Twitter, Gmail). These projects looked scattered, but they actually all point in one direction: making the coding agent not just something that writes code, but a general-purpose personal agent that can operate every digital tool.
Alex didn't reveal much about Peter's specific work at OpenAI, only saying he's helping build the "next-generation personal agent, integrated into ChatGPT."
PM isn't a leadership role, it's a gap-filling role
This was the most contentious part of the whole session. Peter Yang asked directly: do we still need PMs?
Romain answered first, offering a gentler framing: the boundaries of all roles are blurring. The traditional division of labor between engineers, designers, and PMs is losing its meaning. Designers can now write code, PMs can build prototypes, and engineers can talk directly with users.
Alex was more direct.
"I don't actually view PM as a good leadership position. I view it as a fill-in-the-gaps position."
He admitted he may have said somewhere that "if a startup has a PM before it reaches 20 engineers, that's a red flag."
His chain of reasoning goes like this: AI tools let everyone do a slice of someone else's job. Engineers previously didn't have time to do task triage and project management because they needed to concentrate on writing code. Now that writing code can be delegated to agents, engineers have more time. What Scott Belsky (Adobe's Chief Strategy Officer) called the "collapsing of the talent stack" is happening.
"I think the fewer people you need in a room to do anything, just the better that thing goes. The more pure every decision is."
Scott Belsky is Adobe's Chief Strategy Officer and Vice President of Design and Emerging Products, and the founder of Behance. "Collapsing the talent stack" is a concept he proposed in 2023, whose core idea is: having one person cover the functions of multiple roles (for example, a chief designer also making product decisions) is more effective than adding coordination staff.
But Alex then drew a distinction. He thinks some PMs should switch careers outright: if you always wanted to be an engineer and only became a PM because you were good at managing, then now with coding agents you can just "delete yourself from the PM role" and become an engineer instead. Likewise, if you'd rather do design, go do design.
But if what genuinely interests you is spending a lot of time with users and understanding where the market is heading, and your team is big enough, then there may still be room for a PM.
He closed with: every problem needs someone accountable, but that person doesn't necessarily have to be a PM.
Romain offered a counterexample: Stripe reached 250 employees with zero PMs, without any AI tools at all. The reason is simple — they were all engineers, building the kind of API they themselves had always wanted, and everyone knew what an elegant API looked like.
This example illustrates a precondition: how much you need PMs is related to how close you are to the user. If you yourself are the user of your own product, the value of a PM drops. The Codex team happens to be in exactly that position.
"Show me what you built"
The last topic was hiring. Alex's standard can be summed up in one word: agency.
He described the onboarding experience on the Codex team: there's no list of tasks with increasing difficulty, just a "welcome," and then you go find things to do yourself. What he wants is someone who proactively spots problems, doesn't mind overturning existing decisions, and is willing to take on any unfamiliar territory.
When looking at job applications, he prioritizes the links and ideas someone sends. If someone writes a pile of self-introduction and a resume, he probably won't finish reading it. He says he genuinely has no idea what schools his team members graduated from.
"I'm so glad we live in a world where all these stupid credentials don't matter anymore. Who cares? Show me what you built."
Romain added the hiring criteria for the developer experience team: strong technically, skilled with tools, and at the same time loves being with the developer community and enjoys teaching others. He mentioned they'd just announced that Thomas (creator of the open-source project Codex Monitor) would be joining his team.
Thomas is Thomas Ricouard (@Dimillian), a well-known open-source developer who built Codex Monitor, an open-source monitoring app built with Codex, for Codex. Romain confirmed the hire on Twitter.
Alex summed up the DevX team's job description in one line: "Really good at writing code, and also really good at using Twitter." Romain added a qualifier with a laugh: in Europe and other regions, developers might be more active on LinkedIn or other platforms, so a more accurate phrasing would be "performs well on social media."
Closing thoughts
The most valuable information from this interview isn't Codex's product features, but the structural precondition it exposes: the Codex team's extremely lean management style — barely writing specs, one PM for a team of 50, running the ship pirate-style — rests on a special set of conditions. Both Alex and Romain explicitly acknowledged this: they are users of their own product, their users are also developers, and they have an extremely active open-source community providing continuous feedback. Romain's Stripe example is the same.
When Codex's ambition is to "bring the coding agent to ChatGPT's 900 million users," will this approach still hold up? Alex himself mentioned that when a product faces user groups it's unfamiliar with, it may need more PM-type work. But he then dissolved the question with "PM is just a label."
Another tension worth continuing to watch is Codex's evolution toward a general-purpose agent. Alex mentioned that non-technical teams inside OpenAI are already using the Codex App for non-coding work, and Romain positioned Codex as "the entry point to all developer platforms." Reports from April 2026 show that OpenAI is building Codex as the foundation of a unified desktop "super app," integrating ChatGPT and the Atlas browser. When a coding agent product's users expand from "people who write code" to "everyone," the complexity of product decisions changes qualitatively. Does the principle of "letting the person closest to the metal make the decision" still apply in that world?
Alex says what he values most is interest and agency. Both qualities have indeed become more important in the AI era. But the judgment that "PM is a gap-filling role" may itself be a conclusion that only holds under specific conditions — and the Codex team happens to be positioned exactly where that conclusion looks most correct.
Original video: https://www.youtube.com/watch?v=9qXc-THAvc0
Q&A
Q: What does the Codex team use instead of product spec documents? A: Engineers make decisions directly at the code level, using Codex's plan mode to talk through options with the model; only complex problems involving coordination across multiple people get a minimal written doc.
Q: How does OpenAI do internal product planning? A: Concrete sprint goals within an 8-week horizon, plus directional judgment ("vibes") for anything beyond a year, with no roadmap in between.
Q: Is there still a need for PMs? A: Alex thinks it depends on whether your team is a user of its own product. If so, the traditional functions of a PM can be absorbed by engineers and designers. If not, someone may still need to dedicate time to understanding users — but that person doesn't have to be called a PM.
Q: How does the Codex team hire? A: They look at work, not resumes; agency, not credentials. Onboarding has no list of tasks with increasing difficulty — it's just "welcome, go find something to do."
Q: What is Peter Steinberger doing at OpenAI? A: Helping build the next-generation personal agent product and integrating it into ChatGPT. Specific details haven't been made public yet.
OpenAI Codex 团队的产品规格文档只有 10 个要点。不是说每个功能的文档只有 10 个要点，而是整个产品的 spec 就这么多。设计师写的代码量超过了六个月前工程师写的。50 到 100 人的团队，直到最近才有了第二个产品经理。
这些数字来自 OpenAI Codex 产品负责人 Alexander Embiricos 和开发者体验负责人 Romain Huet。两人在 Peter Yang 主持的 Behind the Craft 节目中，详细讲述了 Codex 团队如何用自己的产品构建产品，为什么中期路线图在 OpenAI 行不通，以及 PM 这个岗位可能正在从“领导者”变成“填空人”。
原始视频：https://www.youtube.com/watch?v=9qXc-THAvc0
Alexander Embiricos（下文简称 Alex）是 Codex 的产品负责人，此前有五年结对编程产品创业经验。Romain Huet 是 OpenAI 开发者体验负责人，此前在 Stripe 担任开发者平台产品负责人。
要点速览：
- Codex 团队几乎不写产品规格文档，只有涉及多人协调或重大决策时才写，而且往往只有 10 个要点的长度
- OpenAI 内部的规划哲学是只做近期（8 周以内）或远期（方向感），永远不做中期产品路线图
- GPT-5.2 Codex 在 2025 年 12 月发布是关键转折点，模型能力跨过了"可以可靠长时间独立工作"的门槛，直接催生了 Codex 桌面应用
- Codex 团队刻意保持“海盗船”式运作，50-100 人的团队长期只有一个 PM，跨职能协调极少
- Alex 认为 PM 不是领导岗位，而是”填补空缺”的岗位，在 AGI 时代最重要的人类品质是兴趣和能动性
10 个要点就够了
Peter Yang 开门见山：你们还写 spec 吗？
Alex 回答得很干脆：Codex 团队几乎不写产品规格文档。只有在问题复杂到一个人脑子装不下、需要多人协调的时候才会写。而且即使写了，也短得惊人。
我们在 Codex 团队写的 spec 非常非常少。就算写，也就十来个要点，就这样了。 （“We write very, very few specs on the Codex team. We're talking like 10 bullets or something, and then that's it.”）
他解释了背后的逻辑：既然大部分编码工作已经可以委派给 AI Agent，一个人能处理的范围就大了很多。过去需要三个人协调的事情，现在一个人用 Codex 就能探索清楚。“让离金属最近的人做尽可能多的决策”是核心原则。
Romain 补充了一个更具体的例子。他在节目上直接演示了 Codex 的 plan mode（规划模式）：给 Codex 一个正在开发的 iOS 应用项目，不给任何具体指令，只说“我们下一步该做什么？”Codex 会自动分析代码库现状，提出几个方向让人类选择。
这个场景揭示了一种新的工作方式：产品规划不再是人类先想清楚再写文档，而是人和 AI Agent 一起在代码层面探索可能性。
PM 用 AI 做”思维探索”，然后把思考分享给工程师
Alex 描述了自己作为 PM 使用 Codex 的三种模式。
简单改动直接上手，用 Codex 生成代码、测试、提交 PR（代码提交合并请求）。
对于一个小改动来说，直接提一个好的 PR，往往比找人沟通、让他们在一万件事情里把这件排上优先级要快得多。 （“For a small change, it's often faster to send a PR than it is to communicate to someone and get them to prioritize that task when they have 10,000 other things to do.”）
中等复杂度的改动，他会让 Codex 先做一个实现计划。
最有意思的是第三种：他有时候有一个模糊的想法，甚至连具体功能都没想好，就直接在 Codex 里和模型对话，让它去代码库里探索、提问、生成方案。他经常不会真的使用这些方案，因为改动太复杂了，他不打算自己维护。但通过这个过程，他对问题有了更好的理解，然后把这份理解（而非计划本身）分享给工程师。
用 Alex 自己的话说：”我不是在写代码，我是在建立心智模型。”
谈到设计师角色，Alex 说：
Codex 团队的设计师现在写的代码量，超过了六个月前一个工程师写的代码量。 （“The designers on the Codex team write more code now than was written by an engineer six months ago.”）
他接着说，团队成员拿他提交的 PR 数量开玩笑。他没有透露具体数字，只说“确实应该更多”。但他认为这已经不是重点了。现在的关键问题不再是“你能不能生成代码”，而是“你选择做的事情对不对”以及“你怎么保证质量”。
他特别指出，虽然 Codex 团队绝大多数代码是由 AI Agent 生成的，但他们在系统思考和质量把控上投入了大量精力。凭感觉编程（vibe coding）可以用来说“整个 app 是 AI 写的”，但 Codex 团队不是这么运作的。
只做近期和远期规划，永远不做中期
Peter Yang 问：你们有年度路线图吗？
Alex 说两样都不是。他提到一个 OpenAI 内部研究员 Andre 给他的建议：
在 OpenAI，你要么做近期规划，要么做远期规划，但永远不要做中期规划。 （“At OpenAI, you either plan near-term or long-term, but you never plan medium-term.”）
近期是 8 周以内，最多 8 周，而且要是一个具体的目标，团队能够围绕它集中发力。OpenAI 擅长的就是这种短周期的团队冲刺。
远期是一种“感觉”。比如：一年以后我们会有更聪明的模型，用户不会想把自己的电脑借给模型用（因为那样一次只能做一件事），会有无限多个模型同时独立工作、自己验证结果、甚至自己部署和监控代码，用户可能根本不需要主动输入提示词。
中间那段呢？产品路线图？基本不存在。他们有的是长期方向加上他们认为能朝那个方向推进的具体项目。
这种规划方法的前提是模型能力在快速变化。当你不确定三个月后模型能做什么，中期路线图就变成了猜测。但这个前提本身就值得追问：如果模型进展放缓了呢？
Codex App 的诞生：从 18 个终端窗口到一个桌面应用
Alex 用 Codex App 的开发过程来说明这套规划方法怎么落地。
远期愿景：用户需要一个界面，让多 Agent 协作变得自然。不能绑定在某个特定的文件夹或 IDE 里（比如 VS Code 一次只能打开一个工作区），因为未来用户会同时委派多个任务给多个 Agent。
问题的出现：2025 年 12 月 GPT-5.2 Codex 发布后，模型能力跨过了一个关键门槛：可以接手更长、更复杂的任务，一次就做完。用户开始用 tmux（终端多路复用工具）同时运行大量 Codex 会话。社交媒体上出现了一张广为流传的照片：Peter Steinberger 在三块显示器上同时开了大约 18 个终端窗口运行 Codex。
GPT-5.2 Codex 于 2025 年 12 月中旬发布，是当时 OpenAI 最强的编码模型，支持长时间独立工作和大规模代码变更。据 OpenAI 官方数据，发布后 Codex 整体使用量翻了一倍。
但 Alex 意识到，只有顶尖 1% 的工程师会用终端并行的方式工作。如何让这件事变得直觉化？
团队内部其实对此有争论：IDE 扩展已经很受欢迎了，要不要就专注做好那个？CLI 也很有需求。真的需要一个独立的桌面应用吗？
最后推动项目启动的不是一份 spec，而是一份说明“为什么我们认为做一个 app 是好主意”的文档。app 的具体形态是在构建过程中逐渐成形的。
Romain 补充了一个关键的技术细节：Codex App、IDE 扩展和 CLI 底层共用同一套开源的 Rust 核心（Codex harness），这让三个产品形态能够共享代码和能力。
Codex App 于 2026 年 2 月正式发布，首先支持 macOS，后扩展到 Windows。据 OpenAI 数据，发布当月有超过 100 万开发者使用了 Codex。截至 2026 年 3 月，Codex 周活跃用户超过 200 万。
让最前沿的用户拉你进未来
Alex 谈到了 Codex 产品设计的一个核心原则：先为 power user 做可配置性，再为普通用户做简化。
因为 Codex 核心是开源的，用户会直接去改源码。Alex 说了一件让他很高兴的事：团队还没把某个功能上线到生产环境，推特上就有人在抱怨这个功能不好用了。用户直接 fork 了源码，自己启用了未发布的功能。
他把这视为产品优势：最前沿的用户在和团队一起探索未来。他们的实际使用方式就是产品方向的信号。比如子 Agent（sub-agents）这个概念，Codex 已经在底层支持了，用户可以自己启用、实验，但产品层面还没有主动触发它。团队在观察用户怎么用，再决定怎么简化。
我们最前沿的用户和我们一起住在未来，还把我们往未来拽。 （“The cutting edge of your users are just absolutely living in the future with us and pulling us into that future.”）
但 Alex 也承认，如果只为这类用户构建，产品会变得非常难理解。所以他们的设计哲学是：核心交互要做到极简，用他的话说就是“让产品几乎隐形，让模型的能力自然显现”，然后通过分层让 power user 自己去发现更深的功能。他用了一个比喻：用 Codex App 就像打游戏，一层层解锁功能。
50-100 人团队的“海盗船”式运作
Peter Yang 问：你是 Codex 唯一的 PM，团队有 50 到 100 人，你每天怎么过？
Alex 说他不知道怎么回答这个问题，想了想发现自己有几种不同的“模式”。
执行模式：在产品发布前，他大量使用 Codex，用它来了解 Slack 上的反馈、让 Codex 总结反馈并发到 Linear（项目管理工具）、用 Codex 理解代码库状态、直接用 Codex 提交代码改动。他说判断自己是不是在执行模式的标志之一是他在推特上发了多少东西。发得多 = 在发布节奏里。
协调模式：在规划新方向的时候，他花更多时间思考和沟通，用 Codex 更多是做文字工作而非写代码。
团队刻意保持低摩擦运作。Alex 说他们”有意识地像一支海盗船”，跨职能协调极少。直到最近才有了第二个 PM。大部分人都是工程师，汇报结构极简。
但他也提到一个正在出现的挑战：越来越多 OpenAI 内部的非技术团队也在用 Codex App 做非编码工作。这意味着 Codex 的定位正在从“开发者工具”向更通用的方向扩展，而这需要和 ChatGPT 团队做更多跨职能协调。
2026 年 4 月，据路透社报道，Anthropic 的 Claude Code 对 OpenAI 构成的竞争压力促使 OpenAI 将更多资源转向 Codex 和企业工具。Codex 产品负责人 Alex 近期接受 Sources 采访时表示，最终目标是把 Codex Agent 带给 ChatGPT 的 9 亿用户。
开发者体验：Codex 成为所有开发者平台的入口
Romain 从开发者体验的角度补充了另一个观察。他的团队现在把 Codex 定位为 OpenAI 整个开发者平台的入口，不只是编码。
一年前，当 OpenAI 推出 GPT-5 时，他们需要手动撰写大量指南来教开发者怎么使用新模型的推理能力。现在，他们的策略变了：直接教开发者用 Codex 加上对应的 Skill（技能插件）来完成集成。不管你是要接 Imagen（图像生成）、Sora（视频生成）还是 Speech-to-Speech（语音对话），Codex 都可以是起点。
他还提到一个例子：一个朋友用 Codex 的 Linear Skill 把一堆产品想法自动写成 Linear 任务，然后睡觉前告诉 Codex：“去把这些任务全部实现。”第二天早上醒来，全部完成了。
社区建设方面，他们已经在多个城市和国家建立了 Codex 大使网络，由本地开发者自发组织活动和教学。Alex 补充说，Codex 团队最好的部分就是这个社区。因为开源，团队变得对外非常透明，社区也以积极参与来回报。
Peter Steinberger：从“永远不用”到主力工具
谈到 Peter Steinberger 加入 OpenAI，Alex 分享了一个故事。2025 年 10 月，他和 Peter 在旧金山的 Fort Mason 散步。他没有直接说团队在考虑做一个独立 app，但开始试探性地聊“某种让委派变得自然的新界面”。Peter 当时的反应是：他永远不会用这种东西。最近，Peter 在推特上发帖说这个 app“还不错”。
Peter Steinberger 是奥地利开发者，OpenClaw（原名 Clawdbot、Moltbot）的创建者。OpenClaw 是一个开源个人 AI 助手，可以自主操作应用、浏览器和日历等。Steinberger 于 2026 年 2 月加入 OpenAI，负责推动“下一代个人 Agent”的开发。OpenClaw 项目转移到一个独立基金会，保持开源。
Romain 补充了一个更深层的观察。Peter 在 2025 年全年构建了超过 40 个开源项目，每一个都围绕同一个愿景：为日常工具（日历、推特、Gmail）构建命令行接口。这些项目看起来零散，但其实共同指向了一个方向：让编码 Agent 不只是写代码，而是成为操控一切数字工具的通用个人 Agent。
Alex 对 Peter 在 OpenAI 的具体工作没有透露太多，只说他正在帮助构建“下一代个人 Agent，整合到 ChatGPT 中”。
PM 不是领导岗位，是填空岗位
这是全场最有争议的部分。Peter Yang 直接问：我们还需要 PM 吗？
Romain 先回答，给出了一个更温和的框架：所有角色的边界都在模糊化。工程师、设计师、PM 之间的传统分工正在失去意义。设计师能写代码了，PM 能做原型了，工程师能直接和用户对话了。
Alex 更直接。
我其实不认为 PM 是一个好的领导岗位。我觉得它是一个填补空缺的岗位。 （“I don't actually view PM as a good leadership position. I view it as a fill-in-the-gaps position.”）
他承认自己可能在某个地方说过“一个创业公司如果在 20 个工程师以下就有 PM，那是红旗信号”。
他的推理链条是这样的：AI 工具让每个人都能做一部分别人的工作。工程师以前没时间做任务分类和项目管理，是因为他们需要集中精力写代码。现在写代码这件事可以委派给 Agent 了，工程师有了更多时间。Scott Belsky（Adobe 首席战略官）提出的“人才栈压缩”（collapsing the talent stack）正在发生。
做任何事情所需的人越少，那件事就做得越好。每个决策都更纯粹。 （“I think the fewer people you need in a room to do anything, just the better that thing goes. The more pure every decision is.”）
Scott Belsky 是 Adobe 首席战略官兼设计与新兴产品副总裁，也是 Behance 创始人。“人才栈压缩”是他在 2023 年提出的概念，核心观点是：让一个人覆盖多个角色的职能（比如首席设计师同时做产品决策），比增加协调人员更有效。
但 Alex 随即做了一个细分。他认为有些 PM 应该直接转行：如果你一直想做工程师，只是因为管理能力不错才做了 PM，那现在有了编码 Agent，你可以直接“把自己从 PM 岗位上删掉”，转做工程师。同理，如果你更喜欢设计，那就去做设计。
但如果你真正感兴趣的是花大量时间和用户在一起、理解市场走向，而且你所在的团队足够大，那 PM 可能还有存在的空间。
他最后补了一句：每个问题都需要一个负责的人，但这个人不一定得是 PM。
Romain 提供了一个对照：Stripe 在没有任何 AI 工具的情况下做到了 250 名员工零 PM。原因很简单，他们全都是工程师，他们在构建自己一直想要的那种 API，每个人都知道一个优雅的 API 长什么样。
这个例子说明了一个前提条件：PM 需求的大小和你离用户的距离有关。如果你就是自己产品的用户，PM 的价值就会下降。Codex 团队恰好处在这个位置。
“给我看你做了什么”
最后一个话题是招聘。Alex 的标准可以用一个词概括：能动性（agency）。
他描述了 Codex 团队的入职体验：没有递增难度的任务列表，就是一句“欢迎”，然后自己找事做。他要的是那种会主动发现问题、不介意推翻现有决策、愿意接手任何未知领域的人。
看求职信息时，他优先看对方发来的链接和想法。如果有人写了一堆自我介绍和简历，他大概率不会读完。他说他完全不知道团队成员是什么学校毕业的。
我很高兴我们生活在一个那些愚蠢的证书不再重要的世界里。管它什么学校呢。给我看你做了什么。 （“I'm so glad we live in a world where all these stupid credentials don't matter anymore. Who cares? Show me what you built.”）
Romain 补充了开发者体验团队的招聘标准：技术强、工具熟练、同时热爱和开发者社区在一起、喜欢教别人。他提到他们刚宣布 Thomas（Codex Monitor 开源项目的创建者）将加入他的团队。
Thomas 即 Thomas Ricouard（@Dimillian），知名开源开发者，构建了 Codex Monitor，一个用 Codex 为 Codex 开发的开源监控应用。Romain 在推特上确认了这一加入。
Alex 用一句话总结了 DevX 团队的岗位描述：“很会写代码，同时很会用推特。”Romain 笑着加了一个限定条件：在欧洲和其他地区，开发者可能更活跃在 LinkedIn 或其他平台上，所以更准确的说法是“在社交媒体上表现出色”。
写在最后
这次访谈最有价值的信息不是 Codex 的产品功能，而是它暴露的一个结构性前提：Codex 团队的极简管理方式，几乎不写 spec、50 人团队一个 PM、海盗船式运作，建立在一个特殊条件上。Alex 和 Romain 都明确承认了这一点：他们是自己产品的用户，他们的用户也是开发者，他们有一个极度活跃的开源社区提供持续反馈。Romain 举的 Stripe 例子同样如此。
当 Codex 的野心是“把编码 Agent 带给 ChatGPT 的 9 亿用户”时，这套方法还能继续有效吗？Alex 自己也提到，当产品面向不熟悉的用户群体时，可能需要更多 PM 的工作。但他随即用“PM 只是一个标签”把这个问题化解了。
另一个值得持续关注的张力是 Codex 向通用 Agent 方向的演变。Alex 提到 OpenAI 内部非技术团队已经在用 Codex App 做非编码工作，Romain 把 Codex 定位为“所有开发者平台的入口”。2026 年 4 月的报道显示，OpenAI 正在将 Codex 作为统一桌面“超级应用”的基础，整合 ChatGPT 和 Atlas 浏览器。当一个编码 Agent 产品的用户从“写代码的人”扩展到“所有人”，产品决策的复杂度会发生质变。“让离金属最近的人做决策”的原则在那个世界里还适用吗？
Alex 说他最看重兴趣和能动性。这两个品质在 AI 时代确实变得更重要了。但“PM 是填空岗位”这个判断，可能本身就是一个只有在特定条件下成立的结论，而 Codex 团队恰好处在让这个结论看起来最正确的那个位置上。
原始视频：https://www.youtube.com/watch?v=9qXc-THAvc0
Q&A
问：Codex 团队用什么方式代替产品规格文档？ 答：让工程师直接在代码层面做决策，用 Codex 的 plan mode 和模型对话来探索方案，只有涉及多人协调的复杂问题才写极简文档。
问：OpenAI 内部怎么做产品规划？ 答：8 周以内的具体冲刺目标，加上一年以上的方向性判断（“vibes”），中间不做路线图。
问：PM 还有存在的必要吗？ 答：Alex 认为取决于你的团队是否是自己产品的用户。如果是，PM 的传统职能可以被工程师和设计师吸收。如果不是，可能还需要有人专门投入时间去理解用户。但那个人不一定要叫 PM。
问：Codex 团队怎么招人？ 答：看作品不看简历，看能动性不看资历。入职没有递增难度的任务列表，就是“欢迎，自己找事做”。
问：Peter Steinberger 在 OpenAI 做什么？ 答：帮助构建下一代个人 Agent 产品，将其整合到 ChatGPT 中。具体细节尚未公开。
See all posts