Get AI summaries of any video or article — Sign up free
AI Programming: Exploring GPT-4o Structured Output / Future of Software Dev ++ thumbnail

AI Programming: Exploring GPT-4o Structured Output / Future of Software Dev ++

All About AI·
5 min read

Based on All About AI's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Structured outputs are built to make LLM responses exactly match developer-supplied JSON schemas, unlike JSON mode which improves JSON formatting without guaranteeing schema validity.

Briefing

Structured outputs are moving from “best-effort JSON” to schema-locked reliability, and early hands-on tests show why that matters for real software workflows. OpenAI’s structured output feature in the API is designed to make model responses exactly match developer-supplied JSON schemas—something JSON mode improves but doesn’t guarantee. In OpenAI’s own evaluation framing, setting strict mode to true yields perfect schema adherence (100%), while earlier JSON-schema evaluations for GPT-4 reportedly scored under 40%. For developers, the practical payoff is fewer brittle parsing failures and less glue code built around prompt workarounds.

The stream then turns that promise into repeatable experiments. The workflow starts by transcribing YouTube videos using Whisper via the API, then feeding the transcript into a structured-output call with a Pydantic-defined schema. One test extracts “shocking statements” and named entities from a political speech transcript, returning a clean JSON structure with both the extracted claims and the people mentioned (including names like Donald Trump, JD Vance, and others). A second test swaps the schema to extract AI model names from another creator’s video, successfully pulling out a list of model references (e.g., GPT-5, GPT-4, GPT-4o mini, Claude variants, Llama variants, and others). A third pass extracts company/person names from the same transcript, again producing structured JSON that’s easy to store, search, or feed into downstream systems.

Beyond extraction, the discussion highlights where reliability still depends on what’s being asked. “Shocking statements” are inherently subjective, and sentiment tagging can be less useful when the target isn’t a factual label. Finance-leaning extraction (e.g., “finance statements” and stock tickers) is treated as a more deterministic target, though the transcript notes that schema design and field definitions still matter—such as formatting dates in ISO form. The hands-on results also show how quickly developers can iterate: change the Pydantic model, rerun the structured output step, and the output shape updates without rewriting the whole pipeline.

The conversation broadens into the future of software engineering. A widely viewed tweet thread by Russell Kaplan argues that coding models will become extraordinarily strong, and that code is uniquely testable—models can write code, run it, and verify via tests or self-consistency. That leads to “coding agents” that handle end-to-end tasks, shifting engineers toward requirements, architecture, and delegation—an “engineering manager” role for many teams. The stream’s host agrees with the macro trend but remains skeptical about scaling to massive codebases immediately, emphasizing that testing infrastructure and agent reliability will become more important as agents write more.

Finally, the stream connects structured outputs to broader developer tooling: longer output windows (e.g., GPT-4o’s higher max output tokens), schema reliability for database ingestion, and comparisons to other structured-output approaches (like Instructor-style tooling for multiple model providers). The core takeaway is clear: schema-locked structured outputs make LLM-driven extraction and automation far more dependable, and that reliability is a key ingredient for the next wave of agentic software development.

Cornell Notes

Structured outputs aim to make LLM responses exactly match developer-provided JSON schemas, addressing a long-standing gap where JSON mode improves readability but doesn’t guarantee schema validity. In the stream’s experiments, transcripts from YouTube videos are generated with Whisper and then fed into structured-output calls using Pydantic schemas to extract entities like “shocking statements,” AI model names, and people/company names into clean JSON. The results are fast to iterate—changing the schema changes the output shape—making it practical for building pipelines that store, search, or analyze extracted data. Reliability is strongest when the target is well-defined; subjective labels (like “shocking”) and sentiment can be noisier. The broader context links this reliability to coding agents and a future where engineers delegate more work to end-to-end coding systems.

What problem does structured output solve compared with JSON mode?

JSON mode improves the readability of JSON responses, but it doesn’t guarantee the model’s output will conform to a specific schema. Structured outputs are designed to reliably adhere to developer-supplied JSON schemas, with strict mode highlighted as producing perfect schema matching in evaluation (100% adherence). That matters because downstream code can treat the output as valid data instead of writing extra validation and repair steps.

How did the experiments turn unstructured video transcripts into structured data?

The workflow used Whisper (via the API) to transcribe a YouTube video into text, then split the transcript into chunks when it was too large. After transcription, the transcript text was passed into a structured-output request with a Pydantic schema defining the desired fields. The model returned JSON containing the extracted items—such as “shocking statements” plus names, or lists of AI model names—ready for storage or further processing.

Why is schema design (and field definitions) crucial even with structured outputs?

Structured outputs enforce the output shape, but the quality of extracted content still depends on what the schema asks for and how fields are defined. For example, extracting model names works well when the schema expects a list of strings, while extracting dates requires specifying an ISO date format. Subjective targets (like “shocking statements”) and sentiment labels can produce noisier results because the underlying labels aren’t purely factual.

What did the stream suggest about scaling from extraction to agentic software development?

The discussion ties schema reliability to agent workflows: if extracted data can be trusted, agents can feed it into databases, decision systems, or multi-step pipelines with fewer failures. In the broader future-of-software-engineering thread, coding agents are expected to write code and tests, then verify results automatically—shifting engineers toward higher-level architecture and delegation rather than manual implementation.

How does “code is testable” support the argument for coding agents?

The Russell Kaplan thread emphasized that unlike many domains where verification is hard, code can be tested empirically. Models can generate code, run it, and check for correctness via tests or self-consistency loops. That testability is presented as a reason coding agents can improve faster and become more reliable than agents in areas where outcomes can’t be validated automatically.

Review Questions

  1. When would strict schema adherence matter most in an LLM pipeline—what downstream failure does it prevent?
  2. In the transcript-to-JSON workflow, what role do chunking and Pydantic schemas play, and what changes when the schema changes?
  3. Which extraction targets are likely to be less reliable (and why): subjective claims, sentiment labels, or factual entities—and how would you redesign the schema or prompts to compensate?

Key Points

  1. 1

    Structured outputs are built to make LLM responses exactly match developer-supplied JSON schemas, unlike JSON mode which improves JSON formatting without guaranteeing schema validity.

  2. 2

    Strict mode is presented as producing perfect schema adherence in evaluation, reducing the need for fragile parsing and repair logic.

  3. 3

    A practical pipeline emerged: transcribe video with Whisper, chunk long transcripts, then extract entities into JSON using Pydantic-defined schemas.

  4. 4

    Changing the Pydantic schema quickly changes what gets extracted (e.g., shocking statements + names vs. AI model names vs. people/company names).

  5. 5

    Targets that are subjective or label-based (e.g., “shocking statements,” sentiment) can be noisier even when the JSON structure is correct.

  6. 6

    The broader software-engineering outlook links schema reliability and testability to coding agents that can write code and tests, shifting engineers toward architecture and delegation.

  7. 7

    Longer output windows (like GPT-4o’s higher max output tokens) are treated as an important enabler for larger code-generation and analysis tasks, though cost and access still matter.

Highlights

Structured outputs aim for schema-locked reliability: strict mode is framed as 100% adherence to JSON schemas, unlike JSON mode’s best-effort behavior.
A transcript-to-JSON workflow worked end-to-end: Whisper transcription → chunking → Pydantic schema → clean JSON extraction of claims and names.
Schema iteration was fast: swapping the Pydantic model changed the extracted fields without rebuilding the pipeline.
The future-of-software-engineering argument hinges on code testability—models can write code, run it, and verify automatically, enabling coding agents.
Coding agents are expected to shift engineers from writing everything to delegating tasks and focusing on requirements and system architecture.

Mentioned