"I have observed organizations invest huge time and resources to create extensive UX prototypes."

Yikes! That's Doing It Wrong!

The idea of creating a prototype is that it's supposed to be quicker, cheaper and more lightweight than building code!

A low-fidelity prototype could be a literal scribble on the back of an envelope. It's just a check-in with the product team and with the users - "so this landing page has an intro, links to key features A, B, and C?"

"No, we only need features A & B linked from the landing page"

"Oh right, thanks, I'll remove them."

Subsequent prototypes depend on exactly what you're wanting to find out.

If the question is "can they find the button?" then you will almost certainly need an interactive mockup in Figma. If the question is "does the product work?" you will almost certainly need code - but it doesn't have to be pretty or look anything like the finished version.

You can even manually replicate the steps you will later automate through code if the question you're asking is "do the features we will offer actually solve the problem?" For example, Slack had a human pretend to be an AI bot to test the concept before writing any code.

UX prototypes do fall into the solution space, but testing prototypes is only a tiny part of the UX role: the bulk of my time is spent in the strategic insights/discovery space, because if you're not building what they need, it doesn't matter much what you build.