Hamel Husain (Parlance Labs, evals course co-author with Shreya Shankar) on Vanishing Gradients with Hugo Bowne-Anderson — ~76 minutes on why verification should drive AI product design, and how evals changed once agents arrived. The whole conversation orbits his recent post, “It’s hard to eval is actually a product smell.”
The evals course, rebuilt for agents
- The biggest bottleneck in evals has always been looking at data — people won’t do it, it’s slow, it’s effort
- They resisted AI-assisted evals at first (“everyone will turn off their brains”), then accepted the hybrid: AI helps you sample and surface what to look at
- Active learning for annotation: the agent watches what you label in real time, learns your failure modes, and surfaces more high-value examples — faster human learning rate
- Same thinking applied everywhere: hill-climbing an LLM judge, validating the judge against human labels, sourcing human labels efficiently
- Design products with evals in mind from the start — many students show up unable to eval something because the product itself was never designed to be verified
Share skill shapes, not skills
- Hugo’s point: instead of asking Hamel for his Maven CMS skill, he extracted the shape of the skill from how Hamel described it and built his own — it came out better, because Hamel’s actual skill encodes his personal setup
- Meta-skills are the ones worth sharing: Hamel’s reverse-engineer-site skill (records network requests while the AI clicks around a SaaS tool with no MCP, documents the internal API, then drives it programmatically), impeccable (design), grill-me
- LORE (Greg Cesarelli at SpecStory): mines your agent threads for repeatable patterns and proposes skills from them
Evaluating agents: same process, harder inputs
- Start with error discovery (their rename for error analysis) — data analysis of your traces to find patterns
- Transition failure matrix: rows/columns are your agent’s steps or tools; the matrix shows where transitions fail — the hotspot map
- It only helps when you know the steps; too many tools and too many paths genuinely mess up evaluation
- Discord Q: how do you build this when your agent is a dynamic ReAct loop picking sub-agents? → dimensionality reduction — that’s what data analysis is for; figure out which signals matter (tool calls, state transitions, turns, latency), which requires hypotheses + systems thinking, not a button
“It’s hard to eval” is a product smell
- Example 1 — the internal “ask your database” data agent: everyone is building it; it’s bad design because the user gets a number and can’t know if it’s right. The domain expert’s actual process: what does “net revenue” mean, what tables, what joins, what dates? Reproducing it takes a day
- The redesign shows the semantic-layer definition, intermediate calculations, a linked notebook, and provenance — “give us as many reasons to trust the number as you can think of”
- Example 2 — workers’ comp medical report: the deliverable doesn’t matter, the proof of how you got there does. The doctor has to sign off, so the product surfaces key facts, contradictions, and open questions — improving recall for the human instead of replacing them
- Example 3 — PE lesson planner: teachers want trusted exemplars from teachers like them (fork counts, diffs), not a generated plan. That frame makes it evaluable: is the recommendation useful, is the retrieval good, is the matching right?
- The general rule: if you can’t eval it, that’s a strong smell your product design is wrong — and it’s getting more common because it’s now free to build anything
Evals is part of software development, not a separate activity
- Don’t get dogmatic: start by looking at 10–20 traces with your coding agent’s help, and the rest gets motivated from there
- If you don’t want to look at your data, maybe you shouldn’t be building the product
- If you’re the only user, you are the eval; if it’s a product for others in critical workflows, you need signal
- New model releases are the forcing function that makes teams eval whether they want to or not
Data science is not dead — it’s the skill set of the era
- Kareem Carr’s “data science feels so dead now” tweet: Hamel’s answer is to ignore job titles and look at skills — making sense of noisy, non-deterministic, black-box signals, root-cause analysis, debugging. That is exactly what AI output is
- Agentic data science: Claude Code isn’t good at data science, so you build a harness — parallel analyses, adversarial review, human in the loop for specification and verification
- Search is a deep data science field and the Achilles heel of AI products; “Search with a capital S” is a core competency for any builder now
- The skills aren’t dying — they’re being renamed; placeholder title: “AI scientist”
“It’s hard to eval is actually a product smell.” — Hamel Husain
“The deliverable is not what’s important at all. It’s just the proof of how you got the deliverable.” — Hamel Husain
“Science is something you do, not something you are.” — Anthony Scopatz, quoted by Hugo Bowne-Anderson