In this conversation, Robert Ta and Hamel Husain discuss how AI product teams can evaluate the cost‑benefit trade‑offs of different evaluation methods. They start with an analogy that software development is like building a house, where ongoing maintenance (the "tax") must be budgeted. They distinguish cheap, code‑based evals such as unit tests from expensive LLM‑as‑judge evaluations that require human‑label validation. The benefit of an eval is tied to problem difficulty and the expected amount of iterative "hill‑climbing"—optimizing a metric toward a goal. They argue that, despite seeming unintuitive, inspecting individual data traces can provide high‑value insight, especially when the data is sampled strategically. To aid this, they reference an open‑source "Error Discovery" skill on GitHub that clusters traces, ensures diversity, and uses existing annotations to prioritize error‑rich examples, enabling more efficient error analysis and model improvement.
Chapters
I've always thought of software development just like developing a house. Like there's a tax for the maintenance, right? So when we think about evals, I sort of have this question, which is how can an AI product team estimate that tax or that maintenance?
Not like a formulaic thing. You kind of have to practice it and you'll get a strong intuition. There's different kinds of evals. There's code-based evals like unit tests, which are practically free. And then there's an LLM as a judge, which is very expensive. You got to validate against human labels and do all this stuff. And that is way more expensive. And so you have to think about what is the benefit of the eval and weigh that against the cost of the eval.
I see.
And the benefit of the eval centers around like how hard the problem
is
and how much you think you're going to need to iterate. And therefore, like, how much are you going to be using this eval? To hill climb.
I see. Okay. Say more about hill climbing. I think we went off before you—
Yeah. Hill climb just means optimize a metric or conquer a goal. Like you have, you set a goal for yourself, you set a metric and you just want to hill climb. Just means you move towards that goal.
I see. Okay. Yeah. That really adds up with the latest Anthropic article about evals and hill climbing. Okay, cool. Thanks for answering those. Forcing your PMs to look at traces instead of reporting. coherent score. And we see here a young man prying open—
Yeah, that's Nikita Beer, the former, like, I think head of product of X. Yeah, look, like, it's not intuitive that you need to look at your data. Okay.
What? Wait, say more about that. Why is it not intuitive?
Because it feels like a manual task. It feels like you're going to go to a beach, you're going to pick up one grain of sand at a time, you're going to look at it. And you must, you feel That this doesn't seem like a good idea because how can looking at one piece of data move you towards your goal? And the answer is it absolutely does. You know, there's a lot in, there's a lot of alpha in your data. You're not just looking through it randomly, you know, like you can sample your data in ways to maximize the chance.
How does an AI builder sample their data in ways to maximize chance value of their error analysis activity.
Yeah, we have a skill called the Error Discovery skill on GitHub. You can Google Hamil Error Discovery.
Or drop the comment Hamil in whatever you're seeing this, we'll DM it to you.
There you go. And that will help you, that will help your agent like sample the data. You know, it does some clustering, it tries to get diverse sort of traces, And also looks at what you're annotating and like looks, look, gets clues from that on what else might be interesting. Um, or if you haven't annotated enough of that particular error, it'll get more things like that error. It'll make judgment calls. It'll try to do a little bit of, you know, it's like
prioritization work.
Yeah, prioritization and searching for you. It's not perfect, just like anything else, but you know, it's one way to try to, try to have a more fruitful search through your data.