Are these bugs in the sense that the code's plain wrong or that the developer misunderstood the spec? Good unit tests (when written alongside the code they're testing) should go a long way towards preventing the former.
The latter. Also misunderstandings about APIs. IME these combined are usually something like 70% of all bugs so the ROI on unit tests is not particularly high.
I find integration tests paired with BDD do a good job of catching "code plain wrong" bugs as well as misused APIs and misunderstood specs. They're harder to build and run slower but the ROI is still higher.
Because that seems like they're doing things backwards...
You should know what result you want before you even start writing the code.
>You should know what result you want before you even start writing the code.
In theory, but IME about 50% of bugs end up being specification bugs at the high level anyway.
Once you drill down and start writing unit tests on lower levels to imitate higher level APIs that % only goes up.
Integration tests need to be the default and people need to learn when to use one or the other.