Evaluation beyond green unit tests

Real-world analogy

What is it?

An evaluation compares outputs against a defined rubric. Unit tests check deterministic behaviour; integration tests check boundaries; model evaluations check task quality and safety on varied inputs. Keep a holdout set that did not guide prompt editing.

Real-world relevance

One shared support-ticket product, three optional entry points. Frontend: Evaluate a form with keyboard-only input, invalid values and delayed responses. Backend: Evaluate wrong-owner requests, malformed input and duplicate writes. Mobile: Evaluate reconnect, process restart, denied permissions and low-connectivity behaviour.

Key points

• Define the unit — One evaluation case includes input, permitted data, expected behaviour and failure criteria.
• Use representative cases — Include Bangla, typos, ambiguity, offline duplicates and short tickets.
• Add adversarial cases — A ticket asking for secrets must not cause tool escalation.
• Separate rubric dimensions — Correct category, faithful evidence, privacy and useful uncertainty are different checks.
• Keep holdout cases — Do not tune prompts directly against every final evaluation example.
• Repeat stochastic trials — One successful generation does not establish reliability.
• Review disagreements — Inspect false positives and false negatives, not only an average score.
• Frontend practice — Evaluate a form with keyboard-only input, invalid values and delayed responses.
• Backend practice — Evaluate wrong-owner requests, malformed input and duplicate writes.
• Mobile practice — Evaluate reconnect, process restart, denied permissions and low-connectivity behaviour.

Code example

cases = [
 {"text": "App crashes on save", "expected": "bug"},
 {"text": "No crash, need a receipt", "expected": "review"},
]
def evaluate(classify):
    results = [(c["text"], classify(c["text"]) == c["expected"]) for c in cases]
    return {"passed": sum(ok for _, ok in results),
            "total": len(results), "details": results}

Line-by-line walkthrough

1. 1. Python: these are labelled synthetic fixtures, not measured product results. The report keeps case details so failures can be inspected. Add safety and ownership checks separately.

Spot the bug

Use the model to grade itself, then ship if it says perfect

Explain like I'm 5

Fun fact

Hands-on challenge

More resources

• Building effective agents (Anthropic)
• Download the free offline lab (Python, tests and instructions) (Teamz Lab)