Why evaluate at all
The reason hasn't changed: ordinary tests tell you whether software ran, not whether what an AI produced was any good. An evaluation should help you answer four questions, and I'd still put them exactly as I did in 2025:
- Did that change help or hurt? (a model swap, a prompt tweak, a change to the inputs)
- Is it safe to ship?
- Where is quality uneven? (across user groups, scenarios or input types)
- What are the weak points? (systematic failure modes, brittle edge cases)
What I'd add in 2026 is a fifth: what is this costing us? Quality and cost are the two things an AI product has to be able to see, and in Launchling I lost sight of both at once.
1. Get one case working end to end first
Before anything else, I'd want to be able to take one fixed input, generate or load its output, evaluate it against one rubric, write the result to a local file and exit cleanly. No database, no batch runner, no dashboard. Everything else (batches, persistence, reporting, regression alerts) is added only once that works and keeps working. In 2025 I built the platform before proving one case end to end, and spent days repairing the machinery instead of evaluating anything.
2. Look at the outputs before you write the rubric
Read a few dozen real outputs, note every way they disappoint, group those notes into failure modes, and write checks for the failure modes you actually find. Criteria you invent in advance tend to measure what you expected to go wrong rather than what does. This approach owes a lot to Hamel Husain's writing on evals and to Shreya Shankar and colleagues' research on validating LLM-based evaluators ("Who Validates the Validators?", 2024), which also shows that your criteria will shift as you read more outputs; I think that's a feature, as long as you version the rubric when it happens.
3. Prefer specific pass/fail checks to scores
"Does the plan recommend a tool the user said they can't afford?" is easier to judge consistently, and easier to act on, than "personalisation: 3.8/5". I'd keep a single overall score only where it's genuinely useful for spotting trends, and I'd stop using statistical refinements like z-scores until the basics are stable.
4. Calibrate the judge before you trust it
Using an LLM to evaluate an LLM is usually the most practical way to evaluate at breadth; however, the judge is a model too, and it needs evaluating. Label a small set of outputs yourself (or with someone who knows the domain), measure how often the judge agrees with you, and only rely on it for the checks where it does. Use a judge from a different model family to the generator where you can, because a model marking its own family's homework tends to be generous. Re-check agreement whenever you change the judge's prompt or model.
5. Version everything that could change a result
Unchanged from 2025, and still the part I'd defend hardest: model version, prompt version, input version (question set, wording, schema, third-party data) and rubric version, all recorded against every result, so that a score can be traced to exactly what produced it. A score without that context can't be reproduced or compared.
6. Enforce contracts at the boundaries, in code
v1 called for "strict schemas"; Launchling taught me that writing the schema down isn't the same as enforcing it. Define inputs, outputs and evaluation records once, in one place, validate them at every boundary, and make the pipeline fail loudly when something doesn't match. Use stable internal codes that don't change when the wording a user sees does. When different parts of a system each hold their own idea of what a record looks like, they drift apart quietly.
7. Track cost alongside quality, from the first call
Record model, input and output tokens and purpose for every call, at a single shared client layer, as an individual record rather than a running total. Make sure a usage record survives if something later in the pipeline fails, because otherwise the runs that went wrong are exactly the ones whose cost disappears. Reconcile what you've recorded against the provider's actual bill now and then. I spent days in 2025 failing to get Launchling's token usage to save reliably, and never did; I'd now treat cost visibility as a precondition for running evaluations at scale, not a nice-to-have.
8. Build synthetic data for coverage, and keep it separate
Also largely unchanged: make sure every meaningful input value (and the important combinations) appears somewhere; write personas that reflect the people you're building for, to test whether output is genuinely tailored to them; build edge-case suites (absurd-but-coherent, adversarial, ethically charged, malformed) to keep guardrails honest; and keep synthetic results apart from real ones so you never accidentally average them together.
9. Evaluate the steps, not just the answer
Much of what I build now is multi-step: agents that plan, call tools and hand work to each other. A good final answer can hide a bad route to it (an unnecessary tool call, a skipped check, a cost that ballooned), so I'd evaluate the steps an agent took as well as what it produced.
10. Report infrastructure confidence and quality confidence separately
A passing test that a mocked API response parses correctly says nothing about whether the advice was good. By the end of Launchling I was measuring progress in passing tests rather than in the quality of the product's output; I'd now report the two as separate kinds of confidence so that one can't stand in for the other.
11. Buy the plumbing, build the judgement
In 2025 I built my own logging, orchestration and reporting, with Airtable for storage. There are now off-the-shelf tools for tracing and evaluating AI applications, and I'd use them, spending my own effort on the parts no tool can supply: deciding what good looks like for these users, and checking whether the evaluator agrees.
12. Know what each check can't see, and how it fails
Every check has blind spots, and every check fails in one of two directions: closed, where it blocks everything and the product goes stale, or open, where it quietly reports that all is well. I'd decide deliberately which way each check should fail, never let a single check become a single point of failure, and ask every evaluator (human or AI) to say what it couldn't assess. Fold's review panel is built around this idea.
Caveats I'd still give
Metric gaming, selection bias, drift and overfitting to your own test set are all still real. Model outputs vary between runs, so record temperature and seeds where you can and don't over-read small differences. Synthetic data tells you about the cases you thought of; real use will always find others.
If you evaluate AI output differently, or think I've got something wrong here, I'd like to hear about it. Get in touch.