Evals-driven development inverts the build order: before writing the prompt, the agent, or the pipeline, write the evaluation that will decide whether it works. The practice does for AI features what test-driven development did for software — converts taste into specification and debate into measurement.

The mechanism is the red-green loop, translated. Red: assemble a failing eval set from the task you are about to build — real inputs, graded expectations, the failure modes you already fear. Green: build the smallest system that passes it. Refactor: improve cost, latency, and robustness while the eval holds the line. The compounding effect comes from what the eval set forces early: concrete definitions of done, edge cases collected before optimism sets in, and a shared artifact that ends "is it good enough?" arguments with data instead of seniority.

The practice scales through tiers, and teams should be honest about which tier they inhabit.Smoke evals — a dozen cases run on every change — catch the embarrassing class of regressions. Task-level evals — end-to-end outcomes scored by rubric or deterministic checks, run on every PR — catch real regressions. Dataset evals — hundreds of stratified cases, run nightly and on model changes — catch the slow drifts and vendor deprecations. Most teams claim the third tier and operate the first; the gap shows up as the incident where "nothing changed" and everything got worse.

Making It Stick

• Evals live with code: versioned in the repo, run in CI, owned by the feature team — a separate "eval team" produces theater, not safety.
• Report per slice: aggregate pass rates hide exactly the regressions that matter; publish the worst slice next to the average.
• Feed failures back: every production incident becomes an eval case within the week — the suite should remember what production taught you.
• Gate with judgment: a 100% eval gate becomes a ceiling; pair hard gates on critical slices with advisory trends everywhere else.

The cultural shift is the real product. Teams that adopt evals-first stop asking "can the model do this?" and start asking "what would count as doing this, and how would we know?" — and that question, it turns out, is the difference between demoing AI features and shipping them.