Different organizations view the roles of testers and developers differently. In general, a tester verifies that the system conforms to its specification and fulfils its requirements. A developer builds the system and performs maintenance.
Typically, a tester should not pass a finding to a developer without a reproducible description of how the system's behaviour differs from their expectations. Then there can be a discussion on the basis of that description whether this behaviour is a defect or actually by design, whether that design makes sense, whether it should be kept or changed. However, a tester only deals with the behaviour of the system. They don't judge between right/wrong behaviour, and do not deal with causes of that behaviour.
If there is a decision to fix the observed behaviour, a developer will have to track down the cause of this behaviour, for example by observing the program with a debugger or by analysing log files. While developers can use the source code, they do not usually have a QA mindset and training.
All of this means that while you can't find bugs without a developer, letting a developer hunt for a bug without a good idea of what to look for is probably a less-than-ideal use of resources. Ideally, a tester should have a go at it first. After all, the code itself may be perfect if the cause of the problem was during requirements analysis, or if the cause is in the developer's understanding of the problem domain. A developer might be “blind” to such causes.
So while testers bring unique skills and a valuable point of view, they may not have the ability to reproduce any reported behaviour. A developer probably has a better understanding of the system, may see possible circumstances that could hide the problem from a tester, or can help making the behaviour more easily reproducible. E.g. concurrency bugs are unlikely to be reproducible with a black-box approach, but can often be provoked with a well-placed
sleep(1) in the code. If a tester feels they may be on to something but lack the knowledge or skills to pursue it successfully, they should obviously rope in others who do – including developers.
To summarize, the responsibility for reproducing some behaviour tends to lie with QA. Of course testers and developers should cooperate where necessary. A given organization may have formal or informal policies how this should be done, or even use a different definition for “tester” and “developer” roles.