Most teams building AI agents today are still doing prompt engineering by vibes. Change a word, eyeball the output, decide it "looks better," ship it. It's the equivalent of writing software without tests and hoping nothing breaks in production.
Eval-Driven Development (EDD) proposes a fix by borrowing directly from Test-Driven Development (TDD), the practice of writing tests before code that took roughly 15 years to become standard in software engineering. The core idea: define your evaluation rules before you write or change a prompt, then use those rules as an objective scorecard.
The Five-Step Loop
The workflow is straightforward:
- Define eval rules that specify what "good output" actually means - completeness, relevance, safety, cost
- Write the agent prompt with those rules as your target
- Run evaluations and get numerical scores instead of gut feelings
- Iterate the prompt using failing rules as specific guidance on what to fix
- Lock rules into production so you catch regressions automatically
Concrete rule examples include "no PII patterns like SSNs, credit cards, or emails in output," "must complete in under $0.05 per call," and "responses must address the user's specific question." These aren't vague guidelines - they're pass/fail checks with numbers attached.
Confirmation Bias is the Real Enemy
The strongest argument for this approach isn't efficiency - it's objectivity. When you read your own prompt's output, you're primed to see what you wanted it to say. Fixed evaluation rules don't have that problem. In one example, scores moved from 0.72 to 0.88 through systematic iteration, with relevance rules flipping from failing to passing as prompts improved.
This mirrors what IBM and Microsoft found when studying TDD in traditional software: a 40-90% reduction in post-release defects. The parallel isn't perfect - prompts are fuzzier than code - but the principle of separating specification from implementation holds.
Practical for Teams, Not Just Researchers
The real audience here isn't ML researchers who already run formal benchmarks. It's the growing army of developers, product managers, and even marketers who are now writing prompts that power customer-facing features. If you're building a support chatbot, a content generation pipeline, or an internal data extraction tool, you need a way to know when a prompt change makes things worse.
Tools like Iris offer up to 12 built-in evaluation rules across four categories, but the methodology works regardless of tooling. You could implement basic evals with a spreadsheet and a scoring rubric. The discipline matters more than the software.
TDD took from 1994 to roughly 2010 to become mainstream. Given how fast AI development moves, eval-driven development could compress that timeline considerably - especially as more non-engineers find themselves responsible for prompt quality in production systems.