Keith Rabois went on Lenny's Podcast last week and didn't hedge:
"the idea of a PM makes no sense basically in the future... That world is ridiculous... intermediaries like conventional PMs don't make a lot of sense"
In his version of the role, product managers take inputs, produce roadmaps, manage a year at a time. When capabilities shift week to week, that whole setup stops making sense to him. Intermediaries don't earn their keep.
Two months earlier, same podcast, Boris Cherny from Anthropic made what sounds like the opposite prediction:
"I think by the end of the year everyone is going to be a product manager, and everyone codes. The title software engineer is going to start to go away. It's just going to be replaced by builder, and it's going to be painful for a lot of people."
On the face of it, these are opposite claims. Rabois says the PM disappears. Cherny says the software engineer disappears into the PM, and everyone becomes one.
Read past the contradiction, though, and the mechanism is the same on both sides. Each title has always covered very different versions of the role. One version is being automated. The other, the one that was already doing the real work, is what survives.
Then Rabois, a few minutes later, sketches what replaces the old PM: the skill is more like being a CEO now, which is what are we building and why. Lenny pushes back immediately. That's what a great PM has always been really good at. It's also what Cherny's "builder" is trying to name from the engineering side. Someone who decides what's worth making, makes it, and gets it in front of a user, without needing a committee to authorise each step.
Two titles, the same converging shape. AI is chewing through one version of each role while leaving the other exposed.
Which version of each role survives
Both titles have always covered several different jobs under the same word.
On the PM side, Marty Cagan has been drawing this line for over a decade. There was the feature-team PM: writing tickets, refining backlogs, chasing alignment, compiling roadmaps, sitting in the middle between engineering and the business and translating between them. And there was the empowered PM: the person who sees what customers don't realise they need, decides what's worth building, defines what success looks like before the work starts, and knows when to stop. Same title. Very different jobs.
On the engineering side, the same fork. John Cutler named this one nearly a decade ago: the feature-factory engineer, picking up the story, shipping it, closing the loop, moving to the next one. In it for the points. And there was the product engineer, the "engineer with commercial instincts" that every hiring manager claims they want and few companies reward. The one who read the support queue before writing the feature, who pushed back on the PRD because the design didn't match how customers actually behaved, who spotted the obvious thing nobody had thought to add.
The feature-team PM and the feature-factory engineer were often the default. The empowered PM and the product engineer existed, but they tended to exist in spite of the system rather than because of it. Coordination work got measured and rewarded. Tickets closed and sprints hit were visible; the decision not to build the feature that nobody actually needed was invisible. The visible version of each role paid off in visible output. The other version paid off only much later, if at all, and often by absence: the six months you didn't waste on the thing that wouldn't have worked. Nobody celebrates what didn't happen.
When Rabois says PMs don't make sense, he's picturing the feature-team PM. When Cherny says the software engineer title is going away, he's picturing the feature-factory engineer. Both predictions are about the same thing: the version of each role that was mostly about running the process is being automated. The version that was always doing the real work is what's left.
What agents are claiming first
Cherny says Claude is already coming up with ideas on his team. It reads feedback, scans bug reports, watches telemetry for fixes worth shipping. The things that used to be a PM's Monday morning. Not in some hypothetical future, now. On the Claude Code team, the PM codes, the designer codes, the engineering manager codes, the finance guy codes, the data scientist codes. Cross-disciplinary is already the baseline, not the aspiration.
Lenny asked Cherny whether the three traditional disciplines (engineering, design, product) would still persist as separate things. The answer was that in the short term yes, but there's maybe a 50% overlap in those roles already, with specialties rather than clean boundaries. The walls aren't gone. They're getting thin enough to see through.
At OpenAI the prototyping stage has shifted in the same direction. Kevin Weil's point, made a year ago and more true now than then, was that there's no reason to be showing stuff in Figma any more: you can vibe code a working demo in half an hour and put it in front of someone. The gap between "here's what I'm imagining" and "here's the thing, try it" has collapsed.
Anthropic launched routines last week, joining similar features already shipped by OpenAI Codex and Cursor. Agents that run on schedules against codebases and connected systems, doing triage, reviewing, connecting dots, surfacing patterns. The coordination work that used to eat PM days is becoming infrastructure. So is a lot of the ticket-taking work that used to eat engineering days: the well-specified bug fix, the clean refactor, the boilerplate that maps one-to-one from a written requirement to working code. The spec-to-implementation step is getting very short, very fast.
The temptation to skip the thinking got stronger as a result. When building was slow, the thinking stage was forced on you by the cost of getting it wrong. The friction did the work. The friction isn't there any more.
New names for old skills
AI labs have started naming the components of good judgement with more precision than either product management or software engineering traditionally has. Evals inherit from both sides of the divide: the PM's discipline of articulating what good looks like before the build, and the engineer's discipline of writing tests that keep checking the thing still works. Context engineering is curating the right information for a decision. Harness engineering is shaping the whole operational environment around an agent so that good decisions become the path of least resistance.
Nick Turley at OpenAI put his finger on what these names actually are. He'd been writing evals before he knew what an eval was, because he'd been outlining the ideal behaviour for a use case before the work started. His way of putting it:
"it's not that different from the wisdom of, you ought to articulate success before you do anything else"
These are new names for old skills, borrowed from both sides of the divide. But AI teams are more rigorous about them than either discipline was alone. Success criteria get version-controlled instead of written once and forgotten. Feedback loops get built as infrastructure instead of left to social processes that break under deadline pressure. When an eval fails, the system tells you. When a PRD's success criteria drift, you find out in a retro six months later, if at all.
If you've read my previous posts: evals are the same shape as kill criteria, just applied to model behaviour instead of experiments. The argument for pre-committed success criteria is the same argument. And context engineering is the name AI engineering has given to the problem I spent the last post describing: context needs to flow to where decisions happen, not sit in a silo waiting to be found.
An agent harness is what good management has always been trying to build: the stack of tools, context, and guardrails that make good decisions the path of least resistance and bad decisions hard to ship. The coordination overhead used to be that harness, crudely, through meetings and stand-ups and ticket conventions. What replaces it is tighter, more automated, and built around judgement rather than around keeping everyone busy.
One thing to watch. In the same interview, Rabois observes that the number one consumer of tokens in the best organisations is now the CMO, and reads that as a signal of the CMO's performance. At Nvidia's GTC a few weeks earlier, Jensen Huang had said he'd be "deeply alarmed" if a $500,000 engineer wasn't consuming at least $250,000 worth of tokens a year. Maybe. But "tokens consumed" is just the latest in a long line of output proxies: story points burned down, tickets closed, slides shipped. Each one starts as a rough signal of activity and gets quietly promoted into a metric that can be gamed. The old ritual dies and a new ritual grows in its place. Naming the skills properly only works if the measurement doesn't drift back into counting activity.
Smaller teams, broader roles
Both titles are bending. LinkedIn has already replaced "Associate Product Manager" with "Associate Product Builder" in its graduate programme. There's no longer a resume: applicants send a 60-second demo of something they actually built. Brian Chesky merged Airbnb's product management and product marketing functions two years ago, not to kill product management but because the two roles had become one job in practice. Cherny thinks the software engineer title is next. Titles change. They've changed before. They'll change again. I was a webmaster in a previous life.
The hiring side is where the shift is already visible. The traditional path into both roles ran through the coordination layer. Juniors learned the harder work by doing the ticket work long enough to see the patterns. That ramp is getting shorter on both sides, which is exactly what the LinkedIn move is responding to: select for judgement at entry, rather than hope it emerges from years of coordination work that no longer exists.
The reframe also sharpens what you're hiring for. Companies that hired feature-team PMs were testing whether candidates could run the process: write the tickets, chase the alignment, keep the trains running. Companies that hired empowered PMs were already testing for judgement: show me a product decision you owned, walk me through a trade-off, tell me about the thing you killed.
Same story on the engineering side. LeetCode, a timed puzzle with a known answer, is exactly the kind of problem an agent now solves in seconds. The test that matters is whether candidates can see which tickets deserved shipping, or should never have been written. If you're still interviewing for the feature-factory version, you're hiring for a job that's being automated.
The uncomfortable implication of the convergence is that the lines can't stay clear at scale. If everyone is a builder with overlapping capabilities, a team of twelve becomes a free-for-all. The threshold where a team used to need splitting was somewhere around ten or twelve: past that, communication overhead compounded and you had to break the group up. With roles blurring, the threshold moves down. A team of five or six, each with overlapping capability, starts hitting the same friction that used to kick in at twelve. Teams still need to split. They just need to split earlier.
Total company size is getting reshaped too. Block cut its workforce by 40% in February, citing AI. Snap cut 16% last week, with Evan Spiegel citing smaller focused teams and AI doing more of the repetitive work. Every announcement of this kind comes with an AI justification attached.
Whatever the real drivers, the interesting question is which layer will prove compressible over time. Coordination work on the PM side, ticket-taking on the engineering side, is where an agent can do most of the job. The empowered work isn't. The hiring-side signals (LinkedIn selecting for judgement at entry, Airbnb merging PM and marketing) point the same way. If the layoffs follow that same logic, the coordination layer is the one being thinned.
Whether they do or not, the story is half-told. Restructuring to do today's work with fewer people is the easy first move. It's also the one that stops working as soon as a competitor runs the second move: use the same shift to do more work than was possible before.
The startups showing up from the other direction are already running the second move. Midjourney reached $200M ARR with eleven employees. Cursor hit $100M ARR in twelve months from launch with about twenty people. They got there by never building the coordination layer and pointing everyone at the empowered work from day one.
For a bigger company watching this, doing the same with less is a trap. The point isn't "less." The point is what the empowered people are freed up to do. Hiring doesn't stop. It shifts: fewer people running the process, more people who can see a problem, decide it's worth solving, and ship it.
What's left is the exciting part
The threat isn't that product management dies, or that software engineering dies. The threat is that the version of the role you were doing, the one with the visible process and the predictable output, is being automated. The version that survives is the one the job description kept pointing away from.
That version is the hard part. It's also the best part. Knowing what to build. Knowing why. Knowing when to stop. Shaping the thing with care rather than just hitting the spec. Being the person who can say "this is the way to frame it" in a room where everyone else is still trying to figure out what to measure.
The last time a floor dropped out from under what was possible was the dotcom boom, and anyone who could build was suddenly in the room. This feels like that again, with a wider door. The person who decides what's worth building, shapes it, and gets it in front of someone who cares is now the person. Broader roles, smaller teams, and a lot of work suddenly worth doing.
Call it builder, call it product manager, call it whatever ends up sticking. It always was the work. The question is whether you've been doing it.