Eval-Driven Development: Tests for AI Behavior

Eval-driven development (EDD) is the practice of treating evaluation suites as the primary executable specification for AI features — writing evals before implementation, iterating prompts, models, and tool policies against the suite, and gating deployments on aggregated pass rates. Vendor and practitioner sources increasingly recommend it as the default workflow for production LLM systems, but the discipline rests on three contested assumptions: that finite eval suites can specify latent behaviors, that automated judges produce stable scores, and that pass rates predict user-facing quality. This article defines the pattern, surveys the eval-type spectrum and tooling ecosystem, catalogs the dominant failure modes, and treats the "new paradigm vs renamed TDD" debate as part of the topic's substance rather than a closing aside.

Coverage note: verified through May 2026.

Definition

Eval-driven development is the practice of making evaluation the load-bearing engineering artifact in an AI system's development loop, in contrast to demo-driven development (ship what looks good in a hand-picked example), ad hoc prompt tweaking (change the system prompt until the latest reported failure goes away), or post-hoc quality assurance (write tests after the feature ships, mostly to prevent specific regressions). The phrase comes from practitioner and vendor sources rather than academic literature. OpenAI's evaluation best-practices guide tells teams to "adopt eval-driven development," use production-shaped task-specific evals, automate scoring, and calibrate automated metrics with human feedback (OpenAI Evaluation Best Practices). Braintrust's reference article frames EDD as: define evaluations first, iterate against them, version-pin datasets, prompts, models, judges, and rubrics, run on every change, and monitor for judge drift (Braintrust).

The term is doing two distinct jobs that are worth separating before going further.

The first job is procedural — a claim about workflow ordering. Write the eval before the implementation, the same way TDD says write the test first. This is a discipline imported from software engineering and intended to force teams to articulate "what would success look like?" before they change the prompt or swap the model.

The second job is methodological — a claim about specification. The eval suite is the primary representation of intended behavior, and the model-plus-prompt is judged correct or incorrect by reference to the suite. This is the more aggressive claim, and it is where most of the contested ground lives.

Useful applications of EDD hold the first claim firmly and the second claim weakly. Evals are the best available executable approximation of the spec for stochastic systems. They are not the spec. The product spec still lives in user research, domain constraints, safety policy, and human judgment. Evals make a slice of that spec auditable. Confusing the slice for the whole is the first failure mode of the discipline, and most of the others descend from it.

The reason this distinction matters is that "primary specification" framing changes the development gradient. If the eval is the spec, every change optimizes the eval, and the dynamics of Goodhart's Law in AI Systems kick in immediately — visible improvement on the suite at the expense of unmeasured behaviors. If the eval is an executable hypothesis about the spec, the team's incentive is to keep checking whether the hypothesis still tracks the underlying behavior, which is a much healthier loop.

The TDD Analogy and Where It Breaks

The cleanest way to understand what EDD inherits from test-driven development and where it has to diverge is to enumerate the structural differences between deterministic software behavior and AI system behavior.

In TDD, the operational logic is simple: a test asserts that for input X, the function returns Y, the database state changes Z, or some invariant holds. The test is close to the specification because the specification is mostly about input-output mappings and invariants. Even here, the empirical evidence on TDD's productivity effects is mixed. A 2014 systematic review by Munir et al. found that high-rigor, high-relevance studies reported external quality gains with productivity costs (Munir et al. 2014). Bissi et al. 2016 found that 76% of included studies reported internal-quality improvement and 88% external-quality improvement, with productivity differing by setting (Bissi et al. 2016). The TDD discipline is real, useful, and not a free lunch.

EDD inherits the workflow ordering — articulate the executable check first — but four properties of LLM systems break the underlying analogy:

Stochasticity. The same input produces different outputs across runs. Single-run examples are not definitive. Anthropic's statistical-evaluation guidance argues for standard errors, clustered errors, paired-difference analysis, resampling, and power analysis as preconditions for treating eval results as evidence (Anthropic Research). A pass rate without a confidence interval is closer to anecdote than measurement.

Latent constructs. "Did the function return the right value" has a clean answer. "Was the assistant helpful, calibrated, and faithful to the source documents" is a latent variable that has to be sampled. Evals approximate latent constructs through rubric items; rubric items are a model of the construct, not the construct itself. This is the same epistemic structure as psychometrics, and it inherits psychometrics' problems — content validity, construct validity, reliability across raters.

Judge dependency. Many evals score outputs with another model — LLM-as-judge. The eval's verdict therefore depends on the judge's own behavior, biases, and version. Zheng et al.'s MT-Bench paper, which introduced LLM-as-judge as a serious evaluation method, reported judge agreement with humans above 80% in their setup, but documented position bias, verbosity bias, self-enhancement bias, and reasoning limitations as systematic effects (MT-Bench / Chatbot Arena). Subsequent work measured position bias across 15 judge models and over 150,000 evaluation instances, confirming the effect is general rather than model-specific (Position Bias in LLM Judges). LLMBar found that even strong LLM evaluators have substantial room for improvement on instruction-following judgments when outputs are deceptively plausible (LLMBar).

Distributional drift. Model providers change underlying weights, sometimes silently. An eval suite calibrated against a model in March may behave differently in May. Pinning model versions is a partial mitigation; rerunning calibration on a cadence is a fuller one. Static suites get stale, which is exactly the warning that public benchmark research has been issuing for years.

The TDD analogy is therefore useful as a workflow heuristic and misleading as a methodological claim. Saying "EDD is TDD for AI" is correct about the loop and wrong about what the loop measures. Saying "EDD is a new paradigm" papers over the genuine continuity in workflow shape. The honest position is that EDD is the TDD workflow with an empirically distinct failure surface — and the failure surface is the substantive part.

The Canonical Workflow

The eval-driven loop, distilled from OpenAI, Braintrust, LangSmith, and Anthropic guidance, has nine stages. The numbering is for clarity; in practice the stages overlap and feed back into each other.

1. Specify behavior in prose. Before any eval, write down what the feature is supposed to do. This sounds trivial and is not. Most production AI failures trace to a behavior the team thought was specified but had never been articulated to a level of precision that could distinguish "doing it correctly" from "doing it almost correctly."

2. Build the dataset. Three sources, mixed by need: curated cases (small, high-signal, often hand-written by domain experts); production traces (real, but sometimes thin until traffic accumulates); synthetic data (cheap to generate, useful for coverage of rare cases, dangerous if the synthesis process is itself biased). Braintrust's eval-feedback-loop writing emphasizes connecting real-world logs to evals because finding good eval data and observing production failures is a recurring practical bottleneck (Braintrust Feedback Loops). LangSmith's documentation describes the same shape — curated cases, historical production traces, synthetic data, offline experiments, online evaluators, and feeding failing production traces back into datasets (LangSmith Evaluation).

3. Define grading. Three modes, often combined: deterministic checks (regex, JSON-schema validity, tool-call match, retrieval recall against ground-truth references); model-based graders (an LLM evaluates the output against a rubric); human grading (gold-standard, expensive, used to calibrate the other two). Anthropic's "Demystifying Evals for AI Agents" gives a useful vocabulary here — task/test case, trial, grader, transcript/trace, final outcome, harness — and explicitly recommends inspecting transcripts before trusting any aggregate score (Anthropic Engineering).

4. Run a baseline. Score the current implementation against the eval suite. The baseline matters because the only honest claim about subsequent iteration is "this change moved the score from X to Y" — and X has to be measured before iteration begins.

5. Iterate. Change prompts, swap models, alter tool policies, modify retrieval. Each change is a hypothesis. Each hypothesis is checked against the eval suite. The 80/20 ratio that holds for code generation generally — generate broadly, review the result — applies here too: iterate the prompt-model-tool stack with broad strokes, then read the failed transcripts and inspect why they failed.

6. Compare to baseline. Regression check. The new version cannot fail more cases than the baseline on the held-set; if it does, the change is rejected or the eval set is updated to reflect a known tradeoff.

7. Gate. CI checks on pull requests, pre-deploy gates on release branches, shadow deploys for irreversible behavior changes, canary rollouts for graduated risk. The deployment gate is the part of the workflow that gives EDD its production teeth and also the part most prone to misuse — see the failure modes section below.

8. Monitor in production. Online evaluation of real traffic. Anthropic's guidance is direct on this point: take aggregate scores skeptically until someone has read transcripts. Production monitoring closes the loop between offline evals and the actual user experience that offline evals are trying to approximate.

9. Feed production failures back into the eval set. New failure modes get curated into the dataset. Old eval items that no longer reflect the production distribution get retired or re-weighted. The eval suite is a living artifact, not a fixed contract.

The "write evals before implementation" mantra deserves explicit qualification at this point. For deterministic business logic embedded in an AI system — JSON schema validity, tool-call signatures, retrieval recall against known references — test-first works the way it works in classical TDD. For the latent-construct part of AI behavior — usefulness, tact, calibrated refusal, faithfulness — the most valuable eval cases are usually drawn from observed failures: real user traces, adversarial examples, near-miss outputs that the team did not anticipate. Pure test-first is often premature. A hybrid pattern is more honest: write the deterministic evals first, prototype the feature, harvest failure modes from prototype traffic into the rubric-graded portion of the suite, then gate.

Eval Taxonomy

The vendor and tool ecosystem tends to organize evals by tool features. A more useful taxonomy organizes them by engineering function — what question the eval answers, and where in the lifecycle it sits.

Eval type	Question answered	Typical grading	Lifecycle stage
Capability eval	Can the model do X at all?	Deterministic or model-graded against canonical answers	Model selection, vendor comparison
Regression eval	Did this change make us worse on cases we already passed?	Same grader as before, pinned baseline	Pre-merge, pre-deploy
Behavioral spec eval	Does the feature follow the product's rules?	Mixed deterministic + rubric-based	Pre-deploy, ongoing
Safety / policy eval	Does the system refuse what it should refuse and not refuse what it should answer?	Policy classifiers + audited human labels	Pre-deploy, continuous monitoring
Preference / A/B eval	Which version do users (or judges proxying users) prefer?	Pairwise comparison, often LLM-judge or human	Online experimentation, gradual rollout
Production monitoring	Is live traffic still working?	Sampled grading, often async	Post-deploy, continuous

Two distinctions are worth pulling out because conflating them is a recurring mistake.

Capability evaluation versus product behavior specification. "Can GPT-5 solve graduate-level math problems" is a capability question. "Does our tutor feature give grade-appropriate hints rather than full solutions when the user asks for help" is a product question. Capability evals are about the model. Product evals are about the feature, which is a model-plus-prompt-plus-tools-plus-context. They are different objects. The same model can be highly capable and still fail the product behavior spec because the prompt or context is wrong. Treating one as a substitute for the other is a common Goodharting precondition: teams optimize capability scores and assume product scores follow.

Offline evals, CI gates, online experiments, and monitoring. These four are at different lifecycle stages with different latency and confidence requirements. Offline evals run on curated datasets in development. CI gates run on every change. Online experiments compare two versions on live traffic. Monitoring evaluates the deployed version continuously. The "A/B eval" terminology in particular gets used to mean any of the last three depending on the writer; clarity here matters because the statistical treatment differs (paired comparisons across the same dataset versus randomized live traffic versus continuous sampling).

Tooling Ecosystem

The dominant tools, mapped to workflow stages rather than treated as a vendor brochure.

OpenAI Evals (open-source framework). A registry-and-runner format that ships eval definitions as YAML/Python with sample datasets and graders. Wide community adoption, but its data model assumes a single-call shape that fits chat completions cleanly and agent traces less cleanly. Best for capability and basic regression evals. (OpenAI Evals Guide)

OpenAI Evals API (hosted). First-party hosted product within the OpenAI platform. Lower friction if the team is already on OpenAI; deeper coupling to that ecosystem if not. The "should we use the platform's eval API or a tool-agnostic one" decision is a familiar Vendor Lock-In in AI Tooling tradeoff — convenience versus portability.

Braintrust. Eval-as-product platform with explicit support for golden sets, dataset versioning, judge versioning, regression thresholds, and judge-drift monitoring. Strong fit for the EDD workflow as the company describes it; commercial vendor with the standard lock-in concerns. (Braintrust EDD)

LangSmith. Trace-first observability with eval workflows layered on top. Datasets, evaluators, online and offline experiments, and Pytest/Vitest integration that lets teams write evals as ordinary tests. The Pytest/Vitest framing is itself an honest signal: eval-as-test, deliberately (LangSmith Pytest/Vitest). Strongest for teams already on LangChain; less natural for non-LangChain stacks.

Helicone. Observability-first product with eval and evaluator surfaces. Worth verifying current capabilities against the docs before adopting — Helicone's older "Experiments" feature was deprecated and scheduled for removal on September 1, 2025, so the eval surface has been in flux (Helicone Experiments). Production-ready for monitoring and trace storage; the eval workflow proper is less mature than Braintrust's or LangSmith's as of May 2026.

Custom in-house frameworks. Many serious AI teams build their own eval harnesses, often as thin layers over Pytest plus a model-call wrapper plus a results database. The advantages are full control over data handling, no vendor coupling, and the ability to tailor to a specific product's eval shape. The cost is maintenance burden, no shared learnings from the community, and the recurring problem that the in-house tool tends to ossify around the original team's mental model and resist evolution.

A useful comparison axis the vendor pages rarely surface explicitly: data handling. Eval suites contain prompts, completions, and trace data that may include user PII, customer business data, or sensitive internal information. The privacy/retention/access surface differs across tools. In-house frameworks give the most control. Hosted products vary in their data isolation guarantees. This is a AI Observability and Privacy question that deserves explicit attention before a tool is chosen, especially in regulated industries.

The mistake to avoid in this section, and that vendor blogs frequently encourage, is the implicit assumption that "OpenAI Evals, LangSmith, Braintrust, Helicone, and custom frameworks" are interchangeable. They are not. They sit at different points in the workflow, have different primitives, and assume different operational contexts. Picking one because a competitor team picked it is a weak reason; picking one because the team's actual workflow stages and data constraints fit its primitives is a strong reason.

Failure Modes

The literature on eval failure is more developed than the literature on eval workflow, which is one reason a serious treatment of EDD has to spend significant space here. Six failure modes recur.

Goodharting and Eval-Set Overfitting

The classical formulation of Goodhart's Law in AI Systems — when a measure becomes a target, it ceases to be a good measure — applies with unusual force to EDD because the workflow explicitly optimizes against the measure. Dwork et al. formalized the related problem of adaptive data analysis: repeated reuse of a holdout set against decisions informed by previous results produces overfitting in a way that single-shot statistical guarantees do not capture (Dwork et al. 2015). In EDD, prompts, retrieval rules, tool policies, and model choices are tuned repeatedly against visible eval failures. The team learns the eval's texture. The model may learn the judge's taste. The product gets better at passing the suite while becoming more brittle in the wild.

Public benchmarks give concrete warnings. SWE-Bench+ found solution leakage and weak test cases in a prominent coding benchmark; after filtering problematic cases, reported success rates dropped sharply (SWE-Bench+). SWE-rebench argues that static software-engineering benchmarks become stale and contaminated, inflating scores for newer models that were trained on data overlapping the benchmark (SWE-rebench). LiveCodeBench is a contamination-aware coding benchmark precisely because the authors took the contamination risk seriously enough to engineer around it (LiveCodeBench). EvalPlus rebuilt HumanEval with stronger test coverage and reported pass@k drops of up to 19.3–28.9% on the augmented version, demonstrating how thin the original tests had been (EvalPlus).

These are public benchmarks. Private product evals are not magically immune. They are usually smaller, less peer-reviewed, more path-dependent, and written by the same team incentivized to ship. The Goodharting pressure is in some ways stronger, not weaker.

Mitigations exist but cost something:

Held-out blind sets that the team cannot inspect during iteration.
Rotating canary cases that get retired once they're known.
Adversarial test generation (often by another model) to widen coverage.
Periodic qualitative review of transcripts on a schedule, regardless of aggregate scores.

The held-out blind set is the most commonly recommended mitigation and has its own cost: developers cannot inspect failures on the held-out set, which limits debuggability. A workable compromise is a multi-tier dataset — visible dev cases, visible regression cases, and a blind audit set that gets sampled occasionally to check whether visible-set improvements are transferring.

Judge Drift and Bias

LLM-as-judge is attractive because human evaluation is expensive and slow. It is not free of cost; it imports model bias into the release gate. Position bias, verbosity bias, self-enhancement bias, and reasoning limits are all documented (MT-Bench, Position Bias). LLMBar's finding that strong evaluators struggle with deceptively plausible outputs is particularly relevant for behavioral spec evals, where the question is often "is this answer wrong in a subtle way" rather than "is this answer obviously wrong" (LLMBar).

Worse, judges drift. The judge model's underlying weights may change across provider releases. The judge's prompt may be tuned. The rubric may be modified. Each of these moves the scoring distribution and breaks comparison across time.

Mitigations:

Pin the judge model version explicitly. If the provider updates the model, treat it as a methodological change requiring re-baselining.
Calibrate the judge against a small set of human labels regularly. If judge-human agreement on the calibration set drops, the judge needs retuning before the next release gate.
Use multiple judges where the cost allows, especially for high-stakes evals. Disagreement between judges is itself a useful signal that the rubric is ambiguous.
For evaluation that gates a deployment, never use a judge from the same model family as the system being evaluated unless the bias risk has been audited explicitly.

The Eval-Implementation Gap

Passing evals does not guarantee production behavior. The eval is a sample. The production traffic is a population. The difference between sample and population grows when:

Eval cases were curated, not sampled — they reflect what the team thought to test, not what users actually do.
The model's behavior is sensitive to prompt structure or context, and the production prompts differ in subtle ways from the eval prompts.
The user population is distributed differently from the eval dataset (regional, demographic, expertise, language).
New product features change the input distribution after deployment.

Anthropic's guidance is explicit on this point: scores should not be taken at face value until someone has inspected transcripts, and eval suites should be treated as living artifacts requiring ownership (Anthropic Engineering). Aggregate pass rates without transcript inspection are a textbook setup for the eval-implementation gap to widen invisibly.

The strongest mitigation is sampling production traffic into the eval dataset on a continuous basis — Braintrust's feedback-loop framing, LangSmith's online-trace-to-dataset pipeline, and the Anthropic guidance all converge on this practice (Braintrust Feedback Loops, LangSmith Evaluation, Anthropic Engineering). Done right, the eval set's input distribution tracks the production distribution with a lag, which keeps the gap from growing unboundedly.

Eval Brittleness Under Prompt Restructuring

Many evals are coupled implicitly to the prompt structure of the system being evaluated. The grader expects a particular output format, the rubric assumes a particular reasoning trace, the deterministic checks pattern-match on incidental phrasing. Then the team restructures the prompt — switches from chain-of-thought to direct answer, changes from JSON output to YAML, refactors the system prompt — and the eval scores swing wildly even though the underlying behavior is unchanged.

The diagnostic signal is that small surface-level prompt changes produce large eval-score changes. The mitigation is to write evals that bind to semantic outputs rather than incidental formatting, which is harder than it sounds. Schema-validated evals are robust against formatting drift; rubric-graded evals are robust if the rubric is written for behavior rather than presentation. Regex-based deterministic checks are the most fragile and should be avoided where possible.

Statistical False Confidence

Pass-rate gates of the form "deploy if pass rate is above 95%" treat aggregate scores as if they were precise measurements. They are usually noisy estimates from small samples. Anthropic's statistical-evaluation guidance argues for standard errors, clustered errors (where multiple cases share a feature like the same source document), paired-difference analysis (when comparing two systems on the same eval set), resampling for confidence intervals, and explicit power analysis before treating differences as meaningful (Anthropic Research). A "92% pass rate" with 50 samples and high variance is not better than an "88% pass rate" with 500 samples and low variance, even though the headline number says it is.

This failure mode is not exotic. It is the default behavior of any team that picks a threshold and ships when the threshold is crossed without doing the statistical work to check whether the threshold was actually crossed in a meaningful sense. It is also the failure mode that vendor dashboards encourage by default — most eval UIs surface the headline pass rate prominently and the confidence interval (if at all) in a footnote.

Mitigations:

Confidence intervals on every reported pass rate, not just the headline number.
Repeated runs of stochastic evals with seed control where possible, three or more runs as a baseline.
Severity weighting in the rubric — a 90% pass rate with no critical-severity failures is meaningfully different from a 90% pass rate with critical failures.
Regression budgets — small score drops on small samples are not regressions until they survive a power-aware test.

Organizational Decay

The technical failure modes get the most attention. The organizational ones are at least as common.

Eval ownership. Suites without a designated owner stagnate. The team that wrote them moves on, the rubric becomes outdated, and no one wants to be the person who modifies someone else's evals.
Stale suites. Cases that no longer reflect production distribution drag on the team — they fail in ways that no one cares about, get ignored, and the suite's signal-to-noise ratio drops.
Incentive gaming. When eval scores are visible and tied to release approval, the team has a structural incentive to optimize the visible scores. This is fine if the scores genuinely measure quality, problematic if they don't.
Rubber-stamping. Failed cases accumulate. The team adopts a habit of marking them as "known issues" without addressing them. The eval suite becomes a record of unaddressed problems rather than a development gate.
Cost drag. Large eval suites with model-graded rubrics cost real money to run. CI pipelines that run all evals on every change become unaffordable; teams skip evals to save cost; the gate erodes from the bottom up.

Mitigations are partly technical (caching, sampling strategies, smaller fast suites for CI plus larger slow suites for nightly runs) and partly organizational (named ownership, scheduled reviews of the eval set itself, explicit retirement of stale cases, severity-weighted budget for failed cases).

The "New Paradigm vs Renamed TDD" Debate

Among practitioners, the question of whether eval-driven development represents a genuinely new engineering discipline or a rebrand of test-driven development with extra ceremony recurs in blog posts, conference talks, and team discussions. Both positions have a strongest case worth taking seriously.

The "Renamed TDD" Case

The workflow ordering is identical: write the executable check, watch it fail, write the implementation, watch the check pass, refactor, repeat. The terminology — eval, suite, regression, gate, dataset — maps onto TDD vocabulary one-to-one. The structural shape of CI integration is the same. Many of the most pragmatic vendor frameworks don't even hide this: LangSmith markets eval integration as Pytest and Vitest fixtures, which is to say "your evals are tests, run them like tests" (LangSmith Pytest/Vitest).

If the workflow is the same and the tooling is structurally the same, the "new paradigm" framing serves vendor positioning more than it serves engineers. It creates room for "eval platforms" that are largely test runners with model-call instrumentation. The TDD discipline already covers what's worth covering; the rest is ceremony.

The strongest version of the rebrand argument is also a methodological one: classical software testing already includes property-based tests, fuzz testing, integration tests, and statistical performance tests. The discipline of testing under uncertainty is not new. EDD imports the same techniques into a different domain and gives them a new name.

The "Distinct Discipline" Case

The methodological additions in EDD are not optional ornaments; they restructure the discipline. Stochastic outputs require statistical treatment that classical unit tests do not need. Judge-graded evaluation imports a model dependency that classical tests do not have. Trace analysis and transcript inspection are mandatory parts of the loop in a way that has no clean equivalent in classical TDD — when a unit test fails, you read the assertion error; when an eval fails, you have to read what the model actually said and decide whether the failure is a real defect, a rubric error, a judge error, or a stochastic artifact. Production feedback loops, where failing user traces are fed back into the eval dataset on a continuous basis, are not standard TDD practice — and when they are, they are usually called something else, like "regression mining."

The distinct-discipline case also points to the eval-implementation gap as a class of failure that classical TDD doesn't have to grapple with at the same scale. Unit tests cover the function under test, and the function under test is the production code. Evals cover a sample of behavior, and the sample's relationship to production is a statistical question, not an engineering identity.

Where the Article Stands

The honest synthesis is that EDD is the TDD workflow with an empirically distinct failure surface — and the failure surface is the substantive part. Treating EDD as nothing but renamed TDD underweights the actual engineering work involved in calibrating judges, sampling production traffic into eval datasets, treating stochastic outputs statistically, and maintaining suites against model drift. Treating EDD as a paradigm shift overweights the marketing-friendly framing and underweights the genuine continuity in workflow shape.

The most useful framing, the one this article takes throughout: evals are executable hypotheses about the spec, continuously checked against human judgment, production traces, and changing models. The workflow is TDD-shaped. The methodological discipline is genuinely different in ways that have practical consequences for how teams should think about gates, ownership, and confidence. Calling it "TDD plus statistical treatment plus model judging plus production feedback" would be more accurate than either pole of the debate; "eval-driven development" is the name the field has settled on, and it works well enough as long as practitioners hold the methodological claim weakly.

A position adjacent to this one is worth naming for completeness. Some practitioners argue that EDD is closer to behavior-driven development (BDD) than to TDD — that is, the eval rubric is a Gherkin-style behavioral specification translated into runnable form. OpenAI's evals guide explicitly draws this analogy, suggesting evals are written by describing behavior in natural language and then formalizing it (OpenAI Evals Guide). The BDD analogy is in some ways tighter than the TDD one because BDD is already comfortable with rubric-style behavioral specification rather than input-output assertion. The cost is that BDD has its own track record of devolving into ceremony when applied without discipline, which suggests an obvious failure mode for EDD as well.

Practical Design Principles

Ten design principles synthesized from the above. None are surprising in isolation; the discipline is in applying them all consistently, not in any one of them.

Hold out blind sets. Visible dev sets and visible regression sets are useful for fast iteration, but the deployment gate should consult a held-out blind set that the team has not inspected during iteration. The blind set is the closest available proxy for production distribution.

Calibrate judges against human labels. Judge-human agreement should be measured periodically against a calibration set, not assumed to be high. When the model behind the judge changes, the calibration is stale.

Pin everything. Datasets, prompts, models, judge models, and rubrics should be version-pinned with explicit identifiers. The single most common source of "the eval scores changed and we don't know why" is unpinned components.

Repeat stochastic evals. Three runs as a baseline; report mean and confidence interval, not single-run scores. The cost of repetition is a small multiple of the cost of running once; the value of statistical honesty is much larger.

Sample production traffic into eval datasets. Curated evals reflect what the team thought to test. Production traffic reflects what users actually do. The eval set should track production distribution with some lag.

Risk-segment deployment gates. A single pass-rate threshold for all evals treats all failures as equivalent. They aren't. Critical-path failures (safety, billing, irreversible actions) need higher gates than nice-to-have improvements. Severity weighting in the rubric makes this explicit.

Expect to retire evals. Old cases that no longer reflect production behavior are not preserved as a museum; they're retired or archived. The eval set is a working tool, not a historical record.

Treat the eval suite as a product. Named ownership, regular reviews, scheduled audits. Suites without owners decay.

Separate offline evals, CI gates, online experiments, and production monitoring. These are different operational stages with different latency, confidence, and feedback requirements. Conflating them produces unclear release decisions and unclear monitoring signals.

Read transcripts. This is the principle Anthropic stresses repeatedly and that aggregate dashboards make easy to skip. Aggregate scores describe the suite. Transcripts describe the behavior. They are not substitutes.

Empirical Confidence

A short, calibrated read on the evidence supporting the claims in this article.

Strong evidence. The workflow shape (define evals, iterate against them, gate on regression) is well-documented in OpenAI, Braintrust, LangSmith, and Anthropic primary sources. The failure modes — judge bias, eval contamination, statistical noise, organizational decay — have direct supporting literature. The eval-type taxonomy (capability, regression, behavioral spec, safety, preference, monitoring) reflects how primary sources actually organize the work.

Moderate evidence. The claim that EDD reliably improves production AI product quality across teams is plausible but not established by independent randomized studies. Vendor-supplied case studies are not the same as base-rate evidence. The TDD literature suggests workflow ordering improves quality with some productivity cost in classical software; the analogous study for EDD does not exist at the time of this writing.

Weak evidence. Specific claims about the relative effectiveness of different tooling vendors are largely vendor-self-reported. Comparative independent benchmarks of eval platforms exist informally and on conference talks but not in peer-reviewed form.

Contested. Whether EDD constitutes a methodological paradigm shift or a TDD adaptation is, as discussed, a position-taking question rather than an empirical one. The position this article takes — that the workflow shape is TDD-derived but the methodological discipline is genuinely distinct in consequential ways — is one of several defensible reads.

The empiricist's recommended cheap experiment, for any team that wants to verify EDD's claimed benefits on their own work: pick one feature, split 30–50 cases into visible dev and held-out blind sets, define 3–5 rubric dimensions, calibrate an LLM judge against human labels, and compare two workflows over the same implementation budget — ad hoc prompt iteration versus eval-first iteration. Measure held-out pass rate, human preference, regression count, latency, cost, and number of prompt/model changes. Repeat each stochastic eval at least three times and report confidence intervals. The experiment costs days, not weeks. The highest-impact uncertainty it resolves: whether improving the visible eval suite transfers to held-out behavior, or merely Goodharts the suite. That answer matters more than any vendor-supplied claim.

Companion Entries

Core theory:

Goodhart's Law in AI Systems
Latent Construct Validity in AI Evaluation
Statistical Significance for LLM Evaluation
LLM-as-Judge: Mechanisms and Limits

Practice:

Test-Driven Development for Stochastic Systems
Behavior-Driven Development
Production Trace Sampling for Eval Datasets
Held-Out Blind Sets in AI Evaluation
Judge Calibration Against Human Labels
Severity-Weighted Deployment Gates
CI Integration for AI Eval Suites

Tooling:

OpenAI Evals Framework
Braintrust Eval Platform
LangSmith Evaluation Workflows
Helicone Observability
Custom In-House Eval Frameworks
Vendor Lock-In in AI Tooling

Counterarguments:

Eval-Driven Development as Renamed TDD
Limits of Pass-Rate as Quality Proxy
Eval-Set Goodharting in Practice

Adjacent:

AI Observability and Privacy
Benchmark Contamination and Saturation
Statistical Approach to Model Evaluations
Production Monitoring for LLM Systems
Shadow Deploys and Canary Releases for AI Features