I think you're quite wrongheaded here. I've been a tester and a developer, and have greatly benefited as a tester from guidance by developers on areas that they considered high-risk or fragile; as a developer, I want testers to find the problems I haven't deeply probed.
There was no "pollution" unless your code is raw sewage, and that would be for a completely different reason.
Requirements do a terrible job of communicating the technical issues that a QA professional would care about, because they elaborate at best only what business analysts have managed to capture. Good developers will be aware that their code is optimized around the "happy path", and will want to know what they've left unconsidered. They'll at least have an intuition of what could go wrong, and what areas they'd like QA to probe. They also know what the big picture is for risk around a particular feature based on their design.
As a tester absent guidance from the development team, I've sometimes gone off on a wrongheaded approach that generated good bug reports, but didn't completely exercise the high-risk code paths and bigger problems, which could have been avoided through better collaboration with the development team, shipped to customers.
While a tester certainly shouldn't limit themselves to testing just what the developer says is important, they won't be damaged by learning what the developers own concerns about the code are. Sometimes, they can fine tune their approach based on their knowledge of the implementation. Only if a tester is particularly short-sighted will they consider the developer's opinion about what the risks are as the final word; they won't completely shut out things that the developer identifies as low risk, but they'll invest more effort in things that could have a higher customer impact.
The QA team is likely to see areas that have big combinatorial test scope than the requirements gatherers or developers of a system, but they may not be aware of components of the system that have a more subtle kind of fragility that benefits from awareness of the design or implementation of the system.
In my experience, collaboration between QA and Development produces better quality products. I would never recommend doing only a black box handoff.