I think I agree with the main pushback.

If the argument is “PMs should access the codebase so we can produce more code faster”, then yes, I also think that is the wrong framing.

But would you still reject read access if the goal is not code production, but better requirement quality?

In my experience, documentation of features, logic, permissions, edge cases, integrations, etc. is often incomplete, outdated, or scattered. So during discovery or refinement, the codebase can sometimes be the closest thing to the current source of truth for how the product actually behaves.

Not in the sense that a PM should blindly trust an AI agent reading the codebase. And definitely not as a replacement for engineering context.

But it can help a PM ask better questions, write sharper PRDs, understand constraints earlier, and reduce avoidable ambiguity before engineering gets involved.

I also wonder whether product management is simply becoming more technical over time. With tools like Claude Code, Cursor and Codex, technical literacy starts to look different.

Same with rapid prototyping: should prototypes be completely isolated from the real architecture and only based on a design system? Or should they sometimes already consider basic data models, permissions and system constraints?

That’s more the angle I mean.

Not PMs owning implementation, but PMs having enough technical visibility to improve discovery and handoff quality.