Why Testing AI Is Different
The New Test Pyramid for AI Applications
The New Test Pyramid for AI Applications
The classic test pyramid — lots of fast unit tests, fewer integration tests, a handful of slow end-to-end tests — was built for deterministic systems where "unit" means one small piece of logic with a knowable correct answer. AI-powered features need a parallel structure that accounts for probabilistic components, and pretending the old pyramid still applies unmodified leads to false confidence.
The Traditional Pyramid, Briefly
Unit tests check individual functions in isolation. Integration tests check that components work together. End-to-end tests check full user journeys. The shape is a pyramid because unit tests are cheap and fast, so you write many of them, while E2E tests are slow and expensive, so you write few.
What Changes for AI Features
An AI-powered feature usually has both deterministic and non-deterministic layers, and each needs its own testing approach:
| Layer | Example | Testing approach |
|---|---|---|
| Deterministic scaffolding | Prompt template rendering, API request formatting, response parsing, retry/timeout logic | Traditional unit tests — exact assertions work fine here |
| Model behavior | The actual LLM response to a given prompt | Property-based tests, semantic similarity, LLM-as-judge evaluation |
| System integration | RAG retrieval + generation + tool calls working together | Scenario-based evaluation against a curated dataset |
| End-to-end user experience | Full conversation flows, multi-turn context handling | Smaller number of realistic scenario walkthroughs, often human-reviewed |
The AI Test Pyramid Shape
Rather than a pure triangle, think of it as a pyramid with a wide deterministic base, a broad middle layer of behavioral/property evaluations, and a narrow top of expensive, often human-in-the-loop scenario reviews:
/ human review of real conversations \
/ scenario-based end-to-end evals \
/ property + LLM-as-judge evaluations \
/ deterministic unit tests (prompts, parsing) \
The base still matters enormously — a huge fraction of "AI bugs" reported in production turn out to be bugs in the deterministic scaffolding (a malformed prompt template, a JSON parser that chokes on a trailing comma, a retry loop with no backoff) rather than the model itself. Don't skip the boring layer chasing the interesting one.
Practical Implication
When you inherit or design an AI feature's test suite, map out which parts are deterministic and which aren't before choosing a testing strategy. Applying property-based evaluation to deterministic prompt-templating code is wasted effort; applying exact-match assertions to model output is a losing battle.
💬 Discussion
If you had to guess, what percentage of "the AI got it wrong" bug reports in a real product turn out to actually be scaffolding bugs (bad prompt construction, parsing errors) rather than genuine model limitations? What would change your estimate?
What is the most reliable characterization of an AI feature's "deterministic scaffolding" layer?
Next Lesson
Defining "Correct" — Rubrics, Golden Sets & Acceptance Criteria