hawkes.aiKey ideas
- The one idea — To wire AI into software, force structured JSON output instead of chatty prose — machine-readable fields a program can parse.
- How it is shown — A chatty answer a program can't parse, versus the same information as clean JSON that slots straight into code.
- The trap to avoid — Asking for JSON and assuming you'll get valid JSON — the model can still add prose, markdown fences, or malformed syntax.
- What it sets up — Asking isn't guaranteeing — so how do you FORCE validity?
The gap between an AI demo and an AI product is often one boring thing: output a program can parse. Prose breaks pipelines. Structure is the bridge.
The one idea
To wire AI into software, force structured JSON output instead of chatty prose — machine-readable fields a program can parse.
You got a great answer — but it came back as friendly prose: "The total is forty-two dollars, ships Tuesday." The software waiting to use it can't read that. To wire AI into a program, it has to stop being chatty and speak a language machines parse: JSON. This is structured output. Software doesn't want a sentence; it wants fields. Not "the total is forty-two dollars," but a labeled slot: total, forty-two. JSON is exactly that — data in labeled key-value pairs a program reads directly. The moment AI must feed a database, an app, or a tool, free-form text won't do. The basic approach is to ask. Tell the model to respond in JSON, and — crucially — give it the exact shape: these keys, these types, like this example. Many APIs ship a JSON mode that enforces the syntax outright.
How it works — the demo
A chatty answer a program can't parse, versus the same information as clean JSON that slots straight into code.
Show schema and example, and most of the time you get clean, parseable JSON. Most of the time. But "most of the time" is the problem. Because the model is still predicting tokens, asking doesn't guarantee. It might wrap the JSON in prose, fence it in markdown, add a trailing comma, or forget a bracket — and one malformed character makes it unparseable, crashing the software downstream. For a one-off, a rare bad JSON is a shrug. For a system making thousands of calls, a small failure rate means constant crashes. One in fifty malformed, and an app doing millions of calls fails all day. Prose-to-program plumbing must be reliable, not usually-right. You need a guarantee.
The trap to avoid
Asking for JSON and assuming you'll get valid JSON — the model can still add prose, markdown fences, or malformed syntax.
Why it matters — and what’s next
Asking isn't guaranteeing — so how do you FORCE validity?
The trap: assuming "respond in JSON" means always-valid JSON. You won't — the model can still be chatty, fenced, or malformed, because it's predicting text, not enforcing syntax. Never pipe raw output into a parser assuming success. At minimum, validate and retry. Better: make invalid output impossible. So structured output is how AI plugs into software — but asking for JSON only gets you usually-valid, and usually isn't enough for real systems. Which raises the real question: can you force the model so malformed JSON isn't unlikely but impossible? You can, and the trick is beautiful. Next: forcing valid output with grammars.
This is one short episode in AI: Zero → Frontier, a step-by-step climb through how AI actually works. Each episode builds only on the ones before it.
Full transcript 2:30 of narration
You got a great answer — but it came back as friendly prose: "The total is forty-two dollars, ships Tuesday." The software waiting to use it can't read that. To wire AI into a program, it has to stop being chatty and speak a language machines parse: JSON. This is structured output.
Software doesn't want a sentence; it wants fields. Not "the total is forty-two dollars," but a labeled slot: total, forty-two. JSON is exactly that — data in labeled key-value pairs a program reads directly. The moment AI must feed a database, an app, or a tool, free-form text won't do.
The basic approach is to ask. Tell the model to respond in JSON, and — crucially — give it the exact shape: these keys, these types, like this example. Many APIs ship a JSON mode that enforces the syntax outright. Show schema and example, and most of the time you get clean, parseable JSON. Most of the time.
But "most of the time" is the problem. Because the model is still predicting tokens, asking doesn't guarantee. It might wrap the JSON in prose, fence it in markdown, add a trailing comma, or forget a bracket — and one malformed character makes it unparseable, crashing the software downstream.
For a one-off, a rare bad JSON is a shrug. For a system making thousands of calls, a small failure rate means constant crashes. One in fifty malformed, and an app doing millions of calls fails all day. Prose-to-program plumbing must be reliable, not usually-right. You need a guarantee.
The trap: assuming "respond in JSON" means always-valid JSON. You won't — the model can still be chatty, fenced, or malformed, because it's predicting text, not enforcing syntax. Never pipe raw output into a parser assuming success. At minimum, validate and retry. Better: make invalid output impossible.
So structured output is how AI plugs into software — but asking for JSON only gets you usually-valid, and usually isn't enough for real systems. Which raises the real question: can you force the model so malformed JSON isn't unlikely but impossible? You can, and the trick is beautiful. Next: forcing valid output with grammars.