Evals are the new code review
The gate that decides whether what you built is any good moved. Most teams have not moved with it.
Code review exists because writing code is where mistakes enter. So we put a gate right there: another set of eyes on the diff before it ships.
When agents write a growing share of the code, that gate stops catching what breaks. The failure lives in the behaviour: plausible and wrong, or right in the demo and wrong on the rare inputs. A person reading the diff line by line will not see it, because the diff looks fine.
So the checkpoint moves, from "is this code correct" to "is this behaviour correct, across the inputs that matter." That is an eval: a set of cases run against the output, with a pass mark set in advance, and you do not ship past a failing gate.
Who does the checking is a routing decision: cheapest reliable check first. Rules settle shape, format, and thresholds. A model handles what a rule cannot, cheap enough to run on every change. A person comes last, for calls that set a standard. A person cannot read ten thousand outputs, and a rule can.
That is also the line agents do not cross. An agent can run the check and tell you six outputs look off. It does not set the threshold, and it does not decide a failing case is acceptable this once. The check is delegated. The standard is not.
The tell that you have under-invested is confidence that comes from how it felt when someone tried it. That was the state of code quality before code review, and we did not accept it there.
Deciding what to evaluate, and what threshold counts as good enough, is one of the most valuable calls a builder makes now. The eval suite is where your standard for quality stops being an opinion and becomes something the system enforces.
The check is delegated. The standard is not.