The AI Standoff: Engineers and the PM skill set
Engineers, designers, and product managers each think AI has made the other two redundant; the edge goes to people who learn to wear all three hats.
Loading content...
Engineers, designers, and product managers each think AI has made the other two redundant; the edge goes to people who learn to wear all three hats.
AI coding agents have everyone in a Mexican standoff: engineers think they can design and own the roadmap, PMs think they can skip dev, designers think they can ship alone. The engineers who actually win are the ones who stop gatekeeping and learn to think like a PM.
Marc Andreessen called it a Mexican standoff on Lenny's Podcast — product manager, designer, and coder all pointing guns at each other, each convinced AI made the other two roles optional.
I've seen it in my own org and in every AI Twitter thread:
They're not all wrong. They're all partly right. That's what makes it a standoff.
The engineer who only implements tickets — and the PM who only writes specs someone else builds — both look slower now.
When I use Cursor or Claude Code on a feature end-to-end, I'm not just writing functions. I'm deciding scope, rejecting bad UX mid-stream, and cutting corners that would embarrass us in prod. The designer who ships a working prototype with AI isn't "playing engineer." They're compressing the loop.
If you're protecting a title instead of expanding what you can do, you're the one standing in the circle with nothing loaded.
PMs and designers will eventually ship complex, secure, scalable apps without an engineering team in the loop. We're not there.
Today, AI agents still need someone who knows where state lives, what happens when the queue backs up, and why that "simple" refactor touches twelve files. I've watched agents confidently architect spaghetti because nobody in the prompt understood the data model. The codebase falls apart without engineering judgment — not because the model is dumb, but because nobody translated product intent into structural constraints.
That's an opening for engineers who take it.
The gap isn't syntax anymore. It's knowing why you're building something.
I catch myself grabbing a ticket and letting the agent run before I've asked whether the feature matches how users actually pay us. That's implementer brain. PM brain asks: what's the smallest version that validates the bet? What does success look like? What are we explicitly not doing?
When I sit down with an agent, I'm part tech lead, part PM, part developer. I have to fold design constraints, business goals, and "we can't rewrite auth this week" into the same thread. Same playbook as briefing a colleague: evidence first, narrow context, answer the follow-ups.
Engineers who learn that stack don't just output more code. They ship things users actually want, faster.
Put the gun down. Stop betting on who gets replaced. Start stealing the other jobs on purpose.