I understand that this tool, which I do not know, generates bad code, so I should look for another solution.
There must be a reason to be generated in build and not make it available in the project and do not let it . Moreover, the change is likely to occur frequently, so tinkering does not make sense , you'll lose everything in the next build , or when you need a change. These generated codes are made not to mess .
Subverting this seems quite a lack of common sense. If you do not trust the tool, do not use it. I am in favor of using scaffolding , but it needs to be the right and used tool in the way correct.
Reverse the situation . Anything that can generate an effort must be justified. Ask them to argue why. If doing it by doing is not a good argument. If it is to improve or customize the code, you already have the opposite arguments said above. If it's something else you need to look for a reason to counter-argument, but I think it's in those two that I said.
Good or bad practice is the argument of those who have no argument. There is no need for bad practice, there must be a good reason to do something and it can not cause undesirable damage. It has to analyze technically. Bad practice is to avoid analysis and take what someone else has said without knowing their context.
C # has even partial classes so that code generated before build is part of the project and at the same time protected from changes if everything is well structured.
