Build1 distinct publisher3 min readPublished
A minimal harness published on dev.to fails a prompt diff when its score drops 0.05 below a stored baseline. That score is passes over cases, so how strict the gate is depends entirely on how many cases you wrote.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The gate's sensitivity is a property of the suite, not of the regression, because the score is passes divided by case count [5].
Run the arithmetic on the three cases the post ships [9]. One failure costs 0.333 of the score, more than six times the band [1]. With nineteen cases, one failure costs 0.0526 and still fails. With twenty, it costs exactly 0.05, which is not less than -0.05, so the diff merges green [2]. Every case added past the twentieth makes the gate less sensitive, even as it adds coverage. Single-case strictness at scale means comparing per case, or setting the band to zero.
The stored artifact cannot support the per-case version. Two runs at 0.90 are identical to the gate and need not share a single passing case [3]. Prompt edits that buy formatting compliance with refusal behaviour produce exactly that shape, and the author's own account of where regressions hide names formatting constraints and refusal behaviour together [11]. The failing ids and the first 160 characters of each bad output do get printed to the console [c6a]; they are simply not in the file the next run reads [7].
Graders are only as tight as their strings. grade_keyword lowercases the output and returns true if any keyword appears anywhere in it [3], and the shipped sentiment case looks for "negative" [9]. An output reading "this is not negative, it is neutral" passes [4]. A grader that agrees with you under negation is not actually checking the claim it's supposed to check. grade_word_count splits the entire response [4], so a polite lead-in spends words the summary needed [5].
Then the config line that sets the noise floor: temperature is 0.2 [c8b]. Sampling variation therefore lands in the delta alongside the prompt change, which means part of the 0.05 band is an unpriced flake allowance rather than headroom for real drift [6]. Pinning temperature to 0 costs generality and buys a delta that means what it says.
Cases run one model call each, in sequence [5], so a prompt diff pays N serial calls per CI run [7]. At three cases that is invisible. At three hundred it is CI wall-clock and a per-pull-request bill.
The craft here is in the smallness: the author keeps the harness to one file because a complicated eval framework is one more thing that can break silently [14], and the argument against relying on spot-checks is well made, since humans test happy paths and language models are stable there [11]. The author treats an eval suite as a required artifact of any prompt change [12], which is the schema-migration posture, and it is the right one. What each adopter has to set for themselves is the -0.05. It works for a short suite of near-deterministic calls; a larger suite or looser sampling needs a different number entirely.
Ranked by verification strength, evidence, and original report placement.
The harness described has three pieces: a JSON file of golden cases, a registry of grader functions, and a comparison step that measures the new score against a stored baseline; it fits in one Python file and one workflow file and runs anywhere a cron job can run.
The harness registers three grader functions by name: regex (re.search of a per-case pattern), keyword (case-insensitive substring match), and word_count_max (maximum word count). All are deterministic string checks; no model judge is used.
grade_keyword lowercases the model output and returns true if any of the case's keywords appears anywhere in that lowercased string.
grade_word_count returns true when len(output.split()) is less than or equal to case["max_words"], counting every whitespace-separated token in the response.
run_suite calls the model once per case in a list comprehension and computes score as sum of passed results divided by the number of results.
The comparison step prints score, baseline and signed delta, then prints a line "FAIL {id}: {output truncated to 160 characters}" for each failing case.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Your 90% Cache Hit Ratio Is a Lagging Indicator. Alert on Cold Misses Per Key1 distinct publisher
build
SSE promises framing, not JSON: the streaming bug that only appears on long answers1 distinct publisher
build
An AI test suite hit 94% coverage and missed the one branch that mattered1 distinct publisher
build
Your REPL Is Not A Container: Put Free-Variable Checks In CI Before Generated Code Ships1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
The whole system is on the page
Rare for a how-to: nothing mechanical has to be taken on trust. The grader functions, the pass-rate division and the literal `delta < -0.05` are printed, so the twenty-case arithmetic can be checked against the source without asking the author anything. The weak joint is the premise underneath the build — that the regressions worth catching cluster in edge cases, formatting and refusals — which rests on one developer's recollection of bugs he stumbled into in production.
One pipeline, and the sponsor owns the host
The only place this harness is known to run is the author's own setup, hosted on the free tier of the company that commissioned the write-up. No other team, repository, download figure or third-party report appears anywhere in this reporting, so there is nothing here to score.
A tripwire with an adjustable trigger
At three cases the word tripwire is earned — one failure swings the score by 0.333 against a 0.05 band. It stops being earned as the suite grows: at twenty cases the same single failure lands at exactly -0.05 and the strict comparison waves it through, the baseline forgets which cases passed, and temperature 0.2 folds sampling noise into the delta. None of the claims are false; the protection is simply narrower than the framing, and narrowest precisely when you have invested most in the suite.
Vendor-funded, disclosed in the same breath as the pitch
The disclosure is in the body and unambiguous: the piece was prepared as part of MonkeyCode's product outreach. It sits in the paragraph that recommends MonkeyCode's free server and 10 million token allowance, right after the observation that token cost and hosting are what kill most eval setups. Credit where due — the author says the harness is endpoint-agnostic and it plainly is. But the argument for continuously scheduled runs is also an argument for continuous inference, and that alignment shows in which friction gets named (tokens, hosting) and which does not (a gate that quietly loosens as the suite grows).
Certain about the code, unproven about the practice
Two different grades of certainty are bundled together here. The mechanics — pass-rate scoring, the strict threshold, what each grader accepts — are as solid as anything gets, because they are printed in full and reproduce on inspection. Whether this harness actually catches prompt regressions in the field is a single unreplicated assertion in a sponsored post, with no before-and-after numbers and no second publisher to check it against.