AI evals has become one of 2026's hottest practitioner skills — a course taught by Hamel Husain and Shreya Shankar reportedly trained 2,000+ engineers and PMs, including teams at OpenAI and Anthropic. Here's what an eval suite actually is, the single biggest mistake most teams make when starting one, and the scoring approach practitioners actually recommend.
TL;DR
| Question | Answer |
|---|---|
| What are AI evals? | The systematic testing layer for an AI product — golden datasets, scoring methods, and repeatable checks |
| Biggest first mistake | Picking a tool before hand-writing real test cases — the dataset is ~90% of the problem |
| Recommended scoring mix | ~60% deterministic checks, ~30% LLM-as-judge, ~10% human review |
| Never do this | Rely on LLM-as-judge alone — it stacks judge inconsistency on top of the system's own |
| Common tooling | Promptfoo (CI checks) + a lightweight custom dashboard for online evals; Braintrust for PM-friendly review |
| Who's driving this trend | Hamel Husain and Shreya Shankar's widely-cited course and eval-focused writing |
Why evals became the trending skill of 2026
The underlying problem evals solve is simple to state and genuinely hard to live without a system for: as more teams shipped real AI-powered features into production throughout 2026, they discovered a specific, recurring failure — an AI feature that seemed to work fine in initial testing would quietly regress after a prompt change, a model upgrade, or a new edge case in real user traffic, with no systematic way to catch the regression before users did. Evals are the direct answer to that problem: a structured, repeatable way to measure whether an AI system's output is actually correct and useful, run automatically as the system changes, rather than relying on a developer's spot-check impression of quality.
The biggest mistake: tooling before data
The single most commonly repeated piece of practitioner advice, cited directly from Hamel Husain's widely-read eval FAQ, is worth leading with because it cuts against most teams' first instinct: the golden dataset matters far more than which eval framework or tool you pick. A hand-curated set of even 20 real, representative test cases — actual examples of inputs and the correct or acceptable outputs for them — is described as roughly 90% of the actual eval problem, with tooling choice accounting for the remaining 10%. Most teams do this backwards: they research and adopt an eval framework first, then struggle to populate it with meaningful test cases, when the harder and more valuable work is writing real, specific test cases from actual product usage before worrying about which tool runs them.
The recommended scoring mix: 60/30/10
Once a real golden dataset exists, the next question is how to actually score outputs against it. Current practitioner consensus lands on roughly a 60% deterministic, 30% LLM-as-judge, 10% human-review mix, rather than leaning entirely on any single method. Deterministic checks — does the output match an expected format, contain a required field, pass a simple rule-based correctness test — are cheap, fast, and completely reliable wherever the correct answer can actually be checked mechanically. LLM-as-judge — using a separate model to score output against a rubric — fills the gap for outputs where correctness is more subjective or harder to check with a simple rule, but comes with a real caution worth internalizing: never rely on LLM-as-judge alone, since doing so stacks the judge model's own inconsistency on top of whatever inconsistency the system being evaluated already has, compounding rather than resolving the underlying uncertainty. Human review, kept to a smaller but non-zero share, catches what both automated methods miss and periodically validates that the LLM-as-judge scoring itself is still tracking real quality.
What tools people actually use
On the practical tooling side, a commonly recommended default combines Promptfoo, run inside CI for pre-deployment checks, with a lightweight custom dashboard — often just a simple Postgres-backed tool — for tracking online evals on real, in-production traffic. Braintrust is a popular pick specifically for teams where non-engineering product managers need to run and review eval experiments themselves without needing to open a pull request or involve an engineer for every check. LangSmith tends to make the most sense specifically for teams already committed to the LangChain ecosystem, since the framework lock-in makes later migration costly — it's a reasonable default within that ecosystem, not necessarily the best starting point for a team building without LangChain already in place.
Who's teaching this, and why the course itself is notable
Hamel Husain, an ML engineer with 25+ years of experience and prior work at Airbnb and GitHub (including early LLM research that reportedly informed OpenAI's own code-understanding work), and Shreya Shankar, a UC Berkeley CS PhD joining Carnegie Mellon as an Assistant Professor in 2027, teach what's described as one of the most popular current courses specifically on AI evals — reportedly having trained over 2,000 engineers and product managers, including teams from OpenAI and Anthropic themselves. The two are also co-authoring an O'Reilly book on the topic. Their core thesis, worth taking seriously as a framing for the whole discipline: evals are specifically the skill that separates teams shipping AI products that hold up in production from teams shipping "on vibes" — a distinction that's become increasingly visible as more companies discover the gap the hard way, in production, after a regression nobody caught.
Why PMs specifically need this skill, not just engineers
It's worth being direct about why this trend explicitly includes product managers, not just engineers — a detail baked directly into the course's own name. Engineers building eval infrastructure can measure whether a system's output is technically correct, but deciding what "correct" and "good enough to ship" actually mean for a specific product and audience is fundamentally a product judgment call, not a purely technical one. A PM who can read and reason about an eval suite's results, weigh in on what the golden dataset's test cases should actually cover, and understand where the 60/30/10 scoring mix is likely to miss something is making a genuinely different, complementary contribution than an engineer building the eval pipeline itself. That's the real argument for evals being a shared skill across both roles rather than a purely engineering concern handed off and forgotten about once the infrastructure exists — the most useful eval suites tend to result from product and engineering collaborating on what to test, not engineering building tests in isolation and reporting results back to product afterward.
Evals as an ongoing practice, not a one-time setup
The last detail worth emphasizing is that a genuinely useful eval suite isn't a project you complete once and then leave alone — it's a living practice that needs to evolve alongside the product it's testing. New edge cases surface in real production usage that the original golden dataset didn't anticipate, and a well-run eval practice folds those back into the dataset as they're discovered, rather than treating the initial 20 test cases as a permanently fixed benchmark. That's part of why the golden-dataset-first advice matters as much as it does: a dataset built once and never revisited gradually drifts out of sync with how the product actually gets used, quietly losing its usefulness as a real signal of quality even while the eval scores themselves look stable. Treating eval maintenance as an ongoing, shared responsibility — not a one-time infrastructure project — is what keeps the whole practice actually useful over time rather than becoming theater that looks rigorous without catching real regressions.
Honest limitations
- Tooling recommendations in this space change fast — Promptfoo, for instance, has reportedly shifted toward a more security/red-team focus following a March 2026 acquisition into OpenAI's own infrastructure, which may affect whether it remains the right pick for general-purpose eval CI checks going forward.
- The 60/30/10 scoring mix is a widely-cited practitioner heuristic, not a formally standardized industry rule — the right mix varies by specific product and how checkable its correctness actually is.
- This post describes eval practice for LLM-based products generally, not a specific vendor's exact methodology — adapt the general framework to your own system's specific failure modes.
What this means for builders
If you're shipping any AI-powered feature into production and don't yet have a systematic eval process, the practical first step isn't researching frameworks — it's sitting down and hand-writing 15-20 real test cases from actual product usage, including a few genuinely hard or ambiguous ones, before evaluating a single tool. That dataset is the foundation everything else builds on, and it's the specific piece of work most teams skip in their rush to adopt a framework. Once you have it, layering in deterministic checks first (cheapest, most reliable), then LLM-as-judge for the harder-to-check cases, then a smaller slice of ongoing human review, gives you a genuinely useful, practitioner-validated eval process rather than a tool adopted without the substance underneath it.
Worth being precise about what evals do and don't cover, too: a golden-dataset eval suite checks output quality on a fixed set of test cases, run before or alongside deployment — it doesn't watch what an agent actually does across a live session once it's running with real tool access and real credentials. That's a different, complementary layer explainx.ai's own AgentBeam is built for: open-source, self-hostable runtime monitoring that flags out-of-bounds agent trajectories in production, the same job a human reviewer does in the 10% human-review slice above, just running continuously rather than sampled.
Related on explainx.ai
- What is an embedded evaluator? AI safety, explained
- How to read AI benchmarks and not get fooled
- Is Jev's 200x-faster, 400x-cheaper claim actually true?
- What is harness engineering? Complete guide
- Top generative AI workshops for software developers
- AgentBeam — open-source runtime monitoring for what your agents actually do in production
- Sources: Hamel Husain's eval FAQ · Lenny's Newsletter interview · DEV Community practitioner field guide
This post synthesizes publicly available practitioner writing and course materials on AI evals as of September 19, 2026. Specific tool recommendations and market positioning may shift; verify current tooling status before making an infrastructure decision.