Skip to content
EVALUATION · 2026-02-10

Evals first. Then everything else.

Why golden sets, rubrics, and regression suites are the work that should have started on day one - and the cost of postponing them.

Every AI project I have audited that ran into a production-critical incident had the same artifact missing on day one: an evaluation harness.

It is the single most under-built piece of production AI, and it is the cheapest one to add early.

What an eval harness actually is

It is not a benchmark. Benchmarks are for the model vendors. An eval harness is the set of artifacts and code that lets your team answer this question unambiguously, on demand: Did this change make our system better, worse, or the same - for the use cases we actually care about?

Three pieces:

  1. A golden set. Twenty to two hundred representative inputs, hand-curated, labeled with expected behaviors. Hand-curated by domain experts. Not synthetic. Not auto-generated.
  2. A scoring rubric. Either a numeric scale per dimension (helpfulness, safety, correctness, brevity) or a clear pass/fail per criterion. Written down. Versioned.
  3. A runner. Code that takes the current system, feeds it the golden set, scores every output against the rubric, and produces a report you can diff against the previous run.

Evals are not optional. They are the only mechanism by which you can ship AI changes with confidence.

Why teams skip them

Two reasons, both bad:

  • "It is too early to build evals; we are still figuring out the use case." No. The act of writing the golden set is how you figure out the use case.
  • "Evals are tedious to maintain." Yes - and so are tests, and yet you do not ship without tests. Build the maintenance loop in. Add new examples whenever a production incident reveals a gap.

What to do this week

If you do not have an eval harness, the fastest path is:

  1. Pick the three highest-value use cases your AI handles.
  2. For each, write five inputs that should work, three that should fail gracefully, and two that are ambiguous edge cases.
  3. Write a one-line expected behavior next to each.
  4. Build a runner that prints a pass/fail table.
  5. Commit the golden set to your repo.

That is it. You now have evals. The hard work is keeping them current - that is the work that buys you the ability to ship safely.

The lesson

Teams that build evals first ship faster, not slower. The harness is not overhead - it is the only thing that lets you change the system without guessing whether you broke it.

COOKIES & ANALYTICS

Optional analytics and masked session recordings help us improve this site. They load only with your consent. Form content is excluded. See privacy.