← All speakers

Bio, Work & Ideas

Jason Liu

Conference affiliation: Developer Experience, OpenAI · OpenAI · 2026

Jason Liu is a developer experience engineer on OpenAI’s Codex team and the creator of Instructor, the open-source library that helped establish structured outputs as a practical foundation for language-model applications. His work gives developers concrete ways to make AI systems predictable: typed schemas, validated responses, actionable evaluation, and agent workflows that preserve context without surrendering human oversight.

Liu studied computational mathematics and statistics at the University of Waterloo, worked as a data scientist at Meta, and became a staff machine-learning engineer at Stitch Fix. There, he built Flight, a framework for moving recommendation logic into observable, maintainable production systems. He subsequently founded 567 Studios and developed a consulting and education practice focused on retrieval, evaluation, and AI products; his teaching continues through Systematically Improving RAG.

Instructor distilled that experience into a lightweight interface built around Pydantic models, Python type hints, validation, and retries. Developers describe the object they need; the model returns structured data that conventional software can inspect and use. Liu released Instructor 1.0 in 2024, extending support across providers and programming languages. OpenAI later named Instructor among the projects that inspired its Structured Outputs API.

  • Structure is an engineering contract. Liu treats schemas as executable specifications encompassing the prompt, response, and business rules. Validators can catch fabricated URLs, inconsistent receipt totals, and unsupported claims; informative errors enable targeted retries. Typed search requests can encode dates, sources, and dependencies, letting conventional software execute retrieval plans and parallel searches. His work on Pydantic and language models argues that developers should retain ownership of objects, functions, and control flow.
  • Impact-weighted product evaluation. His open-source Kura project summarizes and clusters chatbot conversations to identify recurring requests, frustration, tool failures, and differences between user segments without exposing individual conversations. Combining usage with performance reveals whether a team should repair a heavily used weakness, promote an overlooked capability, or disregard an inconsequential edge case. Evaluation becomes a product-roadmap instrument instead of an isolated quality score.
  • Computer use with permission boundaries. Liu differentiates native computer control, authenticated Chrome sessions, and the in-app browser according to the access each task requires. He emphasizes approval and organizational safeguards around consequential actions, recognizing that an agent capable of switching interfaces can also circumvent restrictions unless its permissions remain explicit.

Liu also writes about taste, attention, and judgment: as AI makes execution easier, recognizing quality and articulating what needs improvement become more valuable. His approach makes automation serve informed human decisions, not replace them.

Talks by Jason Liu

5 talks

Key ideas

Scroll to read ↓

Jason Liu explains how Pydantic models, OpenAI function calling, Instructor, and explicit validation turn language-model outputs into typed objects that existing software can inspect, execute, and maintain.

  • Use Pydantic models to express the output contract in typed, reviewable code and generate the JSON schema needed for OpenAI function calling. 3:04 ↗ 3:58 ↗
  • Treat Instructor as the model-to-object integration layer described in the talk, while recognizing its stated limitation to OpenAI function calling and Liu’s suggestion of Marvin for broader model support. 4:59 ↗ 5:57 ↗
  • Keep field descriptions, docstrings, validation rules, and object behavior together so the prompt and application contract evolve as one reviewable unit. 5:57 ↗ 6:50 ↗
  • Handle invalid or uncertain outputs with explicit validators, bounded retries, optional results, and structured errors instead of relying on sentinel phrases or unverified prompt compliance. 7:51 ↗ 8:47 ↗
  • Represent retrieval requests and query plans as executable data structures so conventional code can select backends, apply filters, schedule parallel work, and resolve dependencies. 11:41 ↗ 12:37 ↗ 13:40 ↗
  • Ground generated answers by requiring supporting excerpts to exist in the source text, while recognizing that substring verification confirms textual presence rather than complete interpretive correctness. 14:36 ↗ 15:28 ↗

Key ideas

Scroll to read ↓

Jason Liu’s workshop connects voice input, application context, a Git-backed memory vault, and persistent threads into workflows that gather context, follow through, and produce reviewable work.

  • The slide deck is already part of the workflow
    1:05 ↗
  • Give ongoing work a durable thread
    3:31 ↗
  • Bring in messy context and connect the applications
    7:49 ↗
  • Turn recurring investigations into skills
    11:36 ↗
  • Capture identifiers as well as pixels
    16:10 ↗
  • Keep the vault central and the code elsewhere
    17:52 ↗
  • Make memory inspectable and skills correctable
    22:12 ↗
  • Use the desktop’s context, then leave the agent to work
    25:03 ↗
  • Separate helpful behavior from enforced boundaries
    30:03 ↗
  • Schedule follow-through in the same thread
    34:02 ↗
  • Carry work from a briefing to a shared deliverable
    37:16 ↗
  • Give long runs a verifier and an editable objective
    40:14 ↗
  • Prepare the next human action
    42:11 ↗
  • Choose the work product, then let the model elaborate
    44:16 ↗
  • Inspect the artifact where the work happens
    50:00 ↗
  • An alternate tool path can cross a security boundary
    52:28 ↗
  • Let a monitor route new evidence to existing work
    55:35 ↗
  • Keep useful records without turning everything into bookkeeping
    59:27 ↗
  • Develop the vocabulary to direct the work
    1:05:00 ↗
  • Manage threads through ordinary requests
    1:06:56 ↗
  • Spend reasoning and wake-ups where they matter
    1:11:19 ↗

Key ideas

Scroll to read ↓

Fast retrieval tests show which changes help your application, while structured conversation analysis reveals where better tools, filters, and workflows will matter.

  • Which documents should retrieval return?
    0:43 ↗
  • Generate questions that resemble real queries
    3:06 ↗
  • Test an embedding change on your application
    4:29 ↗
  • Read the feedback already inside conversations
    7:10 ↗
  • Give an aggregate score some context
    9:12 ↗
  • Extract records you can analyze
    10:08 ↗
  • Use Kura to build a hierarchy of needs
    11:19 ↗
  • Build the capability a segment is missing
    13:08 ↗
  • Prioritize using both usage and performance
    14:10 ↗
  • Monitor categories and test clearer hypotheses
    15:18 ↗
  • Justify an investment by the users it could help
    17:04 ↗
  • Q&A: price the work an agent completes
    18:49 ↗

Key ideas

Scroll to read ↓

Typed responses turn model output into ordinary application data: objects you can validate, stream, search with, render and send to an execution engine.

  • An API should return more than a string
    0:25 ↗
  • Instructor grows around a small interface
    1:54 ↗
  • Return an object, stream objects, or stream a partial
    2:58 ↗
  • Validation errors become conditional instructions
    4:39 ↗
  • Validate relationships across receipt fields
    6:06 ↗
  • Give generated answers a useful shape
    6:41 ↗
  • Turn search intent into a typed request
    7:48 ↗
  • Compose retrieval with two models and two functions
    8:54 ↗
  • Extract labels and meeting records
    9:57 ↗
  • An image table becomes a DataFrame
    10:46 ↗
  • Reliability depends on useful feedback
    12:03 ↗
  • Generate reports and plans for execution
    13:19 ↗
  • Keep ownership of the program
    14:12 ↗

Key ideas

Scroll to read ↓

Useful LLM products depend on domain expertise, deliberate hiring, and a feedback loop that turns real user interactions into evaluations, better decisions, and production guardrails.

  • Six practitioners encounter the same problems
    0:24 ↗
  • Build a product advantage that survives better models
    3:23 ↗
  • Evaluation belongs inside an improvement loop
    6:06 ↗
  • Get real interactions into the loop
    10:01 ↗
  • Prototype for economics that may become possible
    11:57 ↗
  • Buying another shovel does not tell you where to dig
    14:52 ↗
  • Premature model ownership creates the wrong work
    16:23 ↗
  • Evaluation is a core engineering skill
    18:24 ↗
  • Hire for the next stage of the product
    21:00 ↗
  • Turn broad quality goals into testable criteria
    23:54 ↗
  • Choose an evaluator you can align and maintain
    25:41 ↗
  • Inspect recognizable failures with their execution context
    28:34 ↗
  • Turn reference-free evaluations into guardrails
    30:43 ↗
  • The surrounding system still needs maintenance
    32:32 ↗
  • A compelling demo can precede a product by decades
    34:17 ↗

References