Um. Yeah. You're also creating a situation where, should anything possibly go wrong (now, how could that happen), you cannot hop on the server, diagnose, and possibly do some quick-try fixes. I can see limiting shell to a small trusted subset of colleagues (sorry, devs), but not eliminating it altogether.
Automated management, "system-as-code", devops, and all that has its place. The problem with virtually all existing systems for automated configuration management (cfengine, puppet, chef, Oopsware), is that they are highly non-transitive, and effectively bin years or decades of administration experience. They're fine once you've worked out the kinks, but as anyone who's worked with these tools can tell you, the one thing they're best at is screwing up all of your systems simultaneously.
"Etch" (http://sourceforge.net/projects/etch/) is one tool I've looked at briefly that appears to take a different tack, and is amenable to taking on-host changes and incorporating them into the configuration management system itself. One of the criticisms I've seen of it is that it's rather Linux and/or specifically Debian-centric, which may well be as Debian offers some very strong tools for managing, assessing, and maintaining system state (policy, APT, debconf). While dependencies can be painful when they keep you from doing what you want to do, as with most good safety systems, it's generally because you really don't want to go there (and if you do, there are means, within the framework provided by Debian, to get you there).
One way to avoid snowflake systems is to use tools that manage dependencies, stick within them to the greatest extent possible, and where that's not an option, to put your own modificiations within that same framework.