Some code generators regenerate an entire application from a model on every run, while others generate only specific artifacts, like a base class or a data layer, and leave the rest to be written by hand. What drives the choice to generate only part of a system rather than the whole thing, and what does a team give up by choosing partial generation?

## Why full generation is such a strong demand Partial generation exists because full generation makes a very strong demand: the model has to be a complete, unambiguous specification of everything the system does, not just its structure. That demand is achievable in narrow, well-bounded domains, a state machine model can fully determine dispatch code, a database schema model can fully determine a CRUD data-access layer, a REST API description can fully determine client and server stub code, because in each of these cases the mapping from model to code really is mechanical and total: there is no meaningful behavior left over that the model failed to capture. Most real production systems, however, are not that narrow. Business logic is full of conditional exceptions, integration quirks with third-party systems, performance-driven special cases, and requirements that change faster than a formal model of them could be kept accurate. Trying to fully model that and generate 100% of the system from it either produces a modeling language so complex it is effectively a second programming language (defeating the purpose), or forces developers to bypass the model constantly, which is worse than not having full generation at all, because now there are two sources of truth silently diverging. ## What earns a place in the generated slice Partial generation resolves this by being selective about what gets generated, and the selection criteria are fairly consistent across real projects — generate the parts that are: 1. **highly repetitive** (the same shape repeated across dozens of entities or endpoints, where hand-writing each instance is pure toil and a prime source of copy-paste bugs), 2. **mechanically derivable** from information that already exists in a structural, machine-readable form elsewhere (a database schema, an API description, a set of DTOs), 3. **low-risk to get wrong** because the generated slice is either simple enough to review at a glance or exercised thoroughly by generic tests. Data-access layers, DTO/mapper classes, API client and server stubs from an OpenAPI or Protobuf definition, and validation boilerplate from annotated fields are the textbook cases. Business orchestration, workflow-specific rules, and anything involving genuine judgment calls about edge cases are deliberately left to hand-written code, because trying to squeeze that logic into a model would either be impossible or would produce a model no more readable than the code it's replacing. ## The two structural patterns Mechanically, partial generation is usually implemented via one of two structural patterns, both aimed at making the boundary between generated and hand-written code explicit and safe. - **The generation-gap pattern** generates a base artifact (an abstract class, an interface, one half of a partial class) wholesale on every run, and hand-written code lives in a separate artifact that extends or implements it, so the generator never touches, and cannot corrupt, the hand-written portion. - **Alternatively**, some pipelines generate entire files but restrict generation to specific directories or file patterns by convention (a `generated/` folder that is entirely regenerated and never manually edited, versus everything outside it that the generator never writes), which is a coarser-grained version of the same ownership-splitting idea applied at the file-tree level rather than the class-hierarchy level. ## The cost: a forfeited consistency guarantee The cost of partial generation is the consistency guarantee it forfeits. With full generation, by construction, the generated system is always consistent with the model, because there is nothing else contributing to the system's behavior; regenerate, and everything is up to date. With partial generation, the model only guarantees consistency for the generated slice; the hand-written portion is a second, independent source of truth that can drift out of sync with the model or with the generated code it depends on. If a model change removes a field, the generated DTO correctly loses that field on the next regeneration, but hand-written business logic that still references the old field will only be caught if the target language's type system flags the reference at compile time; in a dynamically typed language, or if the hand-written code accesses the field through a reflection-based or loosely typed path, the drift can survive into production silently. This is the central risk teams accept: partial generation trades total consistency for practicality, and the price is paid in vigilance, code review discipline, and test coverage around the generated/hand-written seam, rather than in the generator's own guarantees. ## Where it shows up A concrete, common real-world instance: an OpenAPI-driven pipeline (OpenAPI Generator or similar) that regenerates DTO classes and a typed API client from a service's OpenAPI specification on every build, while all request-handling logic, business validation beyond simple field constraints, and orchestration across multiple service calls remain hand-written in files the generator never touches. When a field is renamed in the specification, the DTO regenerates correctly and (in a statically typed target language) the build breaks everywhere the old field name was used in hand-written code, which is the type system doing the job that full generation's inherent consistency would have done automatically; in practice, this compiler-enforced seam is exactly why teams accept partial generation's weaker guarantee, the failure mode is loud and caught at build time rather than silent, as long as the language and the generated artifact's typing are strict enough to make the seam visible.