AI Made Code Cheap. It Made Product Judgment Expensive.

Where this started

On Lenny's Podcast — the episode "OpenAI Codex lead on the new shape of product work," with Andrew Ambrosino, released June 28, 2026 (https://x.com/lennysan/status/2071294324999115057) — Ambrosino relays something he's hearing: some companies say they're getting rid of the product role entirely, on the theory that everyone will just be a builder. Ambrosino's own worry is about a collapse — where everyone is everything, and nobody owns anything.

I want to be straight about the source. The transcript excerpt cuts off mid-thought. It surfaces the observation and the worry; it does not carry the argument all the way to a demonstrated downside. So take what follows as a risk framework built from that observation, not as something the clip proves. The claim I'll defend is narrower and, I think, harder to dodge: cheap building doesn't delete the deciding job — it relocates the cost and hides it.

Two costs wearing one name

Product work has always been two stacked costs. First, deciding what to build. Second, building it. For thirty years the second cost dominated. Implementation was slow and expensive, so companies organized around engineering throughput. The PM was the cheap layer that fed the expensive machine: figure out what's worth building, hand it down.

AI code generation collapsed that second cost toward zero. An engineer with a coding agent can stand up a working product surface alone, in an afternoon. So it looks like the PM — the person who used to translate intent into a spec for the expensive machine — is now overhead.

Here's the move people miss. When you make one term of a two-term bottleneck much cheaper, the bottleneck doesn't vanish. It moves to the term you didn't touch. Cheap implementation doesn't kill the need for good decisions. It makes good decisions the scarce thing. The two costs didn't disappear. They traded places, and the person whose whole job was the deciding just got rarer, not redundant.

That's the whole argument. The rest of this is about why the deciding half doesn't spread evenly across a team the way the building half does, and what it costs you when you assume it will.

Why deciding needs an owner and building doesn't

This part usually gets waved at instead of explained, so let's do the mechanism.

Building a login form is decomposable. You can split it — one person does the frontend, one does the auth backend — and the pieces recombine cleanly, because there's an objective spec they're all building toward. The form either accepts a password or it doesn't. Correctness is a fact, so independent work converges on its own.

Deciding whether login should gate the whole app or just the paid tier is not like that. There's no external fact to check the answer against. The right answer depends on which customer you're willing to lose, how much friction the funnel can eat, what the sales team already promised. Every person on the team carries a private model of those tradeoffs in their head. And here's the structural bit: if there's no shared source of truth, N people build against N different private models and produce N incompatible specs — each internally reasonable, none compatible with the others. Nothing in the system forces them to converge, because there's no fact to converge on.

That's why contested tradeoffs need a single arbiter and login forms don't. The arbiter isn't there because they're smarter. They're there to be the shared source of truth — one head where the tradeoff gets resolved once, so everyone downstream builds against the same answer. Take that owner away and you haven't distributed the decision. You've deleted the thing that made the decision one decision instead of several.

The failure this predicts — and why you won't see it

Picture a flat team that dissolves its PM role. Everyone can build now, so everyone builds. Each engineer implements the onboarding flow they think is right. Nobody's dumb; each person vibe-codes against their own private read of the user. With no shared source of intent, you get multiple incompatible answers to a single question. The problem isn't skill loss. It's duplicated surface area with no arbiter — exactly what the mechanism predicts.

Now the cruel part. Build velocity holds steady, or even improves, after you remove the PM. That's the number everyone watches, so everyone concludes it worked. The cost lands somewhere else: contested calls now resolve by Slack attrition — whoever argues longest, or whoever merges first while everyone's asleep. Building stays fast. Deciding gets slow and noisy.

Be careful here, because it's tempting to invent a stat. There's no measured figure for how much decision-latency rises, and neither does anyone throwing one around have one. Treat it as a hypothesis you can test on your own team, not a finding. Velocity is visible, decision-latency isn't, so you optimize the number you can see and ship the damage in the number you can't.

Where the deleted work actually goes

The PM function produces specific artifacts: a single prioritized backlog, the "why aren't we building X" memo, the customer-interview synthesis, the written "we're not doing this" rationale. Delete the title and these don't disappear. They get done badly and in fragments by whoever has the fewest Slack messages that day.

And they get taxed onto your best engineers. Whoever is most senior tends to become the de facto PM — context-switched, uncredited, spending real coding hours defending the roadmap and saying no to sales instead of building. You didn't remove the cost. You converted a batched cost into a fragmented, invisible, larger one, paid by the people you least want doing it. A cost that used to live in one calendar now lives scattered across five, which is strictly worse, because context-switching has overhead and batching removes it.

Why AI can't backfill this one

You might think: fine, the agent can do the deciding too. It can't, and the reason is structural, not temporary.

Supervised learning needs a target — a labeled right answer to score against and pull toward. That's why coding agents got good fast: code has a target. It compiles or it doesn't; tests pass or they don't. The signal is objective and stable, so the model has something to converge on.

Arbitrating a product tradeoff has no such target. "Which customer should we abandon" has no ground-truth label, and worse, the answer that's right this quarter is wrong next quarter when the market moves. You're asking a model to learn a function whose output is a subjective judgment against a target that keeps moving. There's no stable signal to fit. This is the same reason that, in many current workflows as of mid-2026, frontier models are still weak at design taste — the thing being judged is a moving, subjective call, and supervised learning is built for fixed, objective ones. So AI deepens the need for the deciding function at the exact moment it looks like it removes it. Only one of the two costs actually got cheap.

The honest counterpoint

Here's where I have to be fair, because the flat, PM-less model is genuinely real and sometimes genuinely great.

Some flat teams ship fast with zero PMs and thrive. But look at why, and it's usually one of these. The founders are themselves ex-PMs, so the judgment is embedded in their heads rather than absent from the team. Or the team is tiny — under about eight people — so the shared source of truth fits in one room and one Slack channel without a named owner. Or they're building for people exactly like themselves, which collapses the user-research gap to zero.

In every one of those cases the deciding function is present. It's just invisible, the way good infrastructure is. Which raises the honest test for anyone reading this on a flat team: is your team flat because the judgment is embedded, or flat because nobody's holding it? Those look identical from the velocity dashboard and could not be more different underneath. Nobody proved the "no-PM" model fails — the evidence for that is thin, and the teams that died aren't writing threads about it. What you can prove is that the function can't be deleted. The org chart is up to you.

Two structures that actually hold

Once you accept the function survives, the real question sharpens. It's not "PM or no PM." It's whether the function needs a dedicated human box or can live as a role plus a ritual. Two versions hold up.

The sequencer. Keep the flat structure, but designate a rotating role — call it the sequencer — that owns convergence. The mechanism matters more than the title: no feature brief ships until the current sequencer signs off on it. This is a product-decision gate, not a code-review gate — the sequencer isn't checking whether the diff is clean, they're checking whether the team is building one answer instead of several. Rotate the role weekly so nobody burns out holding it. The required sign-off preserves convergence, so you don't end up with three teams building three incompatible flows. Distributed structure without deleting the function.

The shape doc. The rule: no feature ships without a named owner writing the customer story first, in an async shape doc, before any code. Then point the AI at that doc as a devil's-advocate reviewer — make it argue against the plan before you build. This is the PM function wearing a hoodie, and that's fine. The point was never the org chart. The point is that someone owns the intent.

The one distinction to carry away

"Everyone's a builder" confuses tool democratization with responsibility democratization. The coding agent writes code for everyone. It does not decide which customer segment you're abandoning. Give everyone the tool. Don't pretend that spreads the responsibility — because responsibility doesn't split cleanly across N people. It has an owner, or it silently evaporates.

Do this tonight

• Measure the invisible number. Pick your last three contested features and clock time-to-decision. For each one, find the message or ticket where the question was first raised, find the message where the call was finally made and nobody kept arguing, and count the hours between them. Do that for all three and look at the trend. If it's creeping up while build velocity looks fine, that's your signal. You're not proving a law here, you're checking one on your own data.

• Set a real decision gate. Name this week's sequencer in your team doc today, and adopt one rule: no feature brief ships until they sign off. It's the product-decision gate as an actual rule, not a title — and rotate the name next week.

• Add the shape-doc rule. No feature ships without a named owner writing the customer story first, and run the AI over that doc as devil's advocate before anyone builds.

So — is your team flat because the judgment is embedded, or flat because nobody's holding it? One quick way to tell: who wrote the last "we're not doing this" rationale? If you can't name that person, you don't have a flat team. You have an unowned one. Worth finding out which, before the incompatible flows show up.