I wrote an EPIC last week. The old-school hard way, no AI. Followed Gokul Rajaram's outcome-driven framework—clear hypothesis, measurable behavior change, the whole playbook.¹ Took me six hours (PRD, Acceptance Criteria, Success Metrics). Writing is really hard when you optimize for clarity.
Then I built a version of the feature itself in Claude Code. One hour. I demoed that prototype to my engineering manager over sending him documentation, he loved it
The EPIC took longer than the thing it was describing.
That's when I knew something fundamental had broken in how the PM job works. The old sequence—spec first, build later, ship eventually—assumes writing is cheaper than building. That assumption just died. Building is now cheaper than writing about building. And when the cost structure flips, everything downstream flips with it.
LinkedIn saw it coming. Last December, they killed their Associate Product Manager program entirely and launched "Associate Product Builder" instead.² The signal is loud: they're not training PMs anymore. They're training builders who happen to do PM work. The application asks for no resume—just a 60-second demo of something you built with AI and questions about how you made it work. Meta changed its PM interview loop for the first time in five years, adding a round where candidates solve product problems with AI in real time.³ These aren't experiments. They're now the new hiring bars.
The boundaries collapsed because the economics changed
The traditional PM-engineer-designer split made sense when each discipline required years of specialized training and crossing between them carried real switching costs. You needed a PM to translate business needs into engineering specs because PMs couldn't build and engineers shouldn't make product decisions. The coordination overhead was expensive but unavoidable.
That economic logic broke.
When a PM can go from idea to clickable prototype in an afternoon, test it with users, iterate three times, and show working demos to stakeholders before the first sprint planning meeting—the handoff now becomes friction. The old boundaries start looking like artificial bureaucracy. Teams shrink because AI makes small teams more capable than large ones. LinkedIn's ideal pod is four people now, down from their initial twelve.⁴ Not because they're cutting costs. Because four builders move faster than twelve specialists coordinating handoffs.
The market already priced this in. Mind the Product's 2025 salary data shows junior PM roles (APM, PM) grew 7-8% while senior IC roles jumped 25.6% to a median of $480,000.⁵ Microsoft laid off 373 PMs in May with a memo about "significantly larger scope" per remaining PM.⁶ They're not eliminating the function. They're eliminating PMs who can't operate with builder leverage.
I get why people resist this. Coding wasn't part of the job description when most PMs started. Learning new tools at 30 or 40 feels harder than it did at 22. And there's a legitimate fear of losing what makes PMs valuable—the judgment about what to build—by getting sucked into the weeds of how to build it.
But here's what changes when you actually do it.
What building as a PM actually looks like
A Head of product at Livesport published a case study in february showing thirteen projects over six months.⁷ He's not an engineer. He used to be a UX designer. He built a native iOS app published to the App Store. He built an internal tool that influenced a C-level brand consolidation decision. Twelve of the thirteen projects are still in use. His reflection: "I didn't become an engineer. I did become more T-shaped."
That's the pattern across every practitioner story I've read. PMs aren't trying to replace engineering—they're using building as a faster form of communication.
A PM at Meta with zero technical background now ships production features using Cursor.⁸ His engineering team asks him to teach them his workflow. Another PM turned Cursor into his complete system for PRDs, tickets, and status reports—not because he's writing production code, but because he can generate first drafts instantly and spend his time on strategic editing instead of formatting.⁹
The value isn't doing engineering's job. It's compressing the discovery loop.
When building takes fifteen minutes instead of fifteen weeks, you can test ten ideas instead of one.¹⁰ The bottleneck stops being "can we build this" and becomes "should we build this"—which is the actual PM job. Andrew Ng noticed it: "For the first time in my life, managers are proposing having twice as many PMs as engineers."¹¹ Engineering velocity jumped. Product decision-making didn't. The constraint has shifted.
What you risk when PMs code
The criticism deserves space because it's partly right.
CodeRabbit studied 470 GitHub pull requests in December and found AI-assisted code had 2.74x more security vulnerabilities and 75% more logic errors.¹² METR ran a randomized trial showing experienced developers were actually 19% slower with AI tools, despite believing they were faster.¹³ The code quality problem is real.
There's a structural risk too. When PMs and engineers operate from different vantage points, the tension is productive by design. PMs push for user needs. Engineers push for technical quality. When PMs start coding, they risk losing objectivity about what to build versus how to build it. That productive tension can collapse.
Y Combinator's 2026 Request for Startups makes the clearest counterpoint: "Getting to what to build is where products win or die. Tools like Cursor and Claude Code shine once the team already knows what to build."¹⁴ The hard part—talking to users, synthesizing messy feedback, deciding which problems actually matter—that's still the core job.
I think they're right. And I think the answer isn't "PMs shouldn't build."
The answer is PMs should build to validate ideas and communicate vision, not to ship production code. Build to compress discovery. Build to show instead of tell. Build to test ten hypotheses instead of one. But hand production engineering to people who think about security, performance, and maintainability full-time.
Brian de Haaff at Aha! coined "PM coding" to make this exact distinction.¹⁵ It starts with the customer problem and uses AI as execution leverage. Not vibe coding where you start with the tool and see what emerges. The discipline comes from knowing what question you're trying to answer before you start building.
How to adapt without losing what makes you valuable
If you're early-career, the bar moved. LinkedIn's builder program requires "comfort with code, prototyping tools, and AI-assisted development workflows."² Start this week. Build something trivial—a landing page, a calculator, a prototype of an idea you've been sitting on. Not for your portfolio. To break the psychological wall between describing and building.
Then put it on GitHub. Aakash Gupta tracks PM placements at top AI companies and the pattern is stark: only 24% of PM candidates have a GitHub, but every PM he placed at OpenAI, Anthropic, and Meta AI in the last year had one.²¹ The repos don't need to be impressive. They need to exist. Hiring managers aren't looking for 78K stars—they're looking for evidence you've shipped something, anything, that moved from idea to working code.
Your first three prototypes should be throwaway experiments. Jackie Bavaro's two-pass method: the first version is a scratch pad to surface questions, not a deliverable.¹⁶ You're building to learn, not to ship.
Within a month, connect tools to your real work. Claude Code pulls context from Linear, GitHub, Slack, Notion—it starts with your actual project history instead of generic suggestions.¹⁷ Ask it to pull the last thirty days of tickets, summarize the Slack channel, show the implementation from GitHub, and generate options—all in one prompt.¹⁸ The leverage compounds when the tool understands your product's context.
If you're an IC PM at an established company like me, use building to do your job faster. Prototype three UX approaches and test them with users before the design cycle starts. Build the analysis tool that answers the question your team has been debating for three weeks. Your company's processes will catch up eventually. Just start.
The fundamental PM skills haven't been automated—they've become more valuable. Understanding what users need versus what they say they want. Synthesizing ambiguous feedback into clear direction. Deciding which of ten possible features will actually move the business. These require judgment from experience, not prompts.
The real shift is faster, not different
The PM-engineer-designer triad isn't dying. It's compressing. The work that used to require handoffs between three people over two weeks now happens in one person's afternoon. This doesn't eliminate the need for specialized engineering on complex problems. It eliminates the need for PMs who can only write documents about what engineers should build.
The transition window is narrow. Probably eighteen months before building fluency moves from differentiator to baseline. Shopify already made it official: teams must explain why work can't be done with AI before requesting headcount.¹⁹ What's optional today becomes required tomorrow.
The career path is simple. Technical fluency is becoming table stakes. Judgment remains the differentiator. The question isn't whether to learn these tools—it's whether to learn them now when it's still an advantage, or later when it's a requirement.
Start building something this week. Not because coding is the point. Because the fastest way to understand what's possible is to build something that was impossible six months ago. The gap between PMs who talk about AI and PMs who build with it isn't years of study. It's hours of practice.²⁰
References
¹ Gokul Rajaram, outcome-driven product framework, https://youtube.com/shorts/epBd7XBSGgM
² LinkedIn CPO Tomer Cohen, "Why LinkedIn is replacing PMs with AI-powered 'full-stack builders,'" Lenny's Newsletter, Dec 2025, https://www.lennysnewsletter.com/p/why-linkedin-is-replacing-pms
³ Lenny Rachitsky on X, Feb 2026, Meta PM interview changes, https://x.com/lennysan/status/2021257353845486030
⁴ Gokul Rajaram on X, Jan 2026, team pod structure, https://x.com/gokulr/status/1913283901726036298
⁵ Mind the Product, "How much were product managers paid in 2025?" https://www.mindtheproduct.com/how-much-were-product-managers-paid-in-2025/
⁶ Spokesman-Review, "Hit hardest in Microsoft layoffs? Developers, product managers, morale," May 2025, https://www.spokesman.com/stories/2025/may/19/hit-hardest-in-microsoft-layoffs-developers-produc/
⁷ Ondrej Machart, "13 Claude Code Projects That Changed My Product Manager Role," Medium, Feb 2026, https://medium.com/@ondrej.machart/13-claude-code-projects-that-changed-my-product-manager-role-over-the-last-6-months-7057b9045d51
⁸ Zevi Arnovitz on Lenny's Podcast, "The non-technical PM's guide to building with Cursor," Jan 2026, https://www.lennysnewsletter.com/p/the-non-technical-pms-guide-to-building-with-cursor
⁹ Dennis Yang on Lenny's Podcast, "Cursor is a much better product manager than I ever was," Oct 2025, https://www.lennysnewsletter.com/p/cursor-is-a-much-better-product-manager
¹⁰ Aha! Blog, "10 Product Manager Insights About Building Applications With AI," Feb 12, 2026, https://www.aha.io/blog/10-product-manager-insights-about-building-applications-with-ai
¹¹ Lenny Rachitsky on X quoting Andrew Ng, Jan 2026, https://x.com/lennysan/status/1943773031459172360
¹² CodeRabbit study, Dec 2025, cited in TATEEDA "Vibe Coding vs. Engineering: A 2026 Guide," https://tateeda.com/blog/vibe-coding-vs-professional-engineering
¹³ METR randomized controlled trial, July 2025, cited in Wikipedia "Vibe coding," https://en.wikipedia.org/wiki/Vibe_coding
¹⁴ Y Combinator, "2026 Request for Startups," https://techstartups.com/2026/02/04/y-combinator-is-out-with-its-2026-request-for-startups/
¹⁵ Brian de Haaff, "The New Era of PM Coding Is Not About Vibes," Aha! Blog, Jan 15, 2026, https://www.aha.io/blog/the-new-era-of-pm-coding-is-not-about-vibes
¹⁶ Jackie Bavaro, "Vibe Coding for Product Managers - Day 1," Aug 2025, https://jackiebavaro.substack.com/p/vibe-coding-for-product-managers
¹⁷ Medium, "Claude Code for Product Managers: Complete Setup Guide," Feb 2026, https://medium.com/product-powerhouse/claude-code-for-product-managers-complete-setup-guide-real-pm-workflows-2026-c94ec7087b6f
¹⁸ George Nurijanian, "How to Use Claude Code: A Product Manager's Guide," prodmgmt.world, https://www.prodmgmt.world/blog/how-to-use-claude-code
¹⁹ MIT CDO, Shopify CEO Tobi Lütke memo, Apr 2025, https://cdo.mit.edu/blog/2025/04/11/shopify-ceo-tobi-lutke-ai-is-now-a-fundamental-expectation-for-employeeslutke-says-managers-asking-for-new-human-talent-will-have-to-explain-why-the-job-cant-be-done-by-ai/
²⁰ O'Reilly Radar, "The Five Skills I Actually Use Every Day as an AI PM," https://www.oreilly.com/radar/the-five-skills-i-actually-use-every-day-as-an-ai-pm-and-how-you-can-too/
²¹ Aakash Gupta on LinkedIn, PM GitHub portfolio insights, 2026, https://www.linkedin.com/in/aagupta/
