My general tactic for codegen hygiene like this is to check in the generated files, and on every CI re-run the code generator. After the generator runs, CI asse

My general tactic for codegen hygiene like this is to check in the generated files, and on every CI re-run the code generator. After the generator runs, CI asserts there are no changes in Git. If there are any changes, the job fails. This ensures that generated code is consistent with its inputs (including the generator logic) for every merge to main. It prevents people from editing the generated code, since their edits will cause a diff in CI and fail the build, but no one ever actually loses their work since the codegen does not run automatically/continuously during local development. Checking in the files also makes it very easy to review changes to the generator since you can always tell how the output is changing. The total burden for the above system is: - a 30 line command called `Notion assert-clean` - A 30 line CircleCI job that loops over the list of code generator commands, calls the command, then calls assert-clean. We’ve used that tactic for years for simpler stuff like “make sure the SQL dump is consistent with the SQL migrations” and “put all the file names in this directory tree into a typescript file so we can tab complete them”. The only necessary bit is that your code generator shouldn’t be spitting out enormous mountains of unreadable code.