You probably don't need an eval platform

Every few weeks someone asks which eval product they should buy. At this size, none of them. I say that as someone who builds an AI detection product. Scoring text for AI involvement is close to a worst-case eval problem. The thing you are measuring is fuzzy and the models underneath keep shifting. A regression does not throw an exception. It just quietly starts giving wrong answers with the same confident tone as before. If eval tooling were going to save anyone, it would save me. What actually saved me was embarrassingly small, and I want to describe it concretely, because I wasted real time believing it had to be bigger.

Agents and PR bots now ship more code, more prompt edits, and more dependency bumps than I used to touch by hand in a week. The surface that can silently change a score got wider. The fix didn’t get fancier. The few checks I trust just matter more, as long as they live next to the product and one person can read them.

The trap looks like diligence

When your model-backed feature misbehaves, the industry’s default advice is to stand up an evaluation pipeline. Dataset management, scoring dashboards, experiment tracking, a vendor for each. I went partway down that road, and I can report what’s at the end of it for a small team: another system to maintain, sitting between you and the product, whose own configuration becomes a source of bugs.

These platforms are built for teams where ten people share one model pipeline and need to coordinate. On a team of one or three, the coordination problem they solve doesn’t exist yet, and the ceremony they add lands on the same person who was supposed to be shipping. It’s the same instinct I wrote about in the orchestration trap: when the core problem is hard, building scaffolding around it feels like progress and postpones the hard part indefinitely.

Review bots sit in the same neighborhood now. BugBot, CodeRabbit, and the rest will comment on a diff. That is useful for catching an obvious mistake in a patch. It is not an eval. A bot that reviews code does not know that your AI-detection score on long mixed-authorship documents drifted by enough to matter. It never ran your golden set. It never diffed two traces of the same input. Treating a green review thread as proof the product still scores correctly is how fuzzy regressions sneak through a week of “looks fine” merges.

I have the same instinct when I verify a product change in the browser as a user: click the path, read the output, trust what I see more than what a dashboard claims. Eval work for a small team is that instinct pointed at model-backed behavior. You need a cheap way to replay known hard cases and notice when the story changed. You do not need a second product whose job is to make that look enterprise-ready.

What a regression actually looks like

Here’s the moment that converted me to minimalism. A dependency bump changed how my pipeline chunked long documents. No test failed. The API returned 200s. Scores still looked score-shaped. But long submissions were now being judged mostly on their opening sections, and accuracy on exactly one category of input fell off a cliff.

I caught it days later than I should have, and what finally exposed it was diffing two stored traces of the same document, one from before the bump and one from after, and seeing that the second one processed a third as much text. That experience set my priorities permanently. Everything I now consider essential is whatever would have caught that bug on day zero.

The same class of bug is easier to ship now, not harder. An agent PR can bump a chunking library, rewrite a prompt template, or trim a context window while “cleaning up” a file. The diff can look tidy. A review bot can approve the style. CI for unit tests can stay green. The scoreboard in your head still says the model is fine. None of that notices that the intermediate outputs shrank, that a truncation landed earlier, or that one category of real document started getting half a pipeline. If your only safety net is “someone looked at the PR,” you are betting that a human will notice a behavioral change that does not appear in the code review surface.

I have had quieter cousins of that first regression since. Two more arrived the same way: innocent-looking dependency or plumbing changes, no prompt edit I would have flagged in review, and a score shift that only made sense once I lined up traces. The pattern is boring on purpose. Boring means you can automate the check without inventing a platform.

The whole system, honestly

Three pieces. All of them live in the repo next to the code.

Traces you can diff. Every scoring run writes a structured record: model, version, input hash, intermediate outputs, final score, latency. Plain JSON lines. When something feels off, I pull the trace for the same input from last week and diff them. Ninety percent of “the model got worse” investigations end here, and about half of them turn out to be my code, the chunking, the prompt template, a truncation, and never the model at all.

Store enough to reconstruct the path, not enough to drown in telemetry. I care about which chunks went to the model, which prompt version ran, what came back before post-processing, and the final score. If those four things match last week’s good run for a hard input, I stop blaming the foundation model and start reading my own diffs. If they diverge, I already know where to look. That is the whole point of a trace you can diff: it turns a vibes argument into a file comparison.

A golden set of about twenty inputs. Real documents, chosen because each one nearly fooled the system in a different way. Human-written text that looks AI-ish, AI text that’s been hand-edited, mixed authorship, one document in the category that burned me above. Twenty is a deliberate number. I can read every failure by hand over a coffee, and I actually do, which is precisely what nobody does with a two-thousand-row eval suite. When a new failure mode shows up in production, one example of it earns a place in the set, and something redundant leaves.

I resist the urge to grow the set for comfort. A bigger suite feels safer and usually makes me lazier. The moment I cannot name why each example is in there, the set has stopped being a tool and started being furniture. Keep the failures load-bearing. Keep the set small enough that a bad PR produces a short list you will actually open.

A CI gate with documented tolerance. The golden set runs on every pull request. Scores can drift within a written-down band before the build fails, because model-backed systems wobble and a zero-tolerance gate just trains you to ignore red builds. The tolerances live in a comment right above the numbers, with a sentence explaining each one, so future me knows whether a violation is alarming or expected.

That gate is also where agent PRs earn their keep or get blocked. If Codex or Claude Code opens a change that touches prompts, chunking, or scoring glue, I want the same golden run as a human PR. No special lane. No “the bot usually knows what it’s doing.” The tolerance comment is there for the human who has to decide whether to widen the band or revert the change. Ceremony that postpones that decision is still the wrong product to buy.

Total cost: a few files, no vendors, no dashboard. It has caught every regression that mattered since, including two more that arrived the same way as the first one, through innocent-looking dependency changes rather than through anything I did to prompts. On days when I’m swapping between agents all afternoon, those few files are the part of the stack that still behaves like engineering instead of hope.

What I still do not buy

I still do not buy an eval platform for this work. Large teams with shared pipelines may need shared scoreboards. My bottleneck is still catching silent product regressions on a fuzzy task, and that bottleneck yields to traces, a tiny golden set, and a CI gate I trust. Paying for dashboards before those three pieces exist is how you rent the feeling of diligence.

The coding tools themselves get their own write-ups in the AI coding tools hub. None of them will tell you whether your AI-backed feature still scores the hard cases the way it did last Tuesday.

The uncomfortable part

The reason this works is that the golden set is small enough that a human still reads the failures. Once the output pile is bigger than what I will look at, I stop seeing why a score moved. A 0.91 to 0.89 shift is noise until I open the two documents that flipped.

Agents make that discomfort sharper. More diffs land. More of them look plausible. More of them can change behavior without looking like a behavior change in the PR. Review bots reduce some of the obvious risk and none of the fuzzy score risk. So the discipline stays personal: keep the set small, keep the traces diffable, read the failures yourself, and refuse to outsource the moment of judgment to a vendor chart.

So I keep traces from day one and a set of about twenty examples I actually understand. The CI gate uses tolerances I wrote down on purpose. The money I did not give an eval vendor goes to coffee while I read my own failures. When this stops being enough, it will be because coordinating people is the bottleneck, not catching regressions.