My spicy take on vibe coding for PMs
AI-assisted “vibe coding” is blurring the line between product managers and engineers, raising questions about who should be writing code and under what conditions. Commenters highlight benefits such as faster prototyping, better communication of product ideas, and new opportunities for technical PMs and founders, but warn that non-engineers shipping AI-generated code to production can damage reliability, data integrity, and team productivity. Many see a longer-term shift toward hybrid “product engineer” roles and flatter organizations, with PMs either becoming more technical or their traditional role shrinking, especially in large companies where incentives and blast radius matter.
Role of PMs, Engineers, and “Vibe Coding”
- Many see technical PMs / product-minded engineers as increasingly valuable, especially as AI handles more coding.
- Some argue PMs coding prototypes is useful for communication, internal selling, and exploring long‑tail ideas that wouldn’t get engineering time.
- Others say letting PMs ship production code is low leverage, creates cleanup work, and confuses accountability: if you ship code, you’re effectively an engineer.
Quality, Risk, and “Prod Diffs”
- Strong concern about PM‑written or AI‑generated code landing in production: edge cases, performance problems, and lack of understanding of complex systems.
- Anecdotes of PM vibecoding causing serious production incidents (e.g., hammering databases, leaving “happy‑path only” data debris).
- Several suggest limiting PM coding to low‑blast‑radius areas (internal tools, dashboards, CSS, personal automation).
Future of the PM Role
- One camp predicts the standalone PM role will shrink or be absorbed into engineering/design as AI reduces coding friction and flattens orgs.
- Others say code is now cheap, so deciding what to build, prioritizing, and having “taste” becomes more important, not less.
- Some PMs expect to specialize (engineering, design, data) and move closer to “product engineer” roles.
Engineers vs PMs as “Product Owners”
- Several engineers claim they could more easily become passable PMs than PMs could become competent builders; others counter that the skill sets and motivations differ.
- Common view: in practice, PMs often shield engineers from politics and conflicting stakeholder demands; removing PMs can overload devs with meetings and context switching.
AI Capabilities and Limits
- Mixed views on how far current models (e.g., Claude Opus) go: some jokingly claim engineers are obsolete; most insist complex systems still require deep engineering judgment.
- “Text-to-code” is seen as flashy but risky; “code-to-text” (AI explaining codebases for PMs) is praised as underused and safer.
Culture, Gatekeeping, and Process
- Some see resistance to PM coding as necessary quality control, not gatekeeping; others think engineers are resisting business folks meeting them halfway.
- Agile/Scrum is framed by some as process that turns both dysfunctional and highly motivated teams into “average”; small, tight teams often function well without heavy process.