When people ask what spec-driven development is really about, they mean the spec. Writing down what you want precisely enough that an agent can build it sounds like the whole job, so that is the part that gets the attention. It is not the part that decides whether the output is any good.
The part that decides quality comes after the agent hands something back. You have to know whether it is right. Designing the check that answers that question, honestly and repeatably, is the real skill, and it is a genuinely hard one. In a world where a machine writes the code, evaluation is what code review used to be: the gate where a human decides whether this is safe to ship.
The Part Everyone Skips
An agent will almost always give you something that looks finished. It runs. It reads well. It handles the case you described. None of that tells you it is correct, because looking done and being right are different properties, and the gap between them is exactly where the expensive mistakes live.
Writing the spec narrows what the agent builds. Evaluation is how you find out whether it built the right thing. Skip it, or do it by squinting at the output, and you have not automated the work. You have just moved the bugs downstream to the people who trusted you.
Two Hats at the Same Time
Here is why evaluation is harder than it sounds. To design a test that actually catches failure, you need two kinds of knowledge at once. You need to know what correct means in the domain, and you need to know how software quietly goes wrong. Most people have one of those. This job needs both, held in the same head, at the same moment.
The domain half is knowing that a number measured two ways is not the same number, that a total has to reconcile, that a category everyone forgets about still has to be handled. The software half is knowing where things fail without announcing it: the boundary that is off by one, the empty case, the silent truncation, the assumption that held until the day it did not. A great domain expert who cannot see the second kind of failure will sign off on something broken. A strong technologist who does not know the domain will test the wrong things thoroughly.
Why This Reshuffles Who Is Good at the Job
Once evaluation is the hard part, the people who are best at it are not always the ones with the traditional title. The discipline that sits closest to the output tends to be the discipline that knows how to judge it.
A strong designer already thinks in exact states and edge cases rather than tidy user stories, which is most of what front-end evaluation is. I run back-end data products, and I lean on a data science and statistics background constantly: distributions, reconciliation, knowing which anomalies matter and which are noise. That is not a side skill anymore. It is the core of deciding whether the machine's answer can be trusted. The shift rewards whoever can look at an output and know, specifically, what would have to be true for it to be wrong.
The Agent Optimizes for Looking Done
You are not evaluating a neutral artifact. You are evaluating the work of something that wants to impress you quickly. Left alone, an agent optimizes for appearing finished over being correct, and it will tell you it is done long before it is. Your evaluation is the only thing standing between that instinct and production.
So the rule I repeat, every time, is simple: ask, do not assume. In back-end data work especially, accuracy is everything, and a fast wrong answer costs far more than a slow question. The evaluation is where you make the agent prove the claim it is so eager to make.
Invest in Evaluations Like They Are the Product
The practical conclusion is the one nobody wants to hear, because it is not the exciting part. Treat your evaluations as first-class work. Build them early, keep them, and grow them as you learn new ways the output can fail. Every failure you catch should become a permanent check, so the same mistake cannot slip through twice.
Writing the spec gets you a draft. Evaluation gets you something you can put your name on. In this way of working the tests are not the chore you do after the real work. They are the real work, and they are the reason the output is worth trusting at all.