Traditional CI/CD assumes a test either passes or fails deterministically. AI features break that assumption: a prompt tweak, a model version bump, or a retrieval change can degrade quality gradually and non-deterministically, passing every existing unit test while quietly making real answers worse for real users. Shipping AI features safely requires a different kind of gate — one that measures quality, not just correctness.
What an eval gate actually checks
- A golden dataset — a curated, versioned set of representative real inputs with known-good expected outputs or scoring criteria, run against every candidate deploy.
- Automated or model-assisted scoring — since many AI outputs aren't exact-match testable, scoring against rubrics (accuracy, completeness, tone, citation correctness) using either rule-based checks or a second model as judge.
- Regression thresholds — a deploy is blocked if aggregate quality scores drop below a defined threshold versus the previous production version, not just if the code fails to compile.
- Human spot-check sampling — automated scoring catches most regressions, but a small human-reviewed sample on every release catches the subtle failures automated scoring misses.
The question an eval gate answers that no unit test can: 'did this change make our answers meaningfully worse for real users,' checked before the change reaches them, not after a support ticket surfaces it.
Why this is worth the extra engineering
Without an eval gate, prompt and model changes ship on faith, and quality regressions are discovered by users — or worse, discovered by nobody, quietly eroding trust in the feature until usage drops and nobody's sure why. An eval gate turns 'did this get better or worse' from a debate into a number checked automatically, on every single deploy.