Code generators can save a lot of time and effort which leads to the question: Why isn’t everyone using them? A lot of code in any project is repetition.
The main reason: With todays IDEs, you can’t debug generated code. Well, you can debug the result of the code generation but when hunting bugs in generated code, chances are that you want to hunt them in the input and/or the transformer and no IDE has a notion of “this line of code came from these inputs, so show them as well”.
Example: You need POJOs which map database tables. Easy enough: You create a small program that connects to the database, maps the types in the tables to types in your favorite programming language (or rather the one you have to use for your project) and dump some code.
But unlike C/C++, modern languages don’t have a #line directive which says “this piece of code was originally part of another file” let alone “this information came from the database XXX”. So when there is some problem, you need to dig through the layers of the code generator, the templates and the input (the database) yourself, running the transformation in your head. Bad.
Approaches like MDD will keep failing until they support this.
Dark Views 
Debugging through the generated code is not a problem in most cases, since generated code can be very readable. There are some exceptions (e.g. most generated parsers) but in general this is a proven and pragmatic solution.
This is a common mistake when people start with code generators. At the beginning, the generated code is simple and the generator is simple and everything is great.
Then, things become more complex. Eventually, one line of generated code has more than a single input. External influences creep in: Config files, templates, complex transformations in the code generator. And suddenly, you can’t tell anymore why a line in the output is the way it is. When hunting bugs, you need to know where each character of the output came from.
Ideally, the code generator should write to a “context file writer” where it can say “I’m in this method, I’m using the templates X, and the current character comes from the config file Y”. It should be a bit like the stack traces in the Eclipse console: You click on something int he output and you get a view where you can see all the inputs and maybe even the states of all involved variables, so you can understand why the code generator did what it did.