← 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

4 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 ↓

A changelog generator provides a practical path through prompt comparisons, code-defined evals, production tracing, and human feedback that improves both the application and its judges.

  • How do you know a change makes an AI application better?
    0:48 ↗
  • Task, dataset, scorer
    7:20 ↗
  • Expand the task without losing the test boundary
    11:34 ↗
  • Connect the changelog application
    21:08 ↗
  • Evaluate accuracy, completeness, and formatting separately
    27:15 ↗
  • Publish resources, then run evaluations
    35:08 ↗
  • Treat the judge as something to evaluate
    40:46 ↗
  • Inspect rationales and investigate disagreement
    47:32 ↗
  • Keep experiments as the historical record
    53:00 ↗
  • Trace the application and score live traffic
    55:19 ↗
  • Turn scored logs into regression cases
    1:04:29 ↗
  • Use human feedback to improve the application and the judge
    1:10:14 ↗
  • Keep the evaluation connected to the changing application
    1:15:44 ↗

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 ↗

Key ideas

Scroll to read ↓

Doug Guthrie connects tracing, online scoring and topic discovery to a practical improvement loop: find support-agent failures, turn them into evaluation cases, and give a coding agent enough context to propose reviewable changes.

  • Traces supply the intermediate evidence; scorers and topic labels make relevant failures easier to find within a large stream.
    5:19 ↗
  • Custom facets can reveal domain-specific workflow problems that default issue classification misses, as the support-agent record-lookup example shows.
    1:06:43 ↗
  • Production failures belong in evaluation datasets so fixes can be checked against both new edge cases and previously preserved behavior.
    1:13:52 ↗
  • A coding assistant needs repository access plus selected trace evidence to propose concrete changes. The CLI and improvement skill connect those two kinds of context.
    1:15:48 ↗
  • Automation can package code changes, reasons, regression cases and evaluation evidence into a pull request; a reviewer still decides whether the proposal should ship.
    1:45:21 ↗
  • Remote evaluations let collaborators change exposed prompts and models in a playground while agent execution stays on the evaluation server.
    1:47:32 ↗

References