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.
Published 2026-03-09
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:
Each role has some grounds for thinking the others have become optional.
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 when nobody translates product intent into structural constraints.
Engineers need to know why they'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 ship things users actually want, faster.
Learn the skills of the other roles instead of betting on who gets replaced.