One thing missing from this discussion is the blast radius of the product or repo in question.

Let PMs land new widgets on internal dashboards or CSS changes in internal tooling. The same way we should be aspiring to build tools for devs to merge these same changes with minimal test plans. You wouldn't call a mechanic to help you turn on your windshield wipers.

Changes in high-risk environments should be gated for people who actually know what they're doing. That high bar should remain high.

100% agreed. I'm a Program Manager and have been writing tooling for my own internal workflows for years (like Monte Carlo-based forecasting tools), or program-adjacent low-stakes stuff (like an API to generate a WSJF score based on a fields inputted into Asana, since it couldn't do that itself).

But I'm not about to send a PR for fixing production bugs even if I have decent high level context. Nobody has better context than the devs working on it every day.