I've found that "this doesn't work" usually means "I've spent the past three hours on this and I want someone else to take a fresh look at it before I go insane" with my co-workers. In the case where someone doesn't provide more information because their brain is on fire and they're starting to get stressed out about the problem, it's easier to just help them and trust they'll do the same for you.
Having said that, with a team that's spent less time around each other, you might not have that level of consensus.
I've found that even QA people casually write "X feature doesn't work" in bug reports, when they could give 10x more information, like: "the page stalls and shows the spinner continuously", "the button is grayed out and I can't click it", "the output is garbage letters", "the result is not the expected value", etc.
They probably assume that the person whose job is to maintain the code can more efficiently investigate the nature of the problem, provided they give instructions on how to reproduce it.
How do we know whether or not we're properly reproducing whatever they're seeing if we don't know what we're seeing?
I've seen scenarios where a set of reproduction steps actually showed two things wrong. QA was sending it back for one of the things, but they didn't say what was wrong, only that something was wrong and here's how to reproduce it. The developer saw the other problem, and fixed it. The result when shipped back to QA?
"You didn't fix the problem, but I opened a new defect now for the other thing you broke."
Having said that, with a team that's spent less time around each other, you might not have that level of consensus.