Read the template line the way the model reads it: "A static-analysis engine flagged the code below as a possible {vuln_class} ({cwe}). Decide whether it is a REAL vulnerability or a FALSE ALARM." [6] Before any code arrives, an expert system has filed a verdict, and the task is framed as concur or contradict. That is a prior handed over by an authority the judge cannot audit, into a procedure trained to produce answers people approve of, which the author notes has a name: sycophancy [11].
Deleting the sentence is not free. It carries the vulnerability class and the CWE [6], which is what tells the judge which sink to look at and which neutraliser to look for. The accusation and the focus travel in the same string. That constraint is the reason this design has the flaw at its centre rather than around the edges.
The arithmetic is worth doing, because the author gives two rates that constrain each other. The weak model confirmed 90% of everything it was shown [3], so out of 200 snippets [1] it rejected roughly 20. If those 20 rejections are the "20% of false alarms" it removed, the false-alarm population in that sample is around 100, and it cannot be higher: any rejection that was actually a true positive pushes the count down [2]. So at most half of those 200 findings were noise, and the strong model's 51% [2] bought back about 51 of them against the weak model's 20 [3]. The gap is roughly 31 snippets out of 200, which is a triage queue, not a rounding error.
Treat 51% as a claim about someone else's 200 snippets. For it to be your number, your rule stage would have to over-report at about the same rate, your CWE mix would have to look like theirs, your definition of "false alarm" would have to match their labels, and you would need the same model build behaving the same way. The article identifies the failing model only as a well-regarded commercial model from a frontier lab [5], so even the ranking does not transfer. What transfers is the harness.
The prompt work itself is good craft, and worth copying regardless of which model you land on. The RULES block does not just instruct; it asserts that static engines raise false alarms routinely, labels rejection as a correct and expected answer, and names the exact error to avoid [14]. The author's read is that stating a fact about the world makes rejection reasonable rather than contrarian [16]. The confirmed=false criteria are checkable rather than vibes: not attacker-controlled, never reaches the sink, or neutralised by a parameterised query, escaping, encoding, or an allow-list [15]. "Allow-list" is the clause that catches the worked example, where id is checked against matches("[0-9]+") before being concatenated into a DELETE, so the data flow is real and the attack is not [9][17]. Four countermeasures, and the author's conclusion is that whether they fire is mostly a property of the model [18].
Which leaves the honest split. Stage one is deterministic: same code in, same suspects out [7]. Stage two has to be re-qualified against labels every time you change model or version, because its failure mode ships a findings list that reads perfectly normal [13]. The author's description of the alternative is the one I would put on the slide: a rubber stamp with a token bill [12].
