The first extraction service I shipped at Darmis spent more code parsing the model’s answer than producing it. The LLM would hand back something like “Sure! The insured is John Doe, the policy type appears to be Auto, and the coverage is roughly $500,000 (I think)” — and then a regex, a string-strip, a type-coercion, and a retry loop would try to wrestle that sentence back into a row my database would accept. Half my bug reports were not about wrong answers. They were about right answers in a shape the next function couldn’t read, because the model rephrased one word and my parser fell off a cliff.
Guaranteed JSON schema conformance kills that whole layer. Not automates it. Removes it. When the API contract says the response will match this schema, the parse-then-validate-then-retry pipeline has nothing left to do.
Left: free-text output and the parser you have to babysit around it. Right: the same request constrained to a schema, where the typed object is the boundary and downstream code reads it straight.
The real shift is upstream, though, and it’s a design decision more than an API feature. Design the system around structured outputs from the start and the schema stops being a thing you validate against — it becomes the contract between the model and your business logic. That’s how we do form extraction at Darmis: every field maps to a typed slot with a confidence score, not a bag of text some downstream function has to interpret and hope. The output is data. It was always supposed to be data. We just spent a few years pretending an LLM’s prose was a reasonable place to keep it.