Aakash GuptaHow to Build AI Evals Step-by-Step | Daniel McKinnon | Product Growth
CHAPTERS
- 0:00 – 1:43
Why evals matter for PMs: defining success in the AI era
Daniel frames AI as forcing every major tech company—and every PM role—to reinvent how products are specified and measured. He argues that traditional PM work is increasingly automatable, making rigorous evaluation a core differentiator. The conversation tees up evals as the practical bridge between product intent and model behavior.
- •AI reshapes PM work; orchestration/analysis becomes easier with AI
- •Large companies must reinvent product development around AI capabilities
- •Evals become central to defining “success” for AI features
- •Motivation for learning evals as a foundational PM skill
- 1:43 – 3:22
Do evals replace the PRD? Using examples to communicate product behavior
Daniel explains his “evals replace the PRD” provocation: in genAI, describing behavior in prose breaks down because systems must handle many situations. Evals function as concrete examples—“trivia questions for the model”—that specify desired behavior far more precisely than lengthy PRDs. Strategy still matters, but execution details shift to example-based specs.
- •PRDs still need strategy/customer context, but detailed behavior specs are hard in genAI
- •Evals communicate expectations through examples rather than prose
- •Offline eval performance becomes the key proxy for whether users will be satisfied
- •If offline eval fails: change model, harness, or even the product scope
- 3:22 – 4:51
Offline evals vs. shipping to production: why the distinction matters
The discussion clarifies what “offline evals” are and why they precede launching. Daniel uses a recipe/ice-cream example to show how a curated prompt set plus scoring approximates real user traffic during development. Online metrics validate the proxy, but offline evals prevent shipping broken experiences to users.
- •Offline eval = pre-baked prompt set + answer key/scoring run during development
- •Online eval = real user traffic after shipping
- •Offline evals are proxies that reduce risk and speed iteration
- •Example: generate ice-cream recipes; prompts reflect expected user distribution
- 4:51 – 6:53
How evals evolved: from QA benchmarks to agentic, multi-step tasks
Daniel walks through how early evals mirrored public QA benchmarks (MMLU, ARC, HumanEval) and were relatively straightforward to design and score. As models saturated QA, the frontier shifted to agents: tool use, multi-step reasoning, and longer time horizons. This changes what you measure and makes scoring more challenging.
- •Two years ago: evals were mostly question-and-answer style
- •Public benchmarks (MMLU/HellaSwag/ARC/etc.) reflect the old paradigm
- •QA is increasingly saturated; “good models” now solve far harder tasks
- •Modern focus: agents (tool calling, computer use, knowledge work)
- 6:53 – 8:53
The mechanical process of writing an eval (and why easy/hard both fail)
He outlines a repeatable workflow: define the user problem, collect representative prompts, pick “Goldilocks” difficulty, and decide how to score. Easy evals cap out at 100% and provide no room to improve; overly hard evals score near 0% and may be impossible. The goal is an eval that starts around ~25–50% success so teams can iterate toward 100%.
- •Define the problem and what “good” means in measurable terms
- •Create a representative prompt distribution (often ~100 items)
- •Goldilocks difficulty: avoid 0% (too hard) and 100% (too easy)
- •Scoring options: automated rules, LLM judges, or humans (humans don’t scale for agentic tasks)
- 8:53 – 15:34
Why benchmarks get saturated & the shift from “QA thinking” to “task thinking”
Daniel explains why older benchmarks no longer differentiate models and why agentic benchmarks now dominate lab scorecards. The key conceptual shift is from answering a prompt to completing a task with many steps and tools. This retains the same eval framework (problem, prompts, scoring) but expands the complexity of what’s being evaluated.
- •Older QA benchmarks are less informative as models approach ceiling performance
- •Lab scorecards now emphasize agentic coding, tool use, and knowledge work
- •Tasks involve multi-step reasoning + tool calling rather than single answers
- •Agentic scoring needs more automation due to long horizons and complex traces
- 15:34 – 18:06
Live build: choosing a domain—clinical genomics—and why SME is mandatory
Daniel begins constructing an agentic eval in real time using clinical genomics as the domain. He explains whole-genome sequencing interpretation as the bottleneck: transforming massive raw data into a diagnosis is labor-intensive. He stresses that without deep subject-matter understanding, you can’t design meaningful prompts or scoring.
- •Goal domain: AI assistance for clinical genomics interpretation
- •Whole-genome sequencing is valuable but interpretation is costly and slow
- •Pipeline complexity: raw reads → variants → clinical meaning
- •Vertical expertise is why labs hire bankers/lawyers/accountants (and why evals need SME)
- 18:06 – 21:39
Easy-case prompt: cystic fibrosis as a sanity check eval item
To establish the “floor,” Daniel picks cystic fibrosis—an archetypal single-gene disease with a canonical causal gene/variant. He builds the eval schema as a simple table (phenotype → gene/variant) and prepares to test whether an agent can find the known mutation from a genome file. This verifies the basic feasibility of the agent + harness approach before moving to harder cases.
- •Start with an easy, well-understood disease to prove feasibility
- •Define eval row: phenotype (CF) + expected causal variant in CFTR
- •Build the eval as a spreadsheet-style Q/A key
- •Use external sources (e.g., ClinVar) to anchor “ground truth”
- 21:39 – 26:18
Synthetic data + tools: generating a test VCF and running the agentic workflow
Daniel demonstrates how to create a synthetic genome variant file (VCF) containing the target mutation, using an AI coding agent to modify files. He shows what VCF rows look like and how the agent searches within the genome file to identify the causal variant given a phenotype description. The meta-point: teams often use AI to help build evals for AI.
- •VCF files are structured text: chromosome, position, ref/alt, genotype, quality, etc.
- •Create a synthetic “patient” by inserting the CF variant into a VCF
- •Run an agentic prompt: phenotype + genome file → identify genetic cause
- •Using AI to generate/modify eval artifacts accelerates eval creation
- 26:18 – 32:29
Model comparison on the easy case: why “start easy” reveals surprises
Testing multiple agents/models shows strong systems identify the CFTR deletion correctly, while a smaller model (Haiku) fails—hallucinating and missing the canonical variant. This underscores why you must empirically validate difficulty: what seems trivial to an expert may be too hard for the model you need for cost/latency reasons. The eval immediately informs model selection and harness improvements.
- •Frontier/higher-capability agents solve the CF case quickly and accurately
- •Haiku fails despite focusing on CFTR—misses the specific variant and hallucinates
- •The same eval can be “easy” for one model and “hard” for another
- •Outcome drives decisions: add hints/constraints, improve tools, or pick a stronger model
- 32:29 – 39:52
Hard-case eval design: digenic congenital heart disease & finding the model ceiling
Daniel escalates to a harder research-backed scenario: congenital heart disease caused by a combination of variants across two genes (digenic). He pulls examples from a paper’s supplementary table and structures them into the eval format. This step is about identifying the “ceiling”—tasks that current systems fail without a stronger, specialized harness.
- •Digenic diseases (two genes jointly causing one condition) are much harder than single-gene cases
- •Eval rows can be sourced from papers/supplementary tables (proband gene pairs + variants)
- •Hard cases expose limitations in baseline agentic setups
- •This forms the “ceiling” that guides R&D and harness engineering priorities
- 39:52 – 47:00
Sampling and nondeterminism: when multiple runs change eval outcomes
Aakash asks whether you should run the same model multiple times due to nondeterminism. Daniel explains sampling’s historical importance (e.g., “shots” and multiple attempts) and how it can affect outcomes if the right answer exists but isn’t the most probable. In their hard-genomics test, sampling is usually less impactful—but they observe an example where a stronger model succeeds by effectively searching and grounding in the literature.
- •Sampling = running multiple rollouts to capture variance in model outputs
- •Historically used to boost benchmark results (shots/examples/attempts)
- •Often less impactful today, but should be tested per use case
- •Observed: a stronger model can succeed by searching for the exact paper and extracting the digenic pair
- 47:00 – 49:39
Putting it together: the real secret is domain expertise (and when PMs should use evals)
They conclude that evals are fundamentally prompts, responses, and scoring—tools help, but subject-matter expertise dominates quality. Daniel advises PMs to start eval thinking on day zero of an AI feature and to seek experienced guidance because it’s deceptively nuanced. The Pinterest image-generation example illustrates translating vague goals (“beautiful kitchens”) into example-based, scoreable definitions.
- •Evals aren’t a template; they’re a domain-specific dataset + scoring system
- •PMs should define success via evals from the start of building an AI feature
- •Find experienced help—eval design has “taste” and nuance
- •Translate fuzzy user desires into concrete examples and measurable scoring
- 49:39 – 56:56
Career + culture: Product management at Meta vs Google, and building a startup
The conversation shifts to Daniel’s experience across Google (Gemini-era context) and Meta (Llama), contrasting engineering-led vs product-led cultures and the impact of founder-led decision-making. Daniel then introduces Gamoff Labs: using AI to scale whole-genome sequencing interpretation in NICUs globally. The episode closes with a call to build the future—inside big companies or by starting from scratch.
- •Meta described as more aggressive and founder-driven; Google more consensus/engineering-led (as of his experience)
- •Evaluation rigor even impacts major launches (he references Llama 4 eval controversies)
- •Gamoff Labs mission: expand NICU access by automating/augmenting genome interpretation
- •Closing thought: big tech must reinvent; startups can build the future end-to-end
