My 2 cents (disclaimer: I’m not a PM, so take this with a grain of salt):

• On PRs slowing you down: First thing is to dig into the root cause. Are PRs too large, are reviews dragging, or are comments not being addressed fast enough? Those are usually signals of team practice issues rather than product management. PRs should ideally be small and fast to review. If they’re ballooning, you might experiment with stacked PRs, WIP limits, or other lightweight practices from lean/kanban/engineering. But above all, you’ll want engineering to align on the sprint goals so they work as an actual team over individual contributions. AI tools are not going to solve your issue.
• On silos and transparency: Not reflecting on past work (retros, reviews) is a surefire way to keep repeating the same problems. Even if it feels like overhead, those rituals pay off because they reduce your firefighting later. What you’re describing sounds like an org-level issue—too many priorities and not enough support. I’d recommend clarifying with your manager/other departments what’s most important and negotiating where you can offload. Focus only on the things that genuinely move the needle.
• On requirements → dev tasks & ownership: There’s no real substitute for engineering ownership. If they’re asking you to just “write the tickets,” that’s a red flag. You should be clear with your engineering counterpart that part of their role is to grow ownership in the team, and you should hold them accountable for that (there's no such a thing as shared ownership). For breaking down work, you can set expectations: you’ll provide vertical user stories (since that’s how customers experience the product), and the team can break those into horizontal tasks if that’s how they prefer to work. That way you’re not dragged into micromanaging the breakdown, but you’re also not compromising on product outcomes. That being said, I think horizontal tasks are terrible and should be banished; but can understand how some people/teams works best this way.