I haven&#x27;t seen any modern ones, but back in the day it was generally a complete and utter disaster.<p>And having extensible points doesn&#x27;t work.<p>The whole problem is that if they&#x27;re complicated enough to actually encode a client&#x27;s project, they&#x27;re so complicated that they&#x27;re really just a visual programming language.<p>But that means all the code conditions are hidden in drop-downs and checkboxes. But in reality that&#x27;s the logic, those options are the code, but you can&#x27;t easily read the code. If you can&#x27;t read the code, you can&#x27;t understand the code. So increasingly no-one has a clue what the system is really doing and you have to test it like crazy.<p>It also makes it very hard to know what has and hasn&#x27;t changed and even if you can diff it somehow you often can&#x27;t even understand what the change means.<p>Other problems include the &#x27;extensible points&#x27; not being atomic enough, or too atomic, or badly documented, or badly coded, or just plain insanely coded. And if there&#x27;s a bug you&#x27;ve got to wait for the code generator to be fixed.<p>And finally you are locked in to your vendor. Which becomes a big deal.<p>What happens is that you&#x27;ll start writing your own code to fix these problems, or edit the auto-generated output somehow (if you&#x27;re lucky enough to be allowed to) and it&#x27;ll rapidly turn in to a complete mess that only 1 or 2 people really understand what&#x27;s going on and it takes a month to do changes that should take a day or two.<p>ORMs are the closest we get to auto-code generation and there&#x27;s a reason we stop there. We learnt from bitter experience. And even they can be dangerous in the wrong hands.<p>Still, I guess we&#x27;ve got to try again every now and then, one day someone might nail it.