← All speakers

Doug Guthrie is a solutions engineer and open-source developer whose work spans financial-data software, analytics infrastructure, and AI application evaluation. He created yahooquery, built developer tools around dbt, and joined Braintrust in 2025 to help teams measure and improve AI products.

Earlier in his career, Guthrie worked in financial services as a data analytics manager. Building an internal application that required market information inspired yahooquery, an open-source Python interface to unofficial Yahoo Finance endpoints. First released in 2019, the library supports multiple ticker symbols, asynchronous requests, and pandas DataFrames; Guthrie described its origins in his article about accessing Yahoo Finance data.

He later worked at dbt Labs as a senior solutions architect. His dbtc project provides a Python interface to dbt Cloud’s REST and GraphQL metadata APIs, while his dbt Semantic Layer voice agent combines conversational queries, semantic search, and visualizations to make governed business metrics accessible through voice or text.

Guthrie had recently joined Braintrust when he appeared at the 2025 AI Engineer World’s Fair; the 2026 event also identified him as a Braintrust solutions engineer. His introduction to practical AI evaluations outlines an engineering approach to unreliable model outputs:

  • Start with a usable evaluation baseline. Define the task, assemble representative examples, and select scorers; improve the dataset and application together instead of waiting for a perfect test suite.
  • Use targeted, calibrated scoring. Separate deterministic checks from LLM-as-a-judge scoring, evaluate accuracy and formatting independently, and compare automated judgments with human assessments. Stronger models can assess outputs from cheaper production models.
  • Inspect individual workflow steps. Span-level evaluation can expose a misinterpreted question, failed tool call, or weak retrieval result before the error contaminates an entire agentic workflow.
  • Connect production behavior to future tests. Turn low-scoring traces, user feedback, and human-reviewed edge cases into new evaluation examples, while tracking model costs, latency, and regressions through development and deployment.

Guthrie’s projects follow a consistent practical orientation: give developers clearer interfaces to complicated systems and the evidence needed to improve them.

Read the topics behind these talks

2 conference talks

Key ideas

Scroll to read ↓

Build evaluations from tasks, datasets, and focused scorers, then use experiments, production traces, and human review to improve the same application.

  • Did that change make the application better?
    0:17 ↗
  • A task, a dataset, and a scorer
    6:52 ↗
  • Build the task and its test cases
    10:39 ↗
  • Give each scorer a focused job
    14:34 ↗
  • Compare changelog models in the playground
    17:14 ↗
  • Use evaluation results to guide a prompt edit
    21:12 ↗
  • Publish assets and run evaluations from code
    23:35 ↗
  • Instrument the behavior you need to inspect
    27:43 ↗
  • Keep production spans compatible with evaluation cases
    32:19 ↗
  • Turn feedback into a review queue
    35:03 ↗
  • Find the step that caused the bad answer
    36:55 ↗
  • Curate cases and calibrate the evaluators
    40:52 ↗
  • Use evaluation evidence before launch and beyond the platform
    45:43 ↗

Key ideas

Scroll to read ↓

Notion’s evaluation workflow and a Braintrust changelog workshop show how to turn product expectations, production traces, and human feedback into repeatable tests.

  • When a successful demo is not enough
    1:43 ↗
  • More capable products create harder evaluation data
    6:27 ↗
  • Turn a Jira connector into a targeted test
    9:31 ↗
  • Write expectations as rules, not frozen answers
    13:04 ↗
  • A judge needs a scope—and someone to inspect its failures
    16:54 ↗
  • Control retrieval inputs and plan model fallbacks
    24:04 ↗
  • Build an evaluation from a task, dataset, and scorer
    28:35 ↗
  • Compare two changelog prompts
    42:27 ↗
  • Choose the right unit of evaluation
    55:11 ↗
  • Run the same evaluation from TypeScript
    1:03:09 ↗
  • Make production traces usable as evaluation data
    1:10:03 ↗
  • Follow a changelog request into a failure view
    1:14:47 ↗
  • Attach user feedback and expert review to the same evidence
    1:24:00 ↗
  • Keep complex execution in code and expose the experiment
    1:35:59 ↗

References