Hamel Husain makes the case that “are you building the right thing?” matters more than evals: if users can’t verify an AI answer, your product creates work instead of saving it. Three worked examples and four design principles. ~17 minutes on his own channel.

The core problem: verification is the bottleneck

  • Classic AI product: user asks “what was revenue for product A last quarter?”, AI queries a database and returns “$4.21M” — but the user can’t validate the number without redoing all the work
  • Lenny’s tweet: data science teams now spend their time reviewing half-assed AI analysis from PMs and data engineers — 50% of the time it’s wrong
  • Creating output is now easy; verification is the bottleneck — design products with that in mind
  • If a product seems impossible to eval, that’s a product smell: your users have to check it too

Example 1: business Q&A → evidence-backed analysis

  • Instead of a bare answer, show supporting information: base the analysis on already-vetted analysis (notebooks others signed off on)
  • State the assumptions — confirm the metric definition (from a semantic layer, linkable to the governed definition)
  • Show intermediate calculations (returns, customer counts) and raise issues the user might care about
  • “Open as notebook” UI idea: an AI-generated notebook (Jupyter/Marimo style) with narrative + queries — step through it, edit it, ask AI questions about it, and have the AI state what it couldn’t verify
  • Put yourself in the expert’s shoes: a data scientist checks prior analyses, definitions, and intermediate calcs — give users those same affordances
  • Real product doing this today: Hex — a chat interface that flows into a notebook; progressive disclosure is an established pattern we forgot in AI apps

Example 2: PE lesson plan assistant (K-12)

  • Vanilla version: input grade, class length, location, equipment → AI spits out a lesson plan — no way to judge quality
  • Better: anchor the output in existing curriculum — what are trusted colleagues doing? “Here’s a lesson plan exactly like yours, used at 14 schools, run 30 times, by teachers you trust”
  • Show the edits made for your inputs (“shortened to a 45-minute class, matched to your equipment”) — accept or reject each
  • Cold-start problem: seed with expert-vetted plans up front; it makes the app easier to eval and users more confident

Example 3: medical claims report generator

  • The task: read a patient’s chart + claim (thousands of documents) and produce a 52-page report supporting or denying a claim — a doctor can’t eyeball 52 pages
  • Redesign as a research assistant: surface atomic elements first — contradictions (open both pages, resolve), key facts (validate, include, dismiss), open questions (add notes)
  • Do the work the user would normally do and guide them through it; understanding built along the way is arguably more valuable than the final report

Four design principles

  1. Provenance — show where information comes from (prior analyses, source documents, other lesson plans); the more curated/trustworthy, the better
  2. Progressive disclosure — show details at the right time; adapt as your product and users mature
  3. Signals and heuristics — mirror how experts sanity-check: other reports, smell tests, social proof, supporting evidence
  4. Modularity / small steps — break work into small verifiable pieces, show your work along the way, and sometimes force the human in the loop (e.g. doctors step through findings before the final report)

“The goal is to make the human understand, not necessarily to generate a report.”