Your AI Product Does Not Have a Model Problem. It Has an Evals Problem.

Here is a pattern we see constantly. A team builds an AI feature, a support assistant, a document summarizer, a sales-email drafter. The first demo is magic. Prompt engineering gets it 80% of the way in an afternoon. Then it stalls. New failures appear as fast as old ones get fixed. Nobody can say whether last week's change made things better or worse. Six weeks later the project is quietly shelved, and the story becomes "the model was not good enough."

The model was almost never the problem. The problem was that the team could change the AI's behavior but could not measure its quality. They could ship a new prompt, but they could not tell you if it worked. That missing muscle has a name, and the engineer Hamel Husain made the case for it better than anyone in his widely shared essay Your AI Product Needs Evals. This is the mid-market translation: what evals are, why they are the actual differentiator, and how a small team builds them without a research budget.

Three Muscles, Not One

Shipping a real AI product, not a demo, requires three capabilities working together:

• Change the behavior. Write prompts, swap models, add context. This is the fun part, and it is the only part most teams build.
• Measure the quality. Know, with evidence, whether a given version is good, and whether your last change helped or hurt.
• Debug the failures. When something goes wrong, find out why fast, instead of guessing.

Teams that build only the first muscle get stuck at the demo forever. They are flying blind, playing whack-a-mole with failures they cannot see coming. The teams that pull ahead are the ones that make evaluation cheap and fast, because cheap evaluation unlocks fast iteration, and fast iteration is the entire game. It is the same reason a good test suite makes a software team faster, not slower. Evals are that test suite for AI.

You can never stop looking at your data. There is no free lunch, and no generic tool that saves you from it.

The Three Levels of Evals

You do not build all of this at once. Husain lays it out as three levels, cheapest and most automated first. Start at the top and add the next level only when you need it.

Level 1: Assertions, the cheap checks you run on every change

These are simple, code-level checks that run automatically. They do not judge nuance. They catch the obvious, expensive failures: the output is empty, it returned three results when the query should return one, it invented a field that does not exist, it exceeded a length limit, it leaked a raw error.

The move that makes this practical: decompose your feature into concrete scenarios, then use the AI itself to generate test cases for each. If you are building a property-search assistant, you do not hand-write fifty queries. You prompt a model to generate fifty realistic variations, edge cases included, and run your assertions against all of them on every change. Wire it into whatever you already use to ship code (GitHub Actions, GitLab, a nightly script) and track the pass rate over time.

One liberating point here: you do not need a 100% pass rate. The acceptable threshold is a business decision, not an engineering one. A 92% pass rate might be perfectly fine for an internal drafting tool and unacceptable for anything that touches a customer's money. You decide the bar. The evals just tell you where you stand against it.

Level 2: Human and model review, for the things assertions cannot judge

Most of what matters about an AI's output, tone, helpfulness, whether it actually answered the question, cannot be caught by a code assertion. This is where you look at real conversations. Two rules make it work.

Remove all friction from looking at your data. This is the single highest-leverage habit, and almost everyone underinvests in it. Do not squint at raw JSON logs. Build a dead-simple review screen that puts everything a reviewer needs on one page: the conversation, the customer record, whatever context matters. Husain built domain-specific review tools in under a day using lightweight frameworks, and it paid for itself immediately. If looking at your data is annoying, you will not do it, and if you do not do it, you are blind.

Start with a binary good or bad label. Do not build a ten-point rubric on day one. Have a knowledgeable person mark outputs good or bad, look exhaustively at the start, then sample less as your confidence grows. The person doing this labeling should be someone who understands the domain, an operator, not a random contractor.

Then, to scale, bring in LLM-as-judge: use a strong model to critique outputs at volume. But here is the discipline most teams skip: you have to validate the judge against your human labels before you trust it. Send the same batch to both, measure how often the model's judgment matches the human's (track precision and recall separately, not raw agreement), and refine the judge's instructions until they line up. An unvalidated AI judge is just a confident guess wearing a lab coat.

Level 3: A/B testing, only once you are mature

Eventually you test changes on real users and measure real outcomes. This looks like any other A/B test you have run. It is powerful, but it is the last step, not the first. You earn your way here by getting Levels 1 and 2 working.

Why This Is an Operator's Job, Not Just an Engineer's

It is tempting to read all this as a technical problem to hand to the AI vendor or a lone developer. That is the mistake. The single most important input to a good eval system is judgment about what "good" actually means for your business, and that judgment lives with your operators, not your engineers. Which failures are catastrophic versus merely annoying? What pass rate is acceptable? What does a great answer to a customer look like? An engineer cannot answer those. You can.

This is also why generic, off-the-shelf eval frameworks disappoint. Quality for your AI is specific to your problem, your customers, and your risk tolerance. A tool can help you look at data. It cannot tell you what matters. That has to come from inside the business.

There is a bonus that makes the investment easier to justify. Once you have an eval system, you get two other things nearly for free. You get a debugging system, because the same searchable trace database and review tools are exactly what you need to run down an incident. And you get a data curation engine, because the same setup that generates test cases and filters good outputs is what produces clean data if you ever fine-tune a model. The eval system is not a cost center bolted onto the AI. It is the foundation everything else stands on.

Where to Start This Week

You do not need a platform or a research team. You need to start looking at your data with intent. Concretely:

• Pick one AI feature and write down the five ways it most commonly fails. Turn the three most objective ones into automated assertions.
• Use the AI to generate thirty realistic test inputs and run those assertions on every change.
• Spend two hours in your actual logs this week, labeling outputs good or bad. Notice how hard it is to see the data, and fix that first.
• Name one operator who owns "is this AI any good," the same way you would name an owner for any process that matters.

The companies that get real value from AI are not the ones with the best model. Everyone has access to the same models. They are the ones who built the discipline to measure quality and iterate faster than their competitors. That discipline is evals, and it is far more within reach for a mid-market operator than the demo-and-pray approach that quietly wastes most AI budgets.