It depends on the quality of scaffolding , and how well it handles the inevitable changes that will emerge throughout the project.
In general, every time a system (eg your application) needs to interact / integrate with another system (eg, the database), a concept mapping is necessary, since not only does each a different abstraction (eg, objects vs. tables) as it is necessary to establish which entity on one side corresponds to one entity on the other (eg, class X represents table Y). This is sometimes dubbed glue code ("glue code").
There are several ways to do this ( hardcoding , configuration files, introspection / reflection, etc.), and scaffolding is one of them. The idea behind this technique is - assuming enough boilerplate code needs to be written - facilitate the task by combining a smaller, more declarative code with data obtained through introspection, producing from them a complete code. This is different from, for example, generating a "skeleton" ( skeleton ) from the data and letting the programmer complete it (common in UML tools, for example - at least the oldest ones) .
Personally, I do not like the idea (at least the " scaffolding during the design ") because I dispute the assumption that this boilerplate code is necessary - I believe that the same results could be obtained with generic code via reflection. But in itself, the practice does not seem to me detrimental in any sense (perhaps except for the generated code stacks ...). I do not see why it would be suitable for prototypes but not for production.
As for problems with using this technique, I only see the potential for problems to arise as the project evolves. Let's say the scaffolding was done, and it was realized that some changes were required in the generated code. They were made, and in the future there was a need to evolve the scheme (i.e. make changes to the DB). What to do with existing code? Usually the answer would be to "generate it again," but as changes were made to it, we would have to do them all over again. Alternatively, you can not redo scaffolding , making the changes all at hand, but the volume of these changes can be significant (and doing them by hand brings potential for errors).
It is at this point that the idea bothers me: if a system is built on the philosophy of scaffolding , it will not hesitate to add more and more code to its generation process, assuming that this does not cause problems for the programmer. When in fact this brings up problems, as already mentioned. If a system that uses an alternative philosophy, even "hardcore", will always have the cost of changes to the programmer, and will try to minimize that cost. (via generic code, introspection / reflection, or simply via helper tools to modify settings).
I have no experience with Rails to tell if the quality of your scaffolding is good or not. So my recommendation is to look at the following parameters when deciding whether or not to use this feature: 1) If I need to redo scaffolding , am I going to lose something? and 2) if my bank needs to radically change, how much code will I have to write by hand to tailor my current system to changes? Simulate some scenarios like this, see what Rails offers you to help in this, and then evaluate whether it is feasible to do in production or not (where you can not "throw everything away and start over", but if you need to give whether that is difficult or not).
