Pack Génération de Code Spécialisée

What's in this pack

LLM-powered editors are great at one-off code completion, but they are not the right tool when you need the same translation a thousand times — every PR, every API change, every new migration. For that you want deterministic generators with a spec as input. This pack is the working dev's curated set of those generators, plus two AI helpers that handle the fuzzy ends (project scaffold, natural-language regex).

The whole set covers seven niche translation jobs in one rig:

• Project scaffold from a template (Cookiecutter) or from a prompt (Meta Agentic Project Scaffold)
• OpenAPI spec → client SDKs and server stubs (OpenAPI Generator)
• SQL queries → type-safe code (sqlc)
• GraphQL schema → typed resolvers and server (gqlgen)
• JSON Schema → static TypeScript types (TypeBox)
• TypeScript-first validation that doubles as types (Zod)
• Schema-first natural-language UI to structured code (TypeChat)
• Regex from natural-language examples (grex)
• Parser generators for a new DSL or grammar (Tree-sitter)

None of these compete with your coding agent. They sit underneath it. The agent writes the spec; these tools turn the spec into the same code your handwritten version would have been, only without the typos.

Install in this order

1. Cookiecutter — start with the project skeleton. Pick a template, answer five prompts, get a populated repo. This is the lowest-friction win and sets the layout every other tool plugs into.
2. Meta Agentic Project Scaffold — when there is no template that fits, let an AI agent walk you through scaffolding one. The Claude Code agent asks the right questions, writes the directory tree, and seeds the configs. Pair with Cookiecutter to capture the result as a reusable template next time.
3. OpenAPI Generator — install once, generate client SDKs in 60+ languages and server stubs in 40+. Pin the version in CI. The moment you publish openapi.yaml, every consumer (your mobile app, your partner, your internal services) gets a regeneratable client.
4. sqlc — write plain SQL queries in a .sql file, sqlc generate emits type-safe Go (or Kotlin, Python) functions that wrap them. You stop translating SELECT rows into structs by hand. The compiler catches column renames before tests do.
5. gqlgen — schema-first GraphQL for Go. Write schema.graphql, run codegen, get strongly-typed resolver interfaces. You implement the business logic; the wiring is generated. Symmetric to sqlc on the API side.
6. TypeBox — JSON Schema and TypeScript static types from one source of truth. Define the schema once; get both runtime validation and .d.ts types. Fastify and Ajv plug in directly.
7. Zod — TypeScript-first schema validation. Same idea as TypeBox but the schema is the TypeScript expression itself. Pick TypeBox when you also need raw JSON Schema output for OpenAPI; pick Zod when you live entirely in TS.
8. TypeChat — Microsoft's library for getting structured, schema-conforming output from an LLM. Define the response shape as a TypeScript type; TypeChat coerces the model into compliance. The bridge between your AI-generated code and your typed runtime.
9. grex — paste examples, get a regex. Catches the edge cases your regex would have missed by induction. Faster than asking the LLM, deterministic, no token spend.
10. Tree-sitter — incremental parser generator. The day you decide your config file or your DSL needs first-class IDE support, this is the tool. Used by Neovim, GitHub semantic search, and most modern editors for syntax intelligence.

How they fit together

Cookiecutter / Meta Agentic Scaffold
   │
   └── creates a fresh repo with consistent layout
        │
        ├── openapi.yaml ──── OpenAPI Generator ───► clients/, server-stubs/
        │
        ├── queries.sql ───── sqlc ─────────────────► db/typed-queries.go
        │
        ├── schema.graphql ── gqlgen ──────────────► resolvers.go (typed)
        │
        ├── *.schema.json ─── TypeBox ─────────────► types.d.ts + validators
        │                          │
        │                          └── feeds OpenAPI Generator and Ajv
        │
        ├── Zod (TS-only)   ───────────────────────► z.infer<typeof X>
        │
        └── TypeChat ───────────────────────────────► LLM-shaped output → typed runtime

Niche helpers (independent):
   grex (examples → regex)
   Tree-sitter (grammar → incremental parser)

The spine is scaffold → spec → generate. Every spec file becomes a CI step: regenerate, diff, fail the build if the generated code drifts from what is committed. This is the discipline that makes codegen scale across a team.

Tradeoffs you will hit

• TypeBox vs Zod — TypeBox emits raw JSON Schema as a byproduct, so it plugs into OpenAPI Generator and Ajv without translation. Zod has the friendlier TypeScript ergonomics and a larger ecosystem (tRPC, Hono, Next.js). Most projects pick one; some use TypeBox at the API boundary and Zod inside the app.
• sqlc vs Prisma/Drizzle — sqlc starts from SQL and generates code; Prisma and Drizzle start from a TypeScript schema and generate SQL. sqlc wins when the DB is the source of truth and you have DBAs writing the queries. Prisma/Drizzle win when the app team owns the schema. They are not direct competitors of this pack — this pack is for SQL-first teams.
• gqlgen vs code-first GraphQL — gqlgen is schema-first: the .graphql file leads, code follows. Apollo Server in TS can go code-first. Schema-first scales better across language boundaries (frontend reads the same file).
• OpenAPI Generator vs hand-written clients — generated clients can be uglier than handwritten ones. The win is not aesthetic, it is the regenerate-on-spec-change loop. If your spec never changes, hand-write. If it changes every sprint, generate.
• TypeChat vs raw function-calling — function-calling APIs from providers are converging on the same idea. TypeChat is library-not-API, runs against any model, and gives you retry and repair loops. Use it when portability matters or when you want the retry logic for free.

Common pitfalls

• Not committing the generated files — debated for years. The pragmatic answer for most teams: commit them. Reviewers can see the diff, CI can verify regenerate-is-clean, new contributors do not need toolchain on day one. Generate-on-build only when the toolchain is universally available.
• Drift between spec and code — every generator needs a CI step that runs the generator and fails on diff. Without this, the spec and code silently desync.
• Pinning the generator version — OpenAPI Generator and sqlc both occasionally emit different code between minor versions. Pin in CI or you get noisy diffs that have nothing to do with your changes.
• Tree-sitter grammar debugging — the first grammar you write will have ambiguities. Use the tree-sitter test corpus from day one; do not try to debug by reading the parse tree by hand.
• TypeChat retries swallowing real bugs — TypeChat retries when the LLM returns malformed output. If your schema is wrong, it retries forever. Log the failures and set a max-attempts cap.