Mindset Over Metrics: How to Approach AI Engineering | Hamel Husain

Summary

Reliable AI products depend less on choosing an evaluation tool and more on following a disciplined process for finding and fixing real failures.

Build evaluations around real product risks

Generic metrics—such as hallucination, toxicity, or conciseness scores—can create false confidence if they do not reflect how a specific product fails. Instead, identify the application’s likely failure modes and build evaluations around them. Update those evaluations as the product and its use cases change.

Inspect data and analyze errors

Review real traces, categorize failures, and use those categories to decide what to prioritize and which evaluations to build. Hamel suggests reviewing around 100 traces as a practical starting point, then continuing until reviews stop producing new insights—a concept related to theoretical saturation.

This work calls for data literacy: engineers should be able to explore and interpret data, understand sampling and uncertainty, and validate methods such as LLM-as-a-judge against human labels. AI engineering combines software-building skills with analytical and data-science practices; training models is not necessarily its central task.

Make data easy to inspect

Debugging views should show relevant information in a format suited to the application. Depending on the product, that might include external data, rendered widgets, or exactly what the user saw. Custom annotation or data-viewing tools can be worthwhile when they reduce friction, complementing rather than replacing trace viewers and observability platforms.

For complex agent workflows, graph, session, and interaction views can help teams see which parts of an application a request touched, spot anomalies, and investigate the underlying data.

Involve domain experts

Developers may not have the business or subject-matter context needed to judge outputs. Hamel recommends giving domain experts a direct way to experiment with prompts in an environment connected to the actual application.

Basic prompt playgrounds may be insufficient if they cannot access the application’s retrieval, tools, or infrastructure. Supporting this workflow becomes more technically challenging in multi-agent or distributed applications.

Treat development as experimentation

Form hypotheses, try changes, and inspect the results rather than treating AI development as a rigid, predictable sequence.

One speaker describes AI reliability in three layers:

1. Basic monitoring and traceability.
2. Prompts and metrics managed as versioned evaluation assets.
3. Insights that turn qualitative observations into customized quantitative measures.

Guides and learning resources

• Hamel’s Field Guide to Rapidly Improving AI Products, a practical guide to improving AI products.
• An evaluation course taught by Hamel and a collaborator, which Hamel says has had more than 700 students.
• Hamel’s blog and talks, including material on cultivating an experimentation mindset.

Main speakers and sources

• Hamel Husain — Independent AI consultant and guest; discusses evaluation, error analysis, data literacy, and prompt experimentation.
• Conor Bronsdon — Host.
• Galileo co-host — Identified in the subtitles as a co-founder and CTO; the auto-generated name is unclear. Discusses observability, product features, and AI reliability layers.
• Galileo — The company and observability and evaluation platform discussed by the hosts.