A common solution to this problem would probably be code reviewing but the pace at which we are going simply doesn't allow for it.
This tells me you know the solution, but can't get management buy-in to implement it or, worse, you don't want to make the effort to review.
Reviews can be done many different ways, and be as strict or lenient as possible. I work at a research company where non-software-engineers write code and projects are short lived so the code review we had at my industry job are out. You have to hit the right balance of "check that the code is up to snuff" vs "get all the things done by the deadline." When you step into initiating code reviews, start light and make the rules for passing them clear.
When starting code reviews on teams that haven't had them before, I setup the lint/checkstyle/findbugs/StyleCop/whatever that checks for industry standard stuff in your language. That way the review is pretty much "You have N violations, fix them" which is quick for the reviewer and clear to the code writer. Then the eyeball review is making sure they haven't blanket ignored violations on a class, and a few big issues that the tools missed.
Don't go overboard with the code review. Outside what tools will catch pick only a handful of other things to mention. They aren't suddenly going to write Clean Code (tm) and I'm guessing you won't get by-in from management to go that far. Start small and quick -- hopefully with a build process that facilitates checking this stuff -- to slowly teach the juniors how to write better code. Over time good habits will form in the juniors and you can start to tackle other stuff.
My last bit of advice is to get people to review your code too. That way you aren't looking like an a-hole telling others their code sucks but somehow yours is amazing. If you are reviewing their code, they should be reviewing yours.