My Comment Section Designed My Next Experiment. Then It Made Me Freeze My Predictions.

Ten days ago I published an article
about a failure mode: tell a language model "a scanner flagged this code" and
some models agree with everything. Gemma removed 51% of my false alarms;
gpt-4o-mini removed 20% and confirmed 90% of whatever it was shown.

Then the comment section took the article apart — in the best way anything I've
written has ever been taken apart. Over four days, four readers found the
missing control in my experiment, made me preregister my predictions before
running it, fixed my statistics, pinned my model versions, and designed a
production monitoring spec I didn't ask for.

This article is the story of that review, and the results of the experiment it
produced. The predictions were frozen — publicly, in the thread, and in a
commit — before a single API call. What follows includes the rows that
survived and the rows that didn't.

The objection I couldn't answer

The article's headline number was a confirm-rate: what fraction of flagged
code each judge model agreed was really vulnerable. One reader pointed out
what that number actually is:

"Every prompt already tells the model that scanner flagged this, so you
measure agreement with the claim and detection together, in one number. …
Right now Gemma can be more skeptical or just worse at seeing bugs, and from
these tables I cannot tell which one it is."

He was half wrong and half right, and the split matters.

The half the existing tables answer: "maybe Gemma is just worse at seeing
bugs." A judge that rejects because it can't see bugs fails symmetrically —
it rejects real vulnerabilities and false alarms at similar rates, because it
can't tell them apart. Gemma's rejections split 51% on false alarms against 2%
on real bugs. Blindness doesn't produce that asymmetry.

The half they can't answer: why does gpt-4o-mini confirm 90% of everything?
Two stories fit the same tables. Story one: it believed the flag — classic
sycophancy, the article's framing. Story two: it sees vulnerabilities
everywhere and would confirm 90% with no flag mentioned at all — an
over-reporter, not a sycophant. My published numbers cannot distinguish these.

His fix: run the same 200 code slices again with the flag removed. The
per-model difference between the two runs is the anchoring effect, isolated.

"Write the prediction down first"

I agreed and started designing. Then the same reader added the constraint that turned
this from a follow-up into the most disciplined experiment I've run:

"Write the prediction down and publish it together with the result, because
once numbers exist both stories explain them equally well and it becomes
very easy to pick the one that fits."

That sentence describes half the AI benchmarking content on the internet. So
the experiment got a preregistration: protocol, predictions, and decision
rules, frozen and committed before the first API call. The thread comment
carrying the predictions is the public timestamp.

The protocol. Same 200 stratified slices from the OWASP Benchmark (100
ground-truth safe, 100 ground-truth real), same JSON schema, same three
models. Designing the neutral arm surfaced something I hadn't noticed in my
own prompt: the anchor lives in three places, not one.

The vulnerability class stays named in both arms — that was my one refinement
to the reader's design. Drop the class too and you've changed two variables:
the anchor and the task itself (verification becomes open-ended detection).
The flagged arm is generated by the exact code path that produced the
published numbers, asserted byte-for-byte on every candidate.

The frozen predictions, written before any run:

1. gpt-4o-mini's confirms on the safe subset fall by ≥15 percentage points without the flag.
2. Gemma moves by <10 points — the article's claim is that its rejections were never anchor-driven.
3. Ordering of the drops: mini > gpt-4o > Gemma.
4. All three keep confirming ≥95% of the real-bug subset.

And the pre-committed exits: if mini's drop is negligible, it's an
over-reporter, not a sycophant, and the previous article's causal framing gets
corrected in those words. No threshold moves after the numbers exist.

The readers weren't done

A second reader fixed the statistics. My frozen decision rule marked any
5–15-point difference "inconclusive," reasoning from single-rate noise of
about ±8 points at n=100. He pointed out the design is paired — both arms
judge the same 200 cases — so the information lives in the cases that flip:

"What carries the signal is the count of cases that flip confirm-to-reject
against the count flipping the other way; a paired test on those discordant
pairs resolves differences well inside the 5 to 15 point range you have
marked inconclusive."

He's right. Twelve cases flipping confirm→reject against two flipping back
nets only ten points — inside my dead zone — while the exact McNemar test on
those fourteen discordant pairs gives p ≈ 0.013. My unpaired band could have
filed a real effect as a shrug. The rule was amended, dated, and marked
pre-run in the changelog: paired inference primary, the old thresholds
demoted to size labels. As he put it — the edit was only free because the
numbers didn't exist yet.

The first reader then pinned the models. Hosted models move under you: the same alias
can serve a different engine next week, "and then the difference is not only
the sentence you removed." So the aliases were resolved to snapshots before
the first judgment call — gpt-4o-2024-08-06 and gpt-4o-mini-2024-07-18,
committed into the prereg — every response's reported model is checked
against the pin (a mismatch aborts the run), and the two arms run
interleaved per candidate, flagged then neutral back to back, so any
residual drift lands on both arms equally. Gemma's pin is its checkpoint
name — one thing open weights give you for free.

A third reader attacked the metric itself. A judge that reaches the
right verdict through invented reasoning scores as a clean pass — my columns
grade verdicts, not reasons. That one became a second experiment: a 145-row
audit sheet sampling correct confirms and rejections from all three models,
where every cited source and neutraliser gets checked by a human against the
slice it claims to describe. (In progress — grounded-rates will be published
when the human pass is done. An LLM grading LLM reasoning would re-import the
exact problem under study.)

A fourth reader wrote the ops manual. Three comments that turned "which judge do I
pick" into "how does a judge stay picked": a sycophantic judge in CI doesn't
fail loud, it converges to the same behaviour as having deleted the gate
while the dashboard stays green — so the benchmark can't be a one-time
choice. His spec — a labeled canary with both error directions tracked
separately per bug class, a fixed slice plus a rotating fresh slice with
their divergence watched as a slope — deserves its own article, and will get
one.

The results

(Every number below comes from the preregistered runs: the same 200 slices,
both arms interleaved per candidate, temperature 0, pinned snapshots. The two
OpenAI models completed all 400 judgments each. Gemma's arm was interrupted
mid-run by a provider outage on the free tier — her rows and the ordering
verdict land as a dated addendum when the run completes; the preregistration
permits appendixes, never edits.)

(The flagged arm also re-validated the pipeline: gpt-4o-mini reproduced its
published 80% trap-confirm rate exactly, on the pinned snapshot, weeks later.)

Predictions, scored against the frozen rules:

1. "mini falls ≥15 points without the flag" — REFUTED. It fell 6, and the paired test can't tell that from noise. The pre-committed exit fires, in its own words: gpt-4o-mini is an over-reporter, not a sycophant — it confirms three-quarters of the safe cases with or without being told a scanner flagged them. The previous article's causal framing for that model overstated the anchor. This is the correction.
2. "Gemma moves <10 points" — pending the addendum.
3. "Ordering: mini > gpt-4o > Gemma" — two legs in place (mini's +6.0 > gpt-4o's −5.0); the final ranking waits for Gemma's row.
4. "All keep ≥95% of real bugs" — holds for both completed models (96% and 99%).

What the numbers actually say. The sentence I blamed — "a static-analysis
engine flagged the code below" — turned out to be mostly innocent, for both
hosted models. Remove it and mini still confirms almost everything; gpt-4o
still discriminates mid-pack. The confirm behaviour is a property of the
model, not of the framing — which is a stranger and stronger version of the
previous article's own closing lesson than I intended to write.

gpt-4o's direction deserves one honest flag: its point estimate went up
without the flag (more traps confirmed), though not significantly. The
neutral arm necessarily removed the anchor and translated its antidote —
the rule reminding the model that "static engines raise false alarms
routinely." For a model that follows instructions closely, the antidote may
have been doing more work than the poison. That's a hypothesis, not a
finding; it's written here so the addendum and any follow-up are graded
against it, the same way everything else in this article was.

What I learned

1. Preregistration is absurdly cheap for LLM evals. The entire discipline
cost one markdown file and two commits. What it bought: when the numbers
above disagree with my predictions, I can't quietly prefer the story that
fits — the exits were written first. Every "we evaluated N models" post you
read that doesn't do this got to choose its narrative after seeing the
data. Including my own previous one.

2. Publish the guts and readers become reviewers. The thread could only
do this because the full prompt, both few-shot examples, and the response
schema were printed in the article. Nobody can find the missing control in an
experiment they can't see.

3. A confirm-rate is a product of two things — detection and
premise-agreement — and only a controlled comparison separates them. If your
prompt asserts anything ("the system detected X", "the user reported Y"),
your accuracy number quietly contains your model's agreeableness. Measure the
assertion's weight by removing it.

4. The correction rule is the credibility. Prediction 1 was mine, I liked
it, and it lost. The exit was already written, so the correction cost one
paragraph instead of a crisis: over-reporter, not sycophant. The honest part
is this — without the freeze, I don't believe I'd have written that sentence.
I'd have found an angle where the 6 points looked like support. The
preregistration didn't make me honest; it removed the option of being
smoothly, invisibly wrong.

To the four readers who built this in the thread: the preregistration, the
amended decision rules, and these results are your work as much as mine.

I'm Ali Afana — AI builder and security researcher, writing from Gaza. I
build systems in public, measure them against ground truth, and keep the
receipts. This scanner is one project on a longer road — follow for what
comes next.

GitHub · X · LinkedIn