Code Generation Feature Specification Template

Yes. Committing generated code makes builds reproducible without requiring every developer to run the generator locally. It also makes code review possible since reviewers can see what changed in the generated output. Add a CI check that runs the generator and fails if the committed output differs from a fresh generation.

Version your output format independently from the input format. When the input schema introduces a breaking change (renamed field, removed endpoint), the generator should produce a clear error listing what changed and what manual updates are needed. Never silently generate code that compiles but behaves differently.

Include a file-level comment stating that the file is auto-generated, with the generator name, version, and timestamp. Do not add inline comments explaining generated logic. The code itself should be readable. If it is not, improve the templates rather than adding comments. The [definition of done template](/templates/definition-of-done-template) can help define quality standards for generated output.

Separate the parsing and transformation logic from the rendering layer. Parse the input into an intermediate representation (IR), then pass the IR to language-specific renderers. This lets you add a new language by writing a new renderer without touching the parser. Test each language renderer independently with the same set of input fixtures.

Use templates (Handlebars, EJS, Jinja) when the output is mostly static text with variable interpolation. Use AST manipulation (ts-morph, libcst, go/ast) when you need to modify existing code files or generate code that requires precise formatting. For most generators, templates are simpler and sufficient. Switch to AST tools only when you need to merge generated code into existing files. ---