Boris Cherny runs 5 AI agents in parallel and ships like a 10-person engineering team.
So naturally, LinkedIn is flooded with hot takes about how product managers are obsolete. How engineers can now “do PM work” because they can prompt Claude to build features. The bottleneck has moved upstream to product judgment, so every engineer has become a PM.
I’ve seen this movie before. The lessons may look new, but the outcome always repeats itself.
Three months later, the codebase is a mess. The product has seventeen half-baked features nobody uses. The roadmap looks like someone threw darts at a whiteboard. And the team is wondering why velocity went up, but outcomes went down.
AI is incredible. Claude Code is a genuine productivity multiplier. I use AI every single day for almost everything I do. Engineers building faster is objectively good.
But if you think that means you don’t need product managers anymore, you’re confusing speed with direction. And that confusion is about to cost you a lot of time and money.
The Fallacy Nobody Wants To Admit
This isn’t new. Engineers have been claiming they don’t need PMs since the dawn of software.
“We talk to users. We understand the problem. We can prioritize. Just let us build.”
Then six months later, they’ve built a technically beautiful solution to a problem nobody has. Or solved the wrong problem really well. Or shipped features in the wrong order and created debt they can’t recover from.
AI doesn’t change this dynamic. It accelerates it.
When you could ship a feature in three weeks, building the wrong thing cost you three weeks. Now you can build the wrong thing in three hours. Congratulations. You just made bad decisions 40x faster.
The constraint was never lines of code per day. It was knowing what to build, when to build it, and more importantly, what NOT to build.
How I Actually Use AI (And You Should Too)
I use AI for everything. Writing. Research. Code. Analysis. Drafting documents. Generating ideas.
I don’t start with a blank page when I’m writing a PRD. I ask AI to help me think through edge cases. To expand on the exception criteria I might have missed. To challenge assumptions. To generate alternatives I haven’t considered.
Then I use my brain.
I take what AI generates, I evaluate it against what I know about the customer, the market, the business, and the team. I keep what’s useful. I throw out what’s not. I adjust based on context that the AI doesn’t have.
AI is a thinking partner. It’s not a replacement for thinking.
In the same way I wouldn’t blindly follow a consultant’s recommendation, I don’t blindly follow AI’s output. I use it to move faster, think broader, and catch things I might miss. But the judgment calls are still mine.
People who blindly follow other people make bad decisions. People who blindly follow AI make bad decisions faster.
The tool isn’t the problem. How you use it is.
What Product Management Actually Is
Product management isn’t writing PRDs. It’s not maintaining Jira. It’s not running standups or asking for status updates.
Those are artifacts of the job. They’re not the job.
Product management is negotiation. Engineering wants to rebuild the architecture, sales wants the dashboard feature, support wants better error messages, and the CEO wants the thing that’s going to move revenue next quarter. All of them are right. All of them can’t happen at the same time.
So you negotiate. You make tradeoffs. You disappoint people in the right order.
Product management is translation. You sit between customers who don’t know what they want, engineers who think in systems, executives who think in outcomes, and sales teams who think in deals. Somehow, you have to align all those perspectives long enough to ship something coherent.
Product management is saying no. A lot. To good ideas. From smart people. Because even though the idea is good, it’s not the right idea right now.
Show me an engineer who can do that while also writing code, and I’ll show you someone who’s about to burn out or quit.
AI Amplifies Everything (Including Bad Decisions)
AI is a multiplier. I love that about it.
When I’m working on something, AI helps me move faster. Prototype faster. Test ideas faster. Write faster. Code faster. Analyze data faster.
But here’s the thing about multipliers: they multiply everything.
Good judgment plus AI equals great outcomes delivered fast.
Bad judgment plus AI equals a catastrophic mess delivered fast.
I’ve watched teams get access to AI tools and immediately start shipping at 10x velocity. Six months later, they’re drowning. The product is fragmented. Features don’t connect. Nobody can figure out why adoption is low.
They multiplied their output. They also multiplied their mistakes.
The bottleneck was always judgment. AI just made it more obvious and more expensive when you get it wrong.
The Boris Cherny Trap
Yes, Boris Cherny ships like a 10-person team.
You know what Boris Cherny also has? Years of experience at Meta. Deep technical expertise. Clear understanding of what he’s building and why. And he’s building developer tools for developers, which means his customer IS him.
That’s the exception, not the rule.
Most products are not built for people like the person building them. Most engineers do not talk to customers daily. Most teams don’t have the context or the judgment to prioritize effectively while also writing code.
And even at Anthropic, where engineers are using AI to build AI products, they still have product managers. Because even the best engineers in the world building tools for themselves still need someone asking, “Should we build this at all?”
Evals Are Not PRDs
One of Anthropic’s PMs said, “evals are the new PRD.”
Maybe. For AI products where you’re literally evaluating model performance, that might be true.
But for 99% of software, the hard part isn’t specifying what good looks like. The hard part is deciding what problem to solve in the first place.
Evals tell you if you built the thing correctly. They don’t tell you if you built the correct thing.
And that’s the job. Figuring out the correct thing. Then figure out whether it’s the right thing right now. Then, figuring out how to ship it in a way that doesn’t create six new problems.
AI can help you build faster. It can help you test faster. It can help you iterate faster.
It cannot tell you what matters.
What Actually Happens Without Product Thinking
I’ve seen this pattern repeat across companies:
Engineering gets faster. Features ship quickly. Everyone’s excited about velocity.
Then reality hits.
Features don’t connect to each other. The product feels fragmented. Customer adoption is lower than expected. Support tickets go up because nobody thought through the edge cases. The roadmap is just “whatever engineering thought sounded cool.”
Revenue doesn’t move. Retention doesn’t improve. The metrics that actually matter stay flat.
And six months later, leadership is asking, “Why did we ship all this stuff that nobody’s using?”
Because you optimized for speed, not outcomes. You built a lot of things fast, but you didn’t build the right things.
That’s what happens when you confuse engineering velocity with product strategy.
The Real Shift Nobody’s Talking About
AI does change the PM role. Just not the way people think.
Bad PMs who just shuffled Jira tickets and wrote requirement docs? Yeah, they’re in trouble. AI can do that work.
But good PMs who understand customers, make hard tradeoffs, align stakeholders, and keep teams focused on what actually matters? They just got way more valuable.
Because when your team can ship 10x faster, the cost of building the wrong thing just went up 10x. The cost of unfocused execution just went up 10x. The cost of saying yes to everything just went up 10x.
You need someone whose entire job is making sure you’re building the right things. Someone who can say no. Someone who can keep the team from chasing every shiny idea that AI makes easy to build.
That’s not an engineer running 5 AI agents. That’s a product manager who understands the market, the customer, the business, and the team.
AI Isn’t The Enemy (Following Anything Blindly Is)
AI doesn’t make bad decisions. People make bad decisions.
People have always made bad decisions by blindly following others. Following the loudest voice in the room. Following the executive who sounds confident. Following the consultant who has nice slides. Following whatever methodology is trendy this quarter.
AI just replaced “people to follow blindly” with “a tool to follow blindly.”
The pattern is the same. Someone abdicates their thinking to something else. They take recommendations without evaluating them. They execute without questioning whether it makes sense.
That’s always been a recipe for disaster. AI just makes the disaster happen faster.
The teams winning with AI aren’t the ones using it the most. They’re the ones using it the best. They’re letting AI help them think, not letting AI think for them.
Speed Without Direction Is Just Expensive Chaos
AI gives you speed. It doesn’t give you wisdom.
It doesn’t tell you which customer segment to focus on. It doesn’t tell you which features will move retention. It doesn’t tell you when to say no to the CEO’s pet project. It doesn’t tell you how to sequence work, so you’re not creating technical debt you can’t recover from.
Those are human decisions. They require judgment, experience, and understanding of context that goes way beyond “can I prompt an AI to build this feature?”
You can ship fast and still fail. In fact, you can fail faster than ever before.
The teams that win aren’t the ones that ship the most features. They’re the ones that ship the right features, in the right order, for the right reasons.
And that requires product thinking. Real product thinking. Not just “let’s build what sounds cool.”
What This Actually Means For Teams
If you’re an engineer who thinks AI means you don’t need PMs anymore, try this:
Ship fast for six months. Build whatever you think is important. Use AI to maximize velocity.
Then look at your metrics. Look at customer adoption. Look at revenue. Look at retention.
If they’re all moving in the right direction, congratulations. You might actually have good product judgment. Keep going.
If they’re flat or declining, you just learned an expensive lesson about the difference between building things and building the right things.
AI is a tool. A powerful one. But tools don’t make decisions. Humans do.
And when those decisions determine whether your product succeeds or fails, you’d better make sure someone on your team is actually good at making them.
That’s what product management is. And no amount of AI is going to change that.
Related:
- The Truth About Agile Nobody Admits
- Mixing Generations Creates Better Solutions
- How Do Workers Develop Good Judgment in the AI Era? (Harvard Business Review)
Engineers: Are you building faster, or building better? Drop a comment. I want to hear what you’re actually seeing.
Want more unfiltered insights on leadership? Check out my book, Beyond Management: A Field Manual for Real Leadership.