Eval-driven development: what it is, how to do it, and which eval tools support it

Short answer: eval-driven development (EDD) is test-driven development for AI agents: you build a fixed eval set first, run a baseline, and score every prompt, model or tool change against that same set, keeping a change only if it fixes the target cases without breaking the rest. Updated 11 Nov 2026.

By Evals Review editorial team · Published 11 Nov 2026 · Updated 11 Nov 2026

Source: the loop below follows LangChain's guide to eval-driven development (9 Nov 2026), rewritten in our own words and split into smaller steps. LangChain sells LangSmith, which its guide uses throughout; the tool table below covers other vendors too. How we checked: each tool claim links to the vendor's docs or pricing page, read on 11 Nov 2026. This is a docs review, not a hands-on test. How we review.

TL;DR

  • Write the eval before the change, and confirm it fails on the current agent.
  • Judge each change by comparing experiments example by example; the average can hide a regression.
  • Keep a held-out slice to catch overfitting to your own examples.
  • Run cheap checks on every pull request, judge-based evals nightly, and turn production failures into new examples.

Eval-driven development vs test-driven development

EDD borrows TDD's order of work: define success first, then build toward it. What changes is the test, because agents are not deterministic programs. [LangChain blog]

TDD and EDD side by side
Test-driven developmentEval-driven development
Unit of testOne test, one expected resultA set of examples scored together
Same input twiceSame outputOutput can differ between runs
Correct answersUsually oneOften several valid phrasings or paths
How it is gradedAssertions in codeCode checks where possible, LLM judges or people for the rest
A change is good whenAll tests passTarget examples improve and no working example regresses
Main trapTests that never failOverfitting to the examples you tuned on

How to do eval-driven development, step by step

  1. Pick one behavior and write a pass/fail spec. Work on one behavior at a time, taken from a feature you are about to build or a failure you saw in real runs. Write four lines: when it should happen, what the agent should do, what it should not do, and which existing behaviors must keep working. If a reviewer can't mark a run pass or fail from the spec, it is too vague. "The answer is helpful" is not a spec. For help writing criteria, see how to write AI evals.
  2. Build the eval set before you change anything. Collect examples with an input and, where you can, a reference output. Real runs make the best inputs because users phrase things you would not predict. Include cases for the new behavior and cases for the behaviors that must not break. Keep a held-out slice you never look at while tuning; you will use it to catch overfitting in step 6.
  3. Write the evaluator. Use a code check when the answer can be checked deterministically (the right tool was called, the JSON parses, a field is present). Use an LLM judge only for what code can't decide, and check the judge against human labels before you trust it. Decide what you are scoring: the final answer, one step, the full sequence of tool calls, or the end state the agent leaves behind.
  4. Run a baseline and confirm the new cases fail. Run the current agent over the whole set and save the result as an experiment. The cases for the new behavior should fail; if they pass already, the eval is not testing the change. The other cases record what works today.
  5. Make one change, rerun, and compare example by example. Change one thing (a prompt, a tool description, the model, retrieval settings) and rerun the same set. Compare against the baseline per example, not only on the average: a higher mean can hide a case that used to pass and now fails. Weighing a model switch? A worked eval plan for one new release: how to evaluate Gemini 4 Carbon. To share a comparison with people outside your eval tool, see analyzing eval results in Claude Sheets.
  6. Read the traces behind every regression. Open the trace of each newly failing case to see which model or tool call went wrong, fix the cause, and rerun. When the tuned cases pass, check the held-out slice: if it stays flat while the tuned set climbs, you are fitting your examples rather than the behavior.
  7. Automate it and feed production back in. Run fast code checks on every pull request and slower judge-based evals nightly or before a release. In production, score a sample of live traces, route flagged runs to human review, and turn each confirmed failure into a new example. Then the loop starts again at step 1.

A worked example, in brief. LangChain's guide adds a ticket-filing tool to an internal docs agent. The spec says: file a ticket when something is broken, don't file one for how-to questions, and keep the docs and web search tools working. After the change the average score rose, but a how-to question about the VPN started filing tickets, because the new tool's description matched any VPN mention. Reading the trace showed the cause, and a narrower description fixed it. [LangChain blog]

Common mistakes

  • A spec you can't grade. If two reviewers would disagree on pass or fail, rewrite it.
  • Writing the eval after the fix. It will pass by design. Write it first and watch it fail.
  • Reading only the average. Review the examples that flipped from pass to fail before keeping a change.
  • Evals with no purpose. Tie each one to a failure you are fixing or a feature you are building.
  • An unchecked judge. Compare the LLM judge with human labels first, and prefer narrow pass/fail questions to a 1-10 scale. [LangChain blog]

For the wider practice around this loop (error analysis, synthetic data, judge bias, error bars), see our 15-step LLM eval checklist.

Which eval tools support eval-driven development

The columns are the EDD steps where a tool helps most. "Not verified" means we did not find it on the vendor's own pages on 11 Nov 2026; it does not mean the tool lacks it.

Documented support per EDD step (vendor pages read 11 Nov 2026)
ToolBuild the set from real runs (step 2)Compare experiments (step 5)Run in CI (step 7)Score live traffic (step 7)Human review (steps 3, 7)
LangSmithyes: add real runs to a dataset [LangChain blog]yes: comparison view with regressions and improvements [LangSmith docs]yes: pytest and Vitest [LangSmith docs]yes: online evaluators [LangSmith docs]yes: annotation queues [LangSmith docs]
Braintrustyes: docs say to build datasets from production logs [Braintrust docs]yes: side-by-side diffs [Braintrust]yes: GitHub Actions or CLI [Braintrust docs]yes: online scoring rules on production traces [Braintrust docs]yes: human review scores [Braintrust docs]
Langfuseyes: add from trace [Langfuse docs]yes: experiments via UI and SDK [Langfuse pricing (feature table)]yes [Langfuse docs]yes: judges on live data with sampling [Langfuse docs]yes: annotation queues (1 on Hobby, 3 on Core) [Langfuse pricing (feature table)]
Comet Opikyes: datasets from production traces [Comet Opik pricing (feature table)]yes: experiments dashboard to compare prompts [Comet Opik pricing (feature table)]yes: PyTest integration [Opik README on GitHub]yes: online evaluation [Comet Opik pricing (feature table)]yes: annotation queues [Comet Opik pricing (feature table)]
DeepEval + Confident AIyes: auto-curate from traces (Confident AI) [Confident AI pricing (feature table)]yes: regression testing across test runs [Confident AI pricing (feature table)]yes: deepeval test run in CI [DeepEval docs]yes: online evals, Starter plan and up [Confident AI pricing (feature table)]yes: annotation queues, Starter and up [Confident AI pricing (feature table)]
Maxim AIyes: dataset creation from logs [Maxim AI pricing (feature table)]yes: comparison runs, paid plans [Maxim AI pricing (feature table)]yes: CI/CD integrations [Maxim AI pricing (feature table)]yes: online evals, paid plans [Maxim AI pricing (feature table)]yes: human evaluation support [Maxim AI pricing (feature table)]
Arize AXnot verifiedyes: offline evals on datasets and experiments [Arize AX pricing (feature table)]yes [Arize docs]yes: online evals on traces [Arize AX pricing (feature table)]not verified
Promptfoonot verifiedyes: side-by-side matrix view [Promptfoo docs]yes [Promptfoo docs]not verifiednot verified

Our picks

  • Already on LangChain or LangGraph: LangSmith. LangChain's own guide maps onto it step for step, including dataset splits and pytest/Vitest. It charges per seat ($39 per seat a month on Plus, checked 11 Nov 2026), so reviewers cost money.
  • Open source and self-hosted: Langfuse or Comet Opik. Both document datasets built from traces, CI runs, online scoring and annotation queues. Compare them in Opik vs Langfuse.
  • Code-first, no platform yet: Promptfoo or DeepEval in CI. You give up stored traces and review queues until you add a platform. See DeepEval vs Promptfoo.
  • Product managers run the comparisons: see LLM evaluation tools for product managers for no-code options and seat costs.

Evals for AI product teams: the full series

FAQ

What is eval-driven development?

Eval-driven development (EDD) is a way of building AI agents where you write an eval set before you change the agent, run a baseline, and score every prompt, model or tool change against the same set. A change stays only if it fixes the target cases without breaking others.

How is eval-driven development different from test-driven development?

TDD writes a failing test before the code, and each test has one right answer. EDD keeps the test-first habit but scores many examples, because agent outputs vary between runs, several answers can be correct, and the agent picks its own steps. Results are compared as experiments, not single pass/fail runs.

How many examples do I need to start eval-driven development?

LangChain's guide starts its example agent with a handful of examples covering the new behavior and the behaviors that must keep working. Start small, keep a held-out slice, and add every confirmed production failure as a new example.

Should I aim for a 100% eval score?

Not on the examples you tuned against. A perfect score there can mean you fitted those exact cases. Check a held-out set you did not look at while iterating; if it stays flat while the tuned set rises, you are overfitting.

Do I need a platform for eval-driven development?

No. A dataset file, a script that runs the agent and a code check in CI is enough to start. Platforms such as LangSmith, Braintrust, Langfuse or Opik add stored experiments, side-by-side comparison, trace links and human review queues, which matter once several people review results.

Sources