By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

If You Don’t Understand AI Evals, Don’t Build AI

Ankur Goyal is the Founder and CEO of Braintrust, the AI eval platform used by Replit, Vercel, Airtable, Ramp, Zapier, and Notion, valued at $800 million.

Aakash GuptahostAnkur Goyalguest

Mar 20, 202652mWatch on YouTube ↗

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Evals as the durable moat for AI products (beyond model choice)
Aakash and Ankur frame evals as a core skill for shipping reliable AI products, arguing that product success hinges on the quality of feedback loops. They set the context: models and agent frameworks change quickly, but evals can be a durable investment that compounds over time.
- •Evals are positioned as a foundational competency for building AI products
- •Great AI products depend on strong feedback loops from production to offline testing
- •Model choice and agent wiring are transient; evals and harnesses are the durable moat
- •Evals turn LLM unpredictability into an engineering/product challenge you can systematically improve
Why “vibe checks” are still evals—and when they stop scaling
Ankur reframes informal testing as a legitimate early-stage evaluation method, akin to Paul Graham’s “do things that don’t scale.” As usage grows and more stakeholders contribute, teams need structured, repeatable evals to maintain predictable quality.
- •Vibe checks = a human scoring function applied to model outputs
- •Early iteration can be prompt tweaks/model swaps guided by intuition
- •As production usage scales, manual judgment becomes inconsistent and unscalable
- •Structured evals add software/process for repeatability and predictability
LLMs are imperfect yet capable: the real job is building around them
Ankur explains why it’s hard to tell whether failures come from model limitations or from poor prompting/architecture. Successful builders assume imperfection and design systems—measured with evals—that exploit LLM capability while mitigating unpredictability.
- •LLM failures can be ambiguous: model incapability vs implementation issues
- •Modern winners treat imperfection as solvable via product/engineering iteration
- •Evals provide a systematic way to learn what works and what doesn’t
- •Durable eval artifacts let teams keep improving even as models change
The PM’s role: evals as the modern PRD (quantified product intent)
The conversation shifts to product management: Ankur argues evals are the evolution of PRDs from qualitative specs to quantitative, testable success criteria. This creates leverage for PMs—if the product meets the eval but still feels wrong, the eval must improve.
- •PMs drive creative application of AI beyond traditional software constraints
- •Evals function like a quantifiable PRD: clear pass/fail and measurable quality
- •Engineering can build to an eval even without full domain intuition
- •If product meets eval but still disappoints, PMs refine the eval definition
Claude Code controversy: ‘no evals’ vs informal feedback loops
Aakash raises a viral claim that Claude Code shipped without evals and how that impacts PMs championing evaluation. Ankur argues the claim is misleading: internal dogfooding and feedback is an eval, and structured eval rigor depends on organizational context and domain distance.
- •Engineers building for engineers can rely more on intuition and dogfooding
- •Internal feedback (trying the product + incorporating feedback) is still evals
- •Anthropic is vertically integrated (model + product + users), reducing “distance”
- •In domains like healthcare, structured evals become essential to bridge expertise gaps
Distance from end users determines how much eval structure you need
They formalize the concept of “distance” (from model builders to end users) as the driver of evaluation rigor. As distance increases, teams need more explicit artifacts to capture, communicate, and operationalize feedback—sometimes even to share with model labs.
- •Lower distance (same org/users) enables faster, informal feedback cycles
- •Higher distance requires structured evals to encode user needs and constraints
- •Evals become a communication ledger across teams and even external labs
- •Tooling helps standardize and transmit nuanced failures and requirements
Braintrust’s scale and why top teams invest heavily in evals
Ankur shares Braintrust’s growth, usage patterns, and why high-quality companies adopt evals: they have real PMF, operate at scale, and can’t afford quality regressions. He highlights how agents and richer prompts multiply complexity, making observability/evals mandatory.
- •Braintrust: ~100 people, hundreds of customers, large free-plan footprint
- •Explosion in eval volume and logged data driven by larger prompts + more calls + more usage
- •Companies with PMF can’t rely only on vibes; failures are costly (e.g., fintech)
- •Evals and observability become prerequisites for shipping at high quality
Offline experimentation: why AI teams run ‘12.8 experiments per day’
They unpack what frequent experimentation looks like in AI: unlike classic A/B testing that’s expensive and slow, eval-driven iteration can happen offline on a laptop. Ankur previews a live build to show how dataset + prompt/tool changes become rapid, repeatable experiments.
- •Offline evals let teams iterate without production A/B tests
- •Each run is an experiment: prompt tweaks, tool availability, model swaps
- •Rapid iteration accelerates learning and product evolution
- •Live demo setup: build an eval with a prompt and MCP tools
Evals = data, task, scores: the practical framework
Ankur introduces a simple decomposition of evals into three components and explains why normalized scoring matters for comparability over time. This creates a durable baseline for measuring improvements across changing prompts, tools, and models.
- •Data: inputs (optionally with ground truth) representing user tasks
- •Task: the system under test (single LLM call to full agent/tool workflow)
- •Scores: convert output quality into a normalized 0–1 metric for comparability
- •Normalization forces clarity and enables trend comparisons across iterations
Live demo (part 1): create dataset + prompt, run baseline, confirm it fails
They start from scratch: write a simple system prompt and generate an initial dataset with a model—then refine it toward real workload questions. The first run produces vague, unhelpful answers, reinforcing why formal scoring is needed beyond intuition.
- •Start with a minimal system prompt for answering Linear questions
- •Use a model to draft test inputs, then refine toward realistic workload queries
- •Remove expected answers to avoid hallucinated ‘ground truth’
- •Baseline run shows poor, generic responses—vibe check confirms failure
Build the scoring function: categorical scoring beats fuzzy numeric outputs
Ankur uses Braintrust’s agent (Loop) to generate a scorer that checks whether answers address the question and cite sources for claims. They discuss why not to ask an LLM for arbitrary numbers and why categorical/limited scales can be a practical middle ground.
- •Create scorer criteria: answer the question + cite sources when asserting task facts
- •Avoid unconstrained LLM-generated numeric scores; use clear rubric-based categories
- •Binary isn’t always required; categorical scoring can add useful nuance
- •Validate alignment: scorer gives 0s, matching the human vibe check
Wire up Linear MCP tools, then iterate: tools, prompts, and errors
They connect Braintrust to Linear via MCP, intentionally reducing tool exposure to prevent confusion. Iterations include tightening the system prompt (don’t ask clarifying questions, use tools), considering model upgrades, and debugging partial successes and API errors.
- •Connect MCP server and curate tool list to reduce tool-selection mistakes
- •Models may default to ‘capabilities’ talk instead of executing tool calls
- •Iteration levers: change model, improve system prompt, refine dataset questions
- •Use scores to identify partial success (answered but citation policy mismatched)
Loop-driven iteration: improve scorer and prompt until performance jumps
They use Loop to adjust an overly harsh scoring rule and to rewrite the system prompt with concrete tool-usage instructions and examples. The eval score improves dramatically (to ~0.75), illustrating the full workflow: refine dataset, task/prompt, and scoring together.
- •Update scorer to better match real-world citation signals (e.g., referencing task IDs)
- •Have Loop regenerate prompt with explicit instructions and few-shot/tool patterns
- •Versioning allows safe experimentation and reversion
- •Outcome: major score improvement demonstrates end-to-end eval iteration loop
Evals that fail: using benchmark misses to time product bets on new models
Ankur argues teams must maintain evals that currently fail to understand real limits and to detect step-changes when new models arrive. They discuss how benchmark improvements can be misleading and why quick, imperfect datasets plus iteration often beat months of ‘golden set’ perfectionism.
- •If all evals pass, you’re blind to user pain or current impossibilities
- •Rerun failing evals on each new model release to spot capability jumps
- •Benchmark ‘ups’ can indicate benchmark issues; validate with real examples
- •Start simple and iterate rather than overinvesting upfront in perfect datasets
Offline vs online evals: deploying scorers to production logs and closing the loop
They distinguish offline evals (running against curated datasets) from online evals (running scorers on real user logs in production). Online scoring reveals mismatches between lab conditions and reality and feeds new failure cases back into the offline dataset for continuous improvement.
- •Offline: controlled dataset evaluation for fast iteration and regression tracking
- •Online: run the same scorers against production traces/logs
- •Use discrepancies (offline 0.75 vs online 0.3) to diagnose real-world gaps
- •Promote low-scoring real examples into the offline dataset to strengthen coverage
Maintaining an eval culture: daily rituals, not gatekeeping
Ankur explains that strong teams treat evals as part of the daily improvement loop rather than a final release gate. Reviewing production examples in standup, updating datasets, and iterating through the day creates shared trust and prevents bypassing evaluation when shipping.
- •Best teams use evals to guide iteration, not as a compliance hurdle
- •Daily review of real user outputs helps detect new patterns and failures
- •Add novel failures to datasets, then focus engineering on improving those cases
- •Evals become a prioritization tool and shared language across functions
Where to go deeper: Braintrust resources, conference, and closing takeaways
They wrap with ways to engage Braintrust and learn from practitioners, plus Aakash’s encouragement for PMs to build eval skills as a career advantage. The episode closes with calls to subscribe and explore the tooling bundle.
- •Braintrust links: website, direct contact, and community channels
- •Trace conference pitched as practitioner-led, implementation-focused content
- •Aakash’s takeaway: eval literacy is becoming table stakes for PMs
- •Outro includes subscription/review requests and tool bundle mention

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.