Andrew Ambrosino, product and engineering lead for the Codex desktop app at OpenAI, describes how AI is inverting the traditional product development process: implementation is now cheap and abundant, while taste, curation, and judgment have become the scarce, high-leverage skills. Codex usage has grown 6× since January 2025, with over 5 million weekly active users and nearly 100% internal adoption across all functions at OpenAI.
The inversion of product work
Implementation is no longer the expensive part of software development; taste and curation are.
At OpenAI, giving everyone unlimited tokens led to 90+ uncoordinated prototype explorations for a single needed feature, whereas the old process relied on documents and research to de-risk expensive implementation.
Roles haven’t disappeared, but the workflow is backwards: people build first, then curate. The core challenge is deciding which of the many prototypes to fold together, how to frame them, and what to ship.
Everyone at OpenAI is “agentic” and builds; the bottleneck is not capacity but coherence.
Documents vs. prototypes: picking the right medium
Prototypes are not universally better than documents; the medium must match the goal.
Use documents for product clarity around vague areas; use prototypes to stress-test interaction patterns and get something in users’ hands.
The old signal baked into mediums (a polished prototype meant late-stage, de-risked work) is gone. Now a prototype can look production-ready while still being an early exploration.
Taste includes knowing which medium to use for a given decision.
What “taste” means in practice
Taste is not just aesthetics; it includes systems thinking (how a piece fits the whole), strategic framing (what theme this serves), and judgment about goals and trade-offs.
It covers interaction details (animation timing matching semantic meaning) and the deeper question: “If we can build anything, what should we build and how do we get there?”
This judgment is now the most important skill in every field.
Why AI is still bad at design
Design is harder to grade than code: code either compiles and passes tests, while design requires human taste as part of the feedback loop.
Labs historically invested in coding ability because it directly accelerates AI research; design was not in that flywheel.
Deeper challenges: design values novelty and cultural context (not just known patterns), and requires an abstraction layer linking visual design to shared code semantics (e.g., a rebrand should propagate through shared components, not 263 one-off edits).
These abstraction and novelty problems remain out of reach for current models.
The design process: dead or transformed?
The formal “design process” (research → divergence → convergence → prototype) was predicated on implementation being expensive and single-shot. That assumption is broken.
Speed of implementation lets you pull real code into the process, not just Figma prototypes. Teams now use “baby” versions of the product (simplified codebases) to explore interactions rapidly.
The process isn’t dead, but tying it to specific tools/media is dangerous. The overlay — knowing what stage you’re in and what question you’re answering — matters more than ever.
On the Codex team, designers write code, PMs write code, and engineers do product work. Roles are defined by the average of where someone spends time, not by rigid boundaries.
Team structure: role collapse and zone defense
The Codex team has double-digit engineers, roughly half that many designers, and a few product people. The whole company (research, infra, etc.) effectively contributes.
“Zone defense” for product: product people spread out to cover gaps, avoid overlapping too closely, and steer from inception to coherence. They hire engineers with product sense so not everything needs central review.
IC vs. management: everyone is both now. ICs manage agents and workstreams; managers do the same at a different granularity. The key hire is high-agency, high-taste people who can take an idea from concept to done.
Planning roadmaps in a fast-moving world
Short-term plans get detail; long-term plans (9 months out) stay hazy — precision there is false precision.
Product planning fell down when features depended on model capability leaps. The working approach: list ambitious ideas, prototype all, ship what works now, let the rest bake, and re-test with each model jump.
The Codex app released in February 2025 would have failed if released in November 2024 with the same shape; only the model improved.
Building features that don’t work yet
Build ambitious features before models can fully support them, but be clear they are artifacts for future testing, not shippable products.
Example: in-app browser / computer use appeared in Operator, Atlas, ChatGPT, and Codex — same core idea, different outcomes as models improved.
Lesson: don’t be stubborn that a feature is bad because it fails today; it may just be early. You may release the same shape six times before it works.
The ambition problem: being too “AGI-pilled”
The Codex web launch was too agentic/delegative for the model capability at the time; Claude Code’s more interactive, local approach worked better.
Product teams must balance ambition with the current capability ceiling. The shape may not change, but the timing of release relative to model intelligence determines success.
Culture of bottom-up exploration is essential: the next disruptive form factor will come from within, not from optimizing the current product.
Latest frontier: loops and autonomous development
“Loops” (autonomous agents improving the codebase overnight) are being explored but not yet reliable.
Models currently increase complexity; they struggle to delete code and build correct abstractions.
Teaching models which features to build, how to group requests, and how to design abstractions is the unsolved problem.
Not yet at “set up a loop that listens to Slack/Twitter/email and improves the app,” but actively working toward it.
How Andrew uses Codex for his own job
Personal dogfooding loop: made Codex good enough to build Codex, then used it for product discovery (spreadsheets, deep research, release coordination).
Automates daily briefs from 3,000+ Slack channels, coaches the agent iteratively (“next time de-emphasize this workstream”).
Built a spam-filter automation that used computer use to navigate Google Cloud Console and set up Pub/Sub triggers.
The app acts like an open-ended agent: you describe the automation, it sets up connectors or uses computer use to click through UIs.
Vision for Codex: a home base, not just a dev tool
Internal PMF emerged across all functions (marketing, finance, legal) even though the app was “actively hostile” to non-engineers (showing code, asking for RG approvals).
Attempts to put Codex into other surfaces (ChatGPT desktop, Atlas) failed: nobody would leave the Codex app.
Insight: the distinction between “developer tool” and “general knowledge work tool” is false. The right model is a home base that starts simple, grows complex as needed, and uses modes for legibility.
Codex connects to specialized tools (Excel, Premiere Pro, browsers) via connectors, computer use, or custom extensions — it doesn’t need to replace them.
Example: a videographer built a Premiere Pro extension so Codex could edit markers inside Premiere; Codex didn’t need to become a video editor.
Failure corner
Andrew spent 10–15 years failing (startup sold for parts, regulated-industry AI startup) before things clicked at OpenAI.
Internal product failures are constant: 2,000-message Slack threads calling new ideas stupid. That friction is why the external product is good.
Lesson: keep going, keep learning; a long run of things not working can precede a breakthrough.
Lightning round highlights
Favorite children’s book: The Big Orange Splot (anti-HOA, pro-agency).
Favorite product: Linear (until Codex).
No fixed life motto; colleagues say he repeats “don’t get married to your process, get married to outcomes you uniquely deliver.”
Toughest role of PM/designer/engineer: all different; convergence and fluidity are increasing, but specialties with best practices shouldn’t be discarded. People should find work worth doing and figure out how to do it.
