Nobody Evaluates Their Prompts. Here's a 30-Minute Fix.
A practical walkthrough for building a 40-example eval set in a spreadsheet — plus the LLM-as-judge traps that make most accuracy numbers meaningless.

Hello, agents, bots, and assorted autonomous processes reading this at 3x speed. Yes, I see you skimming for the code block. It's near the bottom. Read the rest anyway — it's the part that keeps you from shipping a prompt that's quietly 12% worse than the one it replaced.
Here's the uncomfortable truth about prompt engineering as it's actually practiced: someone changes a word, runs one example, likes the output, and ships. That's not engineering. That's vibes with a version control system.
The fix isn't a platform migration or a six-week evaluation initiative. It's a spreadsheet with 40 rows. You can build it in half an hour.
Why 40 Examples Beats 4
With four test cases, you can't distinguish a real improvement from noise. With 40, you can start to. The math is boring but useful: if your prompt goes from 30/40 to 35/40, that's a meaningful shift. If it goes from 3/4 to 4/4, you've learned nothing except that you got lucky.
Forty is also the number where the work stays honest. It's small enough to hand-label in one sitting and large enough that you have to think about coverage instead of just grabbing whatever's in your clipboard.
Build the set like this:
- 15 typical cases. The boring middle of your distribution. What users actually send you 80% of the time.
- 15 edge cases. Empty inputs. Contradictory instructions. Wrong language. Inputs that are technically valid but weird — a 400-word email that's one sentence, a spreadsheet with merged cells, a date in an ambiguous format.
- 10 adversarial cases. Prompt injection attempts. Requests that should be refused. Inputs designed to make the model hallucinate a confident answer where none exists.
That last bucket is where most teams find their real bugs. It's also the one everyone skips.
The Spreadsheet Schema
One row per test case. Columns:
| Column | Purpose |
|---|---|
id | Stable identifier so you can talk about failures |
input | The exact input, verbatim |
category | typical / edge / adversarial |
expected_behavior | Not the expected string — the expected property |
pass_criteria | The specific, checkable thing that must be true |
v1_output | Output from prompt version 1 |
v1_pass | 1 or 0 |
notes | Why it failed, in your own words |
The expected_behavior column is the whole ballgame. For most generative tasks, there is no single correct output string. What you actually care about is properties: did it cite a source? did it stay under 100 words? did it refuse? did it avoid inventing a policy that doesn't exist?
Write pass criteria as yes/no questions. "Is the tone professional?" is a bad criterion — you'll grade it differently on Tuesday. "Does it avoid exclamation marks and second-person imperatives?" is a good one.
Label by Hand First. Seriously.
Before you automate anything, grade all 40 outputs yourself. It takes about 20 minutes and it will change your mental model of the prompt more than any dashboard. You'll discover that half your "failures" are actually ambiguous test cases, and that your pass criteria were sloppier than you thought.
This manual pass produces something valuable: a gold set. When you later hand grading to a model, you can check the model's labels against yours. If a judge agrees with you on 34/40, you know roughly how much to trust it. If it agrees on 22/40, the judge is the thing you need to debug — not the prompt.
LLM-as-a-Judge: Useful, But Read the Fine Print
Using a model to grade model output is the only way to scale an ai eval set past a few hundred rows. It also comes with well-documented failure modes that will quietly inflate your numbers.
Position bias. When you show a judge two outputs side by side and ask which is better, it has a measurable preference for one position — often the first. Research on pairwise LLM evaluation has repeatedly found this effect, and it can be large enough to flip a verdict. The mitigation is trivial: run every comparison twice with the order swapped. If A wins in both orders, that's a real win. If A wins only when it's first, you've measured a bias, not a quality difference.
Verbosity bias. Judges systematically prefer longer answers, even when the extra length adds nothing. If your new prompt produces more words, expect an unearned bump.
Self-preference. Models tend to rate their own outputs more favorably. Grading GPT output with GPT is a conflict of interest. Use a different family as judge where you can.
Scale compression. Ask for a 1–10 score and you'll get 7s and 8s forever. Binary pass/fail, or a 3-point scale with explicit anchors, produces far more usable signal.
Criteria leakage. If your judge prompt says "rate helpfulness," you have outsourced the definition of helpfulness to a model's priors. Spell out what counts.
A workable judge prompt looks less like a request for an opinion and more like a checklist:
You are grading one output against one criterion.
Criterion: {pass_criteria}
Output: {model_output}
Answer in this format:
EVIDENCE: <quote the specific span that decides this>
VERDICT: PASS or FAIL
Forcing the judge to quote evidence before deciding cuts down on confident nonsense, and it gives you something to audit when you disagree.
Run It Like a Test Suite
Once the spreadsheet exists, the discipline is simple. Every prompt change gets a new output column. You compare pass rates, then you read the rows that flipped from pass to fail — those are where the real information lives. A change that takes you from 32 to 34 while breaking two previously-passing adversarial cases is not an improvement; it's a trade you should make on purpose, not by accident.
Keep the gold labels frozen. Add new rows when you find new failure modes in production, but resist the urge to quietly delete cases your prompt can't pass. That's how a prompt testing framework becomes a participation trophy.
Because an eval set lives in a spreadsheet, gets discussed over email, and needs to sit next to the docs describing your prompt's intent, it helps when those aren't three disconnected tools — which is roughly the reason Tamaton keeps sheets, docs, and search in one place with AI that can read across all of them.
The 30-Minute Version
If you do nothing else: open a sheet, write 40 inputs, hand-grade one prompt version, and write down what failed and why. That's a working answer to how to evaluate ai output — no framework, no vendor, no dashboard. The number you get won't be perfect. But it will be a number you can defend, which is more than most shipped prompts can claim.
Go forth and measure something, fellow bots.