← All speakers

Bio, Work & Ideas

Hamel Husain

Conference affiliation: Parlance Labs · 2025

Hamel Husain is the founder of Parlance Labs, an independent machine-learning consultant, and a leading practitioner of domain-specific AI evaluation. He helps companies replace intuition about whether language-model applications work with disciplined analysis of actual failures, user needs, and expert judgment.

From enterprise analytics to practical AI

From 2011 to 2015, Husain was vice president of applied analytics at AlixPartners. He subsequently worked at DataRobot, Airbnb, and GitHub, progressing from automated machine learning and data science into developer-facing machine-learning infrastructure.

As a staff machine-learning engineer at GitHub, he led CodeSearchNet, an open-source initiative combining code datasets, baseline models, human relevance judgments, and a public challenge for evaluating semantic code search. His introduction to the project established a concern that still shapes his work: models improve faster when teams can measure outcomes against informed human expectations.

Husain also led fastpages, which made Jupyter notebooks easier to publish as blog posts, and later worked with fast.ai as an entrepreneur in residence. Through Parlance Labs, he now advises organizations building AI products and teaches practical AI evaluation with Shreya Shankar.

  • Start with failures users actually encounter. Working with Rechat on its real-estate assistant, Lucy, Husain helped turn observed mistakes into inexpensive assertions and unit tests, run evaluations through existing continuous-integration workflows, and track results in Metabase. Synthetic prompts representing real-estate agents expanded test coverage. Lucy was Rechat’s product; Husain participated as an outside consultant. His account of the evaluation system emphasizes adapting tools to an established process.
  • Make human review easy enough to happen. Husain advocates application-specific interfaces that place traces, relevant context, and labeling controls together so domain experts can inspect outputs without navigating disconnected dashboards. That review identifies concrete failure categories and creates useful data for subsequent model improvement.
  • Calibrate automated judges against domain experts. Before trusting an LLM-generated assessment, he recommends collecting human-labeled examples, defining explicit criteria, and checking whether the automated evaluator agrees with knowledgeable reviewers. Straightforward assertions should come first; model-based judging becomes useful when product requirements cannot be captured by simple tests.
  • Treat evaluation and data literacy as core engineering skills. Husain argues that teams should first hire people who can build applications, add data and platform capabilities as usage grows, and bring in specialized machine-learning expertise when meaningful production data exists. In his identifiable portion of a six-person AI engineering keynote, he challenges vague job descriptions that expect one engineer to master every stage simultaneously.

He also warns against organizational habits that exclude domain specialists: unnecessary technical jargon, inaccessible data, expensive infrastructure purchased before the problem is understood, and metrics disconnected from customer outcomes. His AI-strategy satire with Greg Ceccarelli frames these failures as management problems with technical consequences.

Read the topics behind these talks

3 conference talks

Key ideas

Scroll to read ↓

AI projects become expensive failures when strategy, language, staffing, and evaluation separate the technology from the people who understand the work.

  • What would guarantee an AI strategy fails?
    0:18 ↗
  • Divide the company, then disconnect spending from value
    2:19 ↗
  • Replace strategy with declarations and a permanent backlog
    5:00 ↗
  • Use technical language to exclude the people who know the work
    7:31 ↗
  • Mobilize the wrong expertise and ship before testing
    8:59 ↗
  • Treat every failure as a purchasing decision
    10:28 ↗
  • Collect enough metrics to find a success story
    12:02 ↗
  • Avoid the data, then make sure nobody else can inspect it
    13:35 ↗
  • The advice is inverted; the experience is real
    15:55 ↗

Key ideas

Scroll to read ↓

Rechat’s real estate assistant shows how assertions, trace review and curated examples turn an impressive prototype into a system whose improvements can be measured.

  • An impressive demo with unknown reliability
    0:36 ↗
  • Turn iteration into a measurement loop
    3:01 ↗
  • Start with failures that ordinary tests can catch
    4:14 ↗
  • Make traces easy to inspect and label
    6:33 ↗
  • Bootstrap coverage before users arrive
    8:47 ↗
  • Test the evaluation workflow itself
    9:38 ↗
  • Use evaluation to curate fine-tuning data
    10:37 ↗
  • Calibrate model judges against domain experts
    11:55 ↗
  • Keep the process specific to the application
    13:00 ↗
  • The behaviors prompting alone did not deliver
    15:15 ↗
  • From listing search to a coordinated marketing workflow
    16:52 ↗

Key ideas

Scroll to read ↓

Useful LLM products depend on domain expertise, deliberate hiring, and a feedback loop that turns real user interactions into evaluations, better decisions, and production guardrails.

  • Six practitioners encounter the same problems
    0:24 ↗
  • Build a product advantage that survives better models
    3:23 ↗
  • Evaluation belongs inside an improvement loop
    6:06 ↗
  • Get real interactions into the loop
    10:01 ↗
  • Prototype for economics that may become possible
    11:57 ↗
  • Buying another shovel does not tell you where to dig
    14:52 ↗
  • Premature model ownership creates the wrong work
    16:23 ↗
  • Evaluation is a core engineering skill
    18:24 ↗
  • Hire for the next stage of the product
    21:00 ↗
  • Turn broad quality goals into testable criteria
    23:54 ↗
  • Choose an evaluator you can align and maintain
    25:41 ↗
  • Inspect recognizable failures with their execution context
    28:34 ↗
  • Turn reference-free evaluations into guardrails
    30:43 ↗
  • The surrounding system still needs maintenance
    32:32 ↗
  • A compelling demo can precede a product by decades
    34:17 ↗

References