Chloe Bertrand

I hold one rule for everything on this beat: generated code is still code, and it lands in your repository where somebody has to read it. If you cannot show me what it produced, I cannot recommend the tool. Payload to typed client is the most useful of these. The generator reads a schema or a sample document, infers field types and emits a structure that fails at compile time when a field is missing. The limits are honest and worth stating. Types come from the samples provided, so a field seen only as null becomes nullable, and one seen as an integer may arrive as a string from a different endpoint. Generating from a real schema beats generating from a sample every time. SQL to ORM goes the other way and is harder to do well. The generator has to guess a data model from query text, and a join between two tables produces a nested structure whose shape depends on assumptions about cardinality. The generated layer is a reasonable starting point and rarely the finished article. Every generated file should carry a header saying so, should be excluded from formatting rules that fight it, and should never be edited by hand. Drift between the generator and a hand-edit is the failure mode that costs the most time, because the next regeneration removes the change silently. One security note belongs with the ORM pages. Query builders make the safe path easy, and raw fragments inside them put it back within reach. Every page covering generated query code shows which calls parameterise and which interpolate.