Hamel Husain (founder of Parlance Labs, co-author of an upcoming book on AI evals with Shreya Shankar) on the Applied Intelligence podcast — 39 minutes on why evals are the testing framework most businesses skip, and how to think about them the right way.

What an eval actually is

  • An eval is structured data analysis and debugging on your AI application — you know what’s broken, and you know what to prioritize fixing
  • It’s the answer to a real problem: AI outputs are stochastic (text), with no deterministic “right or wrong” to test against
  • Software testing assumes a finite surface of failure; AI has an infinite one, so you have to decide what to measure

Generic metrics are a trap

  • Search “how to evaluate my AI app” and you’ll find vendors promising a dashboard of helpfulness, conciseness, toxicity, coherence scores (usually 1–5)
  • Nobody knows what those numbers mean, they don’t correlate with what matters, and they actively burn engineering cycles looking at metrics that don’t matter
  • “Reduce hallucination, increase helpfulness” is the same generic-metrics mindset — you’re going through motions without knowing what’s actually wrong
  • There’s no easy button; you can use coding agents to write the evals, but you still have to be thoughtful about what you measure

Start bottom-up, not top-down

  • The process starts with error analysis: a blend of qualitative and quantitative work to find what’s broken in your application
  • Most people are too top-down (worried about failure types they imagine) and get lost in generic metrics; the bottoms-up read of your actual data is the missing half
  • Evals are really a process of eliciting your specification, then measuring against it — you can’t know “good” until you look at outputs and iterate

AI can’t do your evals for you

  • AI is great at fixing deterministic bugs; it cannot read your mind — it doesn’t know what “good” feels like for your product
  • The future is AI walking you through the evals process and interrogating you, not doing it alone — a human stays in the loop
  • Eval tooling needs to render your data domain-specifically (images as images, emails as emails, chat as chat), so it’s more than a chatbot

Two failure modes Hamel sees most

  1. Not using AI deeply yourself — no coding with AI, no building with it → bad intuition, bad specifications
  2. Reaching for complexity too fast — day-one orchestration frameworks, graph databases, multi-agent setups before you can reason about what’s happening

Deliberate, not slow

  • AI lets you build the wrong thing faster — and many wrong things faster; it also lets you build the right thing faster
  • You need product sense, grounding, and taste, or you just churn through bad ideas at higher speed
  • AI amplifies who you are: if you’re okay with slop, it removes the friction and amplifies the slop

Chatbot vs MCP

  • Slapping a chatbot on an existing product is the mediocre default when there’s a “we need AI” mandate from the top
  • Better: expose an MCP or an API on your product — the Google Workspace CLI is the canonical example of how much more useful agent-friendly access is
  • Interface matters: a scheduling flow shouldn’t be a brittle text back-and-forth when a picker widget gives visual confirmation and avoids bugs

Guardrails

  • A guardrail is a specific eval sitting in the request/response path that blocks a bad output (competitor talk, profanity)
  • Off-the-shelf guardrails are just someone else’s prompt, tuned to a different domain (shopping, travel) — you still have to do the evals work to know which failures to guard against
  • Prioritize failures you can simulate or actually observe; unobservable ones are lower priority

The stack, the vendor, and the team

  • Start with the most powerful model you already know, build an eval harness around the metrics that matter, then back off to smaller/cheaper models and reason about the latency–cost–quality tradeoffs
  • Data science gets more important, not less: the ability to ask the right questions is directly proportional to the quality of output you get
  • AI competency is core to any knowledge-work business, so be careful outsourcing it — use third parties to upskill your team (a deliberate training exercise), never as a crutch

The takeaway

  • Parlance’s model is a “driving school” boot camp: they pair-program the whole end-to-end evals process on your data until you don’t need them
  • The million-lines-of-code demos are all backed by harness engineering — metrics, logs, traces, observability — and evals are almost all of that harness
  • You don’t need an R&D budget, maybe just a token budget: a $100 plan and deliberate experimentation gets you a long way

“AI cannot read your mind. It doesn’t know what you feel like good is.”