We are currently seeing a push toward structured outputs in the AI landscape. Every major LLM provider now allows you to enforce that a model returns a response matching a specific JSON structure. This is a game-changer for building reliable AI agents and integrations. However, beneath the surface, we are running into a familiar dilemma: the reliance on JSON Schema.
If you look closely at how different AI companies implement structured outputs, you will notice a trend. Almost every provider has basically invented its own distinct flavor or subset of JSON Schema. OpenAI has specific constraints on what keywords are supported, Anthropic does things slightly differently, and tooling providers are left writing translation layers.
The reality is that JSON Schema was never designed for code generation or clean data modeling. It was designed to validate and describe almost any arbitrary, dynamic JSON structure.
The Validation vs. Modeling Problem
Because JSON Schema focuses heavily on flexible validation rather than structural modeling, it contains complexity.
This becomes obvious if you look at advanced keywords like if, then, else, or
dependencies. While these are powerful for asserting runtime rules on a dynamic JSON payload, they are not
optimal when you try to translate a schema into clean, typed programming structures like an object, class, or record.
We have actually seen this exact scenario play out before in the API space. When the OpenAPI specification was gaining adoption, the maintainers realized that the full JSON Schema specification was simply too loose and complex to reliably generate clean SDKs and server stubs. To solve this, OpenAPI had to define a constrained subset of JSON Schema (historically called the OpenAPI Schema Object) just to make data modeling and code generation predictable.
History is repeating itself with AI structured outputs. LLMs need a clear, deterministic structure to target, and developers need to turn that output into strict types in their codebases. Full JSON Schema is simply the wrong tool for this job, which is exactly why every AI vendor is forced to trim it down into their own custom, incompatible variants.
A Cleaner Path Forward: TypeSchema
The software world would be a much easier place if we could all rely on a single, clean specification built from the ground up for data modeling. Of course, JSON Schema is established and TypeSchema isn't here to replace it overnight. Instead, it serves as an elegant alternative, a high-level, developer-friendly modeling layer that sits seamlessly between your code and the AI ecosystem.
1. Robust DTO Generation
First and foremost, TypeSchema is built for code generation. From a single schema definition, you can instantly generate clean, strongly-typed Data Transfer Objects (DTOs) for almost any popular programming language, including TypeScript, PHP, Python, Java, Go, Rust, C#, and more. This means the exact same definition that powers your backend validation also generates the models your developers use every day.
2. Tailored AI Schema Targets
On top of native DTO generation, TypeSchema acts as a smart cross-compiler for the fragmented AI landscape. Instead
of manually wrestling with the quirky constraints of every LLM provider, you maintain your models in TypeSchema and
automatically export them to specific target environments using dedicated compilers like jsonschema-openai
or jsonschema-anthropic.
By using TypeSchema as your single source of truth, you bridge the gap between your application code and your AI agents. You get clean, deterministic classes and types for your own codebase, while remaining effortlessly compatible with every major LLM provider.
Structured output is the key to making LLMs truly useful in production software. By moving past the JSON Schema dilemma and embracing a modeling-first approach, we can finally stop writing endless translation layers and focus on building great features.