Twee engines, één audit

Laat twee ervaren reviewers dezelfde pull request lezen en je krijgt twee verschillende lijsten. De een ziet dat de identifier in de URL nooit tegen de sessie wordt gecontroleerd; de ander ziet dat de retry-lus bij elke fout een databaseverbinding openlaat. Geen van beiden heeft ongelijk, geen van beiden is volledig. Taalmodellen gedragen zich net zo, om dezelfde reden: wat een reviewer opmerkt, hangt af van wat hij eerder heeft gezien.

Overeenstemming is een signaal

Eén model vertelt je hoe zeker het is. Dat getal is iets waard, maar het is zelfgerapporteerd: het model beoordeelt zijn eigen huiswerk. Wanneer twee modellen van verschillende labs, op verschillende data en met verschillende zwaktes, onafhankelijk op dezelfde zwakte in hetzelfde bestand uitkomen, is die overeenstemming bewijs van buiten het model. Dichter bij een second opinion komt een geautomatiseerde review niet.

Het omgekeerde telt net zo hard. Een bevinding die maar één engine meldt, is daarmee niet fout, en hem weggooien zou precies de bugs weggooien waar een enkele reviewer goed in is. Hij hoort gemeld en toegeschreven te worden, zodat jij zelf kunt wegen.

Waar één engine zwijgt

In de praktijk lopen de twee engines het meest uiteen bij bugklassen die redeneren vragen in plaats van patroonherkenning:

• Logicafouten: een korting die twee keer wordt toegepast, een state machine die na een terugbetaling nog een terugbetaling accepteert, een eigendomscontrole op het verkeerde object.
• Framework-specifieke autorisatie: middleware die een routegroep beschermt maar niet de API-handler die ernaast hangt.
• Resource- en geheugenlekken: listeners, timers en verbindingen die per request worden geopend en alleen op het happy path worden vrijgegeven.
• Prompt injection verstopt in commentaar of fixtures, die als onschuldige tekst leest als je er niet naar zoekt.

Hoe twee rapporten er één worden

Bij het samenvoegen verdient de tweede engine zichzelf terug of verdubbelt hij je ruis. De regels die we hebben vastgelegd:

• Bevindingen worden gematcht op wat een bug identificeert, niet op de formulering: de CWE-klasse en het bestand waarin hij zit.
• Een match wordt één keer gemeld, met de strengste van de twee ernstniveaus, want de veilige lezing is die waarnaar je handelt.
• We houden de tekst waarmee een ontwikkelaar verder kan: het langere bewijs, de concrete patch, de geordende stappen.
• Een bevestigde bevinding gaat naar hoge betrouwbaarheid en krijgt beide engines als label.
• Een bevinding die maar één engine zag, blijft staan, gemarkeerd met de engine die hem vond.

Beide engines lezen dezelfde broncode tegelijk, dus de audit duurt niet twee keer zo lang; hij kost twee keer zoveel om te draaien, en daarom hoort hij bij het Pro-plan. Is de tweede engine niet beschikbaar of geeft hij iets onbruikbaars terug, dan rondt de audit af met de eerste in plaats van te falen.

Niets hiervan maakt een rapport waar. Twee engines kunnen het eens zijn en allebei fout zitten; het geciteerde bewijs onder elke bevinding staat er juist zodat je controleert in plaats van vertrouwt. Wat bevestiging je oplevert is een volgorde: als er honderd bevindingen binnenkomen en je hebt één middag, begin dan bij de bevindingen die twee onafhankelijke reviewers allebei zagen.