You’ve probably felt it—that creeping dread that AI is coming for your job. Every day, some new tool writes code, designs interfaces, ships features. And if you’re a product manager, the old script is crumbling: learn to code they said. Build the roadmap they said. Manage the engineers they said.
But what if that advice is not just outdated—what if it’s actively wrong?
I spent the last week inside a single interview that changed how I see AI product work. Andrew Ambrosino, the product lead behind OpenAI’s Codex, sat down with Lenny’s Podcast and dropped a quiet bomb. It wasn’t about prompts or APIs. It was about something far more unsettling: the real job of an AI product manager has nothing to do with coding.
Let me say that again: AI PMs don’t need to become engineers. They need to become judgment architects.
Here’s why. At OpenAI, anyone—marketing, legal, finance, video production—can now build working prototypes. Codex is used by non-engineers daily. Implementation is no longer scarce. The bottleneck isn’t building. It’s deciding what to build. And that changes everything.
1. When Implementation Collapses, PMs Become Editors of Abundance
Andrew points out that the old product playbook assumed code was expensive. So you researched, documented, designed, prototyped, and finally fought for engineering resources. That assumption is dead. Now, give anyone enough tokens and a strong model, and they’ll ship 10 versions of the same idea by lunch.
The result? Not faster delivery—but version chaos. Too many directions, too many half-finished experiments, all of them technically working. The PM’s job shifts from getting things built to deciding which things survive.
“In a world of abundance, the product manager isn’t a resource allocator—they’re an editor with surgical taste.”
You’re no longer fighting for engineering time. You’re fighting for clarity. Which direction converges? Which prototype adds real value vs. long-term complexity? Which gets promoted to the main product, and which stays in the sandbox?
2. The PRD Isn’t Dead—It Just Needs to Prove Its Worth
Everyone loves to shout “PRD is dead!” Andrew disagrees. He says the medium must serve the problem. If the team lacks shared understanding, a document is still the best tool. If you need to test an interaction hypothesis, build a prototype.
The real skill for an AI PM? Choosing the right artifact for the right question. Not defaulting to prototypes because they’re easy. Not hiding uncertainty in a 50-page doc. Ask: what is missing right now? Consensus? Feedback? System boundaries? Alignment?
“The mature PM doesn’t write more docs or more prototypes—they know which one the moment demands.”
3. Taste Is Not a Luxury—It’s Your Operating System
Andrew talks about “taste” without apology. But he doesn’t mean font choices. He means the ability to look at 10 working demos and know which one fits the system, which one respects user mental models, and which one will age well. Taste, in his words, includes system thinking, direction judgment, interaction semantics, and knowing what something should become.
When you can build anything, the only differentiator is what you choose not to build. That choice is taste. And it’s trainable: study great products, deconstruct failures, map user causality.
“AI gives you answers. Taste gives you the questions worth asking.”
4. Design Process Is Dead—But Phase Awareness Isn’t
Andrew doesn’t mourn the old linear design process. But he warns against throwing away phase consciousness. When everything can be built in an afternoon, teams lose track of where they are: is this exploration? Validation? Production candidate? Everything starts to look like a final product because the prototype is polished.
Solution: tag every artifact with its current question. This prototype answers “does the concept make sense?” Not “is this ready to ship?”.
“The most dangerous artifact is the one that looks finished but isn’t. Label everything with its stage.”
5. Roles Blur—But Don’t Cancel Them
Yes, at Codex, designers code, PMs write code, engineers have product sense. But Andrew is clear: don’t use this as an excuse to eliminate roles. Each discipline carries decades of hard-won practice. The future isn’t “everyone is a builder”—it’s porous boundaries with deep craft.
What happens to the PM who only writes specs and tracks Jira? They vanish. What survives? The PM who defines problems, understands users, makes systemic trade-offs, and aligns the organization—all while respecting the designer’s visual judgment and the engineer’s architectural wisdom.
“Don’t be a PM who hides behind boundaries. Be a PM who knows when to step across them—and when to step back.”
6. Roadmaps Should Be Near-Concrete, Far-Abstract
Andrew’s advice: short-term, specific; long-term, fuzzy. Never pretend you know what 9 months out looks like with precision, especially in AI. Model capabilities shift overnight. He gives a stunning example: Codex v1 would have failed if launched three months earlier—same product, weaker model, different outcome.
Your backlog shouldn’t just be features. It should include hypotheses waiting for model maturity. Write down: the value, the current blocker, the capability threshold needed. Then revisit when the model crosses that line.
“The best AI product managers don’t predict the future—they leave room for it.”
7. The Best Features Are Hidden in Weird User Behavior
OpenAI’s video team used Codex to control Premiere Pro. Not a planned feature. They twisted a developer tool into a video assistant. That weird, off-label usage became a signal. Andrew says: watch how your users misuse your product. Those are the seeds of new workflows.
Don’t only track main paths. Track prompts, workarounds, copy-paste escapes. Users aren’t just consuming features—they’re inventing workflows.
“Your users are your best product strategists. Listen to the strange ways they break your tool.”
What This Means for You
If you’re an AI PM today, the old rulebook is burning. Implementation is cheap. Prototypes are abundant. The scarce resource is judgment—knowing what to build, when, to what degree, and how to fit it into a stable system.
You don’t need to become a coder. You need to become someone who can navigate noise, stage decisions, define taste, and choose the right medium for the right moment. You need to be comfortable not building, but editing.
So here’s the question that keeps me up at night—and it should keep you up too:
“When building is cheap, what will you use to prove you’re building the right thing?”
FAQ
Q: Do AI product managers really need to learn to code?
A: No. The hot take that 'PMs must code' is a red herring. The real value shifts to judgment, taste, and system design. Coding helps you communicate, but it's not the core differentiator.
Q: What's the practical takeaway for my day-to-day work?
A: Stop defaulting to prototypes or PRDs. Before starting any artifact, ask: what question are we answering? Is it consensus, feedback, or alignment? Choose the medium that serves that question. Label every artifact with its stage—exploration, validation, or production candidate.
Q: Isn't 'taste' just a buzzword? How do you train it?
A: Taste is not magic. Break down great products: why does this interaction feel right? Study failures: where did the system get too complex? Map user mental models. The more you practice connecting design decisions to user causality, the sharper your taste becomes.