Dean Wampler wrote a post called Protecting Developers from Powerful Languages that reminded me of a running conversation I have with one of my client developers on "pointy tools versus idiot proof code."
It all started when I asked him to open up some constructors on the pseudo domain classes so we could more easily write unit tests involving those objects. He had a concern that developers would use these "testing" constructors and the persistence layer would then crap out. When he asked me how we could make idiot proof code my answer was the hiring process. Some other answers might be mentoring, knowledge sharing, and streamlining your API's (!). At the end of the day, I don't think there is any possible way to succeed if you can't trust your developers.
A related concern that I've wrestled with all of my career as a technical lead is whether or not you limit the sophistication of your development approaches to the existing skillset of your team. Sometimes hitting your teamate's ceiling might just be a sign that your design ideas are unnecessarily complex and unworkable. Other times you should plow ahead with the knowledge that you'll need to invest in your team members. Sometimes you just punt because you simply cannot succeed with a design that your team as a whole can't grok. If you want the real answer you gotta go find someone wiser than me.