Quick answer: OpenAPI code generation turns a contract into typed clients, server stubs, or models, so the types your code compiles against are the same types the service serves. The direction that pays off is spec-first: author the OpenAPI, generate the client and stubs, and never hand-edit the generated output. The reverse direction — generating a spec from running code — is useful for recovering a legacy service, but it is a starting point to verify, not a substitute for design.

This guide covers both directions, the naming decisions that make generated code usable, and the ways generated types silently drift or get hollowed out with any. Follow the links for the concrete setups.

The two directions, and why they differ

Generating code from a spec is a build step; generating a spec from code is a recovery step. Conflating them is where teams get into trouble. The distinction is argued in generating code from the spec, not reverse engineering it. In a spec-first workflow, the contract is reviewed and versioned, and the generated code is a disposable artifact; in a code-first workflow, the generated spec is a draft that must be checked for things the framework cannot infer.

Generating a typed client

The most common generation target is a client that encodes every operation, parameter, and response type, so calling the wrong shape is a compile error. The TypeScript case is in generate a TypeScript client from OpenAPI. For the generated names to be stable and sensible, the contract metadata has to be right; operationId and tag naming conventions explains how codegen turns those into function names.

Recovering a spec from running code

When the service already exists and there is no contract, generate a draft from the framework's routes and then verify it against real traffic. The routes differ by stack: generate OpenAPI from Express and NestJS, and generate OpenAPI from FastAPI and Django REST, with the general approach in generate OpenAPI from existing code. The honest limits of automated recovery — where a tool or an AI cannot know the intended constraints — are in AST vs AI reverse engineering and the gaps.

Scanning without hallucinating

AI can accelerate recovery, but it also invents endpoints and fields that do not exist. The safe approach is to derive structure from the actual code and let the AI only fill in descriptions, then verify every operation against the running service. The method is in scan code into OpenAPI without hallucinating, and the full workflow of turning that result into tests and mocks is in from a scanned spec to mocks, tests, and an MCP server.

The silent failures of generated code

Generated code only helps if it stays in sync and keeps its types. Three failure modes recur and are worth a CI check:

Even a green typecheck is not proof of runtime correctness; typecheck green while the runtime value was never validated is the gap between compile-time and runtime. Numeric edge cases also need explicit handling in generated clients; int64, bigint, and decimal money covers the values that overflow a JS number.

Where to go next

Code generation is downstream of a good contract. Return to the OpenAPI guide for the modeling decisions, and verify the generated client with the API testing guide. When you want the same contract to drive AI agents rather than only typed code, read the MCP server guide.

FAQ

Should I commit generated code? Either regenerate in CI and leave it out of the commit, or commit it and fail the build on a diff — the key is one authoritative source. Never hand-edit generated files, because the next regeneration overwrites them.

Why are my generated types full of any? Usually because the schema uses free-form or untyped objects, or the generator is configured loosely. Tighten the schema with explicit types and additionalProperties before blaming the generator.

Can codegen replace writing tests? No. It guarantees the types match the contract; it does not verify the business behavior. Keep scenario tests on top of the generated client.