Pick the eval before you pick the model

Teams evaluating LLM features usually start by asking which model is best. That is the wrong first question, because it has no answer without the second one: best at what, measured how.

Build the eval before the feature

The cheapest useful thing you can do is write twenty real inputs and the outputs you would accept. Not synthetic examples — real ones, from the actual use case, including the awkward ones people actually send.

That set does three jobs at once. It tells you whether the feature is viable at all, it makes model comparison a measurement rather than a vibe, and it becomes the regression test for every prompt change afterwards.

What to measure

For most product features, three things matter more than benchmark scores:

• Does it refuse when it should? A confident answer to a question outside its knowledge is the expensive failure.
• Is the format stable? If downstream code parses the output, an occasional stray sentence is an outage.
• What does the tail look like? Average quality is set by your worst cases, because those are the ones people screenshot.

The trap

It is tempting to grade with another model and call it done. That works for coarse signals and hides exactly the failure modes you care about, because the grader shares the generator's blind spots. Read the outputs yourself for the first hundred. It is boring, and it is where the real defects are.