This is difficult, in that it depends a lot on the size of your team, and the roles of the people in the team. It also depends on the target platform of your product/service.
If you can get to a point where your developers are following a set of conventions (patterns/rules) about how to implement functionality for the specific platform, then you've made progress. You can sometimes find these "patterns/rules" for specific platforms (see the Apple user interface guidelines, among others). For web development it is a bit harder (there is a lot more freedom). The developer community has tackled the problem through frameworks like Bootstrap (for better or worse), that provide a consistent look-and-feel.
In the end it is about educating your development team on UX best practices -- an ongoing task that they are already familiar with for their day-to-day development (coding) work. Think "design patterns", but for interaction design. Your question is about "detecting" bad design. You can perhaps start with detecting the biases in your own designs, by investigating how they violate the guidelines for the platform (and motivating why it matters). The more educated the team gets, the easier it will be to detect "bad design".
If your team is not fortunate enough to interact with users, then instrument your application to provide as much usage information as possible (with the necessary privacy protection of course). Analyze the results for usage patterns, and iterate on design. If it is an online application, and you have the infrastructure, perform A/B testing.
Once you've settled on a consistent design (both functionally and aesthetically), you can focus on building the more expensive automated integration tests to ensure that you don't "break" the design (although there is still no automated way to detect that you are following design conventions, as far as I know).
Hopefully this will fit within the time/budget constraints of your project. Perhaps try to get feedback from other teams that have struggled with similar problems. Like I said, it all depends on the organization and the team. If this is something that interests you (which I assume it does), then perhaps you can take ownership of this part of the development process, and help to educate your team. It's not always easy, but you have to start somewhere.