The OpenAI Codex team’s product specification document has only 10 bullet points. Not 10 bullet points per feature, but for the entire product spec. Designers now write more code than an engineer did six months ago. A team of 50 to 100 people only recently got its second product manager.

These numbers come from Alexander Embiricos, product lead for OpenAI Codex, and Romain Huet, head of developer experience. In Peter Yang’s Behind the Craft show, the two detailed how the Codex team builds products with their own product, why medium-term roadmaps don’t work at OpenAI, and how the PM role might be shifting from “leader” to “gap filler.”

Original video: https://www.youtube.com/watch?v=9qXc-THAvc0

Alexander Embiricos (referred to as Alex below) is the product lead for Codex, with five years of experience co-founding a pair programming product startup. Romain Huet is the head of developer experience at OpenAI, previously serving as product lead for the developer platform at Stripe.

Key Takeaways:

• • The Codex team almost never writes product specs. They only write them when multi-person coordination or major decisions are involved, and even then, they are often only 10 bullet points long.
• • OpenAI’s internal planning philosophy is to only do near-term (within 8 weeks) or long-term (directional sense), and never create medium-term product roadmaps.
• • The release of GPT-5.2 Codex in December 2025 was a key turning point. The model’s capabilities crossed the threshold of being able to reliably work independently for long periods, directly leading to the creation of the Codex desktop app.
• • The Codex team deliberately maintains a “pirate ship” style of operation. A team of 50-100 people had only one PM for a long time, with very little cross-functional coordination.
• • Alex believes that PM is not a leadership position, but a “gap-filling” position. In the AGI era, the most important human qualities are interest and agency.

Peter Yang got straight to the point: Do you still write specs?

Alex answered bluntly: The Codex team almost never writes product specification documents. They only write them when a problem is too complex for one person’s mind and requires multi-person coordination. And even when they do write them, they are surprisingly 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 now be delegated to AI Agents, the scope one person can handle is much larger. Things that used to require coordination between three people can now be explored by one person using Codex. “Let the person closest to the metal make as many decisions as possible” is the core principle.

Romain added a more concrete example. He directly demonstrated Codex’s plan mode during the show: give Codex an iOS app project under development, without any specific instructions, just say “What should we do next?” Codex will automatically analyze the current state of the codebase and propose several directions for humans to choose from.

This scenario reveals a new way of working: Product planning is no longer about humans thinking things through first and then writing documents, but about humans and AI Agents exploring possibilities together at the code level.

PMs Use AI for “Thought Exploration,” Then Share Insights with Engineers

Alex described three modes he uses as a PM with Codex.

For simple changes, he does them directly, using Codex to generate code, test, 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 create an implementation plan first.

The most interesting is the third mode: Sometimes he has a vague idea, not even a specific