💻 computer science

Citation Discipline in Spec-Driven Development: A Cross-Model Empirical Study of Output Determinism and Automated Hallucination Detection in LLM-Generated Code

Deze cross-model empirische studie toont aan dat hoewel Spec-Driven Development-frameworks die verplichte per-regel vereiste-citaties afdwingen de automatische detectie van hallucinaties aanzienlijk verbeteren, ze tegelijkertijd de output-determinisme verminderen in vergelijking met niet-geciteerde benaderingen, waarmee een fundamentele afruil tussen verifieerbaarheid en consistentie in door LLM gegenereerde code wordt vastgesteld.

Oorspronkelijke auteurs: Subham Panda

Gepubliceerd 2026-07-01

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Subham Panda

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een team inhuurt van ongelooflijk getalenteerde, maar een tikkeltje ondeugende robotchefs om een complex gerecht te bereiden op basis van een recept dat jij hebt geschreven. Je wilt dat de robots je instructies perfect opvolgen, maar je wilt ook voorkomen dat ze stiekem hun eigen "speciale ingrediënten" toevoegen (zoals extra kruiden of willekeurige groenten) die je niet hebt gevraagd.

Dit artikel is een wetenschappelijk experiment om uit te zoeken wat de beste manier is om deze robotchefs aan te sturen. De onderzoekers testten drie verschillende manieren om instructies te geven om te zien welke methode de meest consistente resultaten opleverde en welke methode de robots kon betrappen wanneer ze probeerden ongeautoriseerde ingrediënten toe te voegen.

Hier is de uitslag van het experiment met behulp van eenvoudige analogieën:

De Drie "Instructiestijlen" die werden getest

De onderzoekers vergeleken drie verschillende manieren om de robots te vertellen wat ze moesten doen:

De "Strenge Notitie-nemer" (traceSDD): Deze methode vereist dat de robot een klein plakz sticky note naast elke enkele regel code die hij schrijft, plakt. De notitie moet precies aangeven welk deel van jouw recept hij volgt (bijv. "Deze regel is voor Stap 3.1"). Als de robot een regel schrijft zonder notitie, of een notitie schrijft voor een stap die niet in jouw recept voorkomt, is dat een waarschuwingssignaal.
De "Verhalenverteller" (Spec Kit): Deze methode gebruikt een standaard receptformaat met user stories en opsommingstekens. De robot volgt het verhaal, maar hoeft zelf geen plaknotities of citaties in de code te schrijven.
De "Kaartmaker" (OpenSpec): Deze methode geeft de robot een recept en een aparte kaart (een zijbestand) die de stappen uit het recept koppelt aan de code nadat de robot klaar is met koken. De code zelf bevat geen notities.

De Twee Hoofddoelen

De onderzoekers maten twee zaken:

Consistentie (Determinisme): Als je de robot drie keer achter elkaar hetzelfde gerecht laat koken, zullen de drie gerechten er dan exact hetzelfde uitzien en smaken? Of zijn ze elke keer een klein beetje anders?
De "Snitch"-test (Hallucinatie Detectie): Als de robot stiekem een verboden ingrediënt toevoegt (een "hallucinatie"), kan het systeem dit dan automatisch detecteren?

De Grote Ontdekking: De Trade-off

De studie vond een fascinerende "catch-22" of trade-off. Je kunt niet zowel de cake hebben als hem opeten; je moet kiezen tussen Consistentie en Veiligheid.

1. De "Geen Notities"-aanpak is consistenter
Wanneer de robots de ruimte kregen om code te schrijven zonder de plaknotities (de "Uncited" conditie), waren ze ongelooflijk consistent. Als je hen drie keer achter elkaar hetzelfde gerecht liet koken, waren de resultaten bijna identiek.

De Analogie: Denk aan een muzikant die een liedje speelt. Als ze niet gedwongen worden om bij elke noot op te houden om op te schrijven waarom ze die noot spelen, kunnen ze het liedje vloeiend en elke keer op dezelfde manier spelen.

2. De "Strenge Notities"-aanpak betrapt de bedriegers
Echter, wanneer de robots werden gedwongen om voor elke regel een plaknotitie te schrijven (de "Cited" conditie), werden de resultaten minder consistent. De drie gerechten verschilden enigszins van elkaar.

De Analogie: Stel je voor dat de muzikant na elke noot moet stoppen om een notitie te schrijven: "Ik speelde dit omdat de bladmuziek dat aangaf." Deze afleiding zorgt ervoor dat hun uitvoering telkens een beetje varieert.
MAAR, deze methode had een superkracht: het betrapte de bedriegers. Omdat de robot voor elke regel een specifieke stap uit jouw recept moest citeren, kon het systeem direct spotten of de robot een regel schreef die een stap citeerde die niet bestond in jouw recept.
- Het Resultaat: De "Strenge Notitie-nemer"-methode betrapte 86–88% van de neppe ingrediënten die de robots probeerden te smokkelen. De andere twee methoden vingen 0% van de neppe ingrediënten.

Wat betreft de andere methoden?

Spec Kit (De Verhalenverteller): Dit was de slechtste presteerder. Het produceerde de minst consistente resultaten (de gerechten varieerden het meest) en betrapte nul neppe ingrediënten.
OpenSpec (De Kaartmaker): Dit presteerde beter dan de Verhalenverteller, maar kon de neppe ingrediënten nog steeds niet automatisch vangen omdat de notities niet in de code zelf stonden geschreven.

De "Makkelijk vs. Moeilijk" Verrassing

De onderzoekers merkten ook iets interessants op over de moeilijkheidsgraad van de taken:

Makkelijke Taken: De straf voor het schrijven van notities was enorm. Bij eenvoudige taken maakte het dwingen van de robot om notities te schrijven de resultaten zeer inconsistent.
Moeilijke Taken: Bij complexe taken was de straf veel kleiner. Wanneer de taak moeilijk is, heeft de robot zoveel manieren om het op te lossen dat de extra notities de consistentie niet zo erg verstoren.

De Kern van het Verhaal

Dit artikel concludeert dat er een fundamentele keuze gemaakt moet worden bij het gebruik van AI om code te schrijven:

Als je wilt dat de AI exact dezelfde code elke keer produceert (Consistentie): Dwing de AI dan niet om citaties te schrijven. Geef het simpelweg een gestructureerd recept.
Als je met zekerheid wilt weten dat de AI geen ongeautoriseerde code heeft toegevoegd (Veiligheid): Dan moet je de AI dwingen om voor elke regel een citatie te schrijven. Dit zal ervoor zorgen dat de code er elke keer net iets anders uitziet, maar het geeft je een unieke, automatische manier om de AI te betrappen als hij probeert te liegen of dingen toe te voegen die je niet hebt gevraagd.

De onderzoekers ontdekten dat deze "Veiligheid vs. Consistentie" trade-off plaatsvindt, ongeacht welk AI-model je gebruikt (ze testten twee zeer verschillende modellen, en de resultaten waren hetzelfde). Het is een regel van het spel, en niet slechts een glitch in één specifiek robotmodel.

Technische Samenvatting: Citatie-discipline in Spec-Driven Development

Probleemstelling

De opkomst van agentic coding-systemen, waarbij Large Language Models (LLM's) autonoom software schrijven en reviseren, introduceert een kritieke verantwoordelijkheidskloof: het verifiëren of gegenereerde code strikt de gespecificeerde vereisten implementeert zonder "hallucinaties" te introduceren. Deze hallucinaties—die zich manifesteren als buiten bereik liggende functies, ongeautoriseerde imports uit trainingsdata of over-engineering—passeren vaak functionele tests terwijl ze beveiligings- of compliance-risico's introduceren.

Hoewel traditionele vereisten-traceerbaarheid (bijv. IEEE 830, tools zoals DOORS) vereisten koppelt aan werkproducten, zijn deze methoden doorgaans op artefactniveau en handmatig, wat ongeschikt is voor snelle AI-ondersteunde iteratie. Drie opkomende Specification-Driven Development (SDD) frameworks proberen dit aan te pakken met verschillende filosofieën:

traceSDD: Handhaaft verplichte inline citaties per regel (bijv. # [REQ-XXX.Y.Z]) die code binden aan specifieke vereistenpunten.
Spec Kit: Gebruikt artefact-niveau traceerbaarheid (user stories, acceptatiecriteria) maar mist inline code-citaties.
OpenSpec: Vertrouwt op post-hoc externe trace-kaarten (YAML sidecars) zonder de broncode direct te annoteren.

De centrale onderzoeksvraag is of het dwingen van een LLM om vereisten te citeren voor elke regel code de implementatiecorrectheid, de output-determinisme en de detecteerbaarheid van hallucinaties verbetert, en of deze effecten generaliseren over verschillende modelarchitecturen.

Methodologie

De auteurs voerden twee onafhankelijke, vooraf geregistreerde gecontroleerde empirische studies uit waarbij de vier condities (traceSDD geciteerd, traceSDD ongeciteerd, Spec Kit, OpenSpec) werden vergeleken over twee verschillende frontier LLM's:

Studie 1: Gebruikte Claude Sonnet 4.6 met 20 benchmark Python-taken (N=20), wat 240 totale implementaties genereerde (3 runs per taak).
Studie 2: Gebruikte GLM-5-turbo met 50 nieuwe benchmark-taken verspreid over 8 software engineering domeinen, 3 moeilijkheidsgraden en 2 grootteklassen (N=50), wat 600 totale implementaties genereerde.

Experimentele Condities:

traceSDD (geciteerd): Hiërarchische REQ-XXX.Y.Z specs met verplichte inline citaties op niet-triviale regels.
traceSDD (ongeciteerd): Identieke specs aan de geciteerde conditie, maar zonder inline citaties (om het effect van het annotatiemechanisme te isoleren).
Spec Kit: Natieve proza-specs (user stories) zonder citatiemechanisme.
OpenSpec: Natieve capability-specs met externe trace YAML-bestanden.

Metrieken:

Output Determinisme: Gemeten via een Lexical Similarity Score (LSS) met behulp van Levenshtein Set Similarity op genormaliseerde, van commentaar ontkende code over onafhankelijke sessies.
Hallucinatie Detectie: Gemeten via een Traceability Detection Rate (TDR). Hallucinaties werden bewust geïnjecteerd (functies buiten de scope, ongeautoriseerde imports, over-engineering) met valse REQ-ID's. Detectie berustte op een "orphan-REQ check" (set-difference tussen geciteerde ID's en geldige spec-ID's).
Functionele Correctheid: Gemeten via de True Positive Rate (TPR) tegen grondwaarheid test-suites.
False Positive Rate (FPR): Frequentie van foutieve alarmen op correcte implementaties.

Belangrijkste Bijdragen

Eerste Cross-Model Vergelijking: Biedt de eerste gecontroleerde vergelijking van SDD citatie-disciplines over twee fundamenteel verschillende LLM-architecturen (Transformer/Constitutional AI vs. Autoregressief/Bidirectioneel), bestaande uit 70 taken en 840 implementaties.
Replicatie van de Citatie-Isolatie Bevinding: Bevestigt dat verplichte inline citaties de output-determinisme significant verminderen vergeleken met een identieke ongeciteerde conditie, een bevinding die standhoudt over beide modellen.
Uitgebreide Subgroep Analyse: Onthult dat de determinisme-straf het meest uitgesproken is voor gemakkelijke en kleine taken, en afneemt naarmate de taakcomplexiteit en -grootte toenemen.
Geautomatiseerde Hallucinatie Detectie: Demonstreert dat de orphan-REQ check in de geciteerde conditie een hoge detectiegraad (86–88%) bereikt met 0% fout-positieven, een capaciteit die niet wordt gehaald door Spec Kit of OpenSpec.

Belangrijkste Resultaten

1. Output Determinisme (RQ1)

Een consistente trade-off werd waargenomen: citatie vermindert determinisme.

Citatie Straf: De ongeciteerde conditie produceerde significant meer deterministische output dan de geciteerde conditie in beide modellen (Claude: $d = -0.76, p = 0.003$ ; GLM: $d = -0.72, p < 0.001$ ).
Framework Vergelijking:
- traceSDD (geciteerd) presteerde significant beter dan Spec Kit op het gebied van determinisme (Claude: $d = 0.47$ ; GLM: $d = 0.42$ ).
- traceSDD (geciteerd) presteerde niet significant beter dan OpenSpec (Claude: $d = 0.18$ ; GLM: $d = 0.14$ ).
- De ongeciteerde conditie behaalde consistent de hoogste determinisme, waarbij deze beide externe baselines overtrof met grote effectgroottes.
Subgroep Analyse: De determinisme-straf was het grootst voor gemakkelijke taken ( $d = -1.85$ ) en kleine taken ( $d = -0.95$ ), maar niet statistisch significant voor harde of grote taken. Dit suggereert dat variabiliteit in de plaatsing van citaties een groter deel van de totale variabiliteit vormt in simpelere taken.

2. Hallucinatie Detectie (RQ2)

Detectiegraad: Alleen de traceSDD (geciteerde) conditie maakte geautomatiseerde hallucinatie detectie mogelijk, met een score van 86.4% (Claude) en 88.0% (GLM) TDR.
Nul Detectie in Alternatieven: De ongeciteerde conditie (ondanks het gebruik van dezelfde gestructureerde spec), Spec Kit en OpenSpec behaalden allemaal 0% TDR. Dit bewijst dat detectie een annotatiemechanisme binnen de code vereist, en niet enkel de aanwezigheid van een gestructureerde specificatie.
False Positives: De FPR was 0.0% over alle checks in beide studies.
Functionele Correctheid: Alle condities behaalden 100% TPR, wat bevestigt dat de citatie-discipline zelf de functionele correctheid niet verslechtert.

Betekenis en Claims

Het paper stelt vast dat citatie-discipline in SDD frameworks een geprincipeerde trade-off inhoudt: verminderde output-determinisme in ruil voor geautomatiseerde hallucinatie detectie.

De Trade-off: De verplichte inline citaties introduceren lexicale variabiliteit (door de besluitvorming van het model over waar en hoe te citeren), wat de consistentie van code-generatie over sessies heen vermindert. Echter, ditzelfde mechanisme creëert een verifieerbare, geautomatiseerde controle (de orphan-REQ check) die scope creep en ongeautoriseerde functies detecteert met hoge precisie en nul fout-positieven.
Generaliseerbaarheid: De consistentie van de effectgroottes ( $d \approx -0.72$ ) en detectiegraad over twee verschillende architecturen (Claude en GLM) suggereert dat dit structurele eigenschappen zijn van het citatie-annotatiemechanisme en geen artefacten van een specifiek model.
Praktische Implicaties:
- Voor gereguleerde/hoog-risico domeinen (gezondheidszorg, financiële sector), adviseert het paper traceSDD met verplichte citaties, aangezien het unieke vermogen om hallucinaties te detecteren de gematigde kosten in determinisme weegt.
- Voor snelle prototyping waar verificatie secundair is, wordt de ongeciteerde REQ-formaat benadering aanbevolen, omdat deze de structurele verankering van de REQ-format behoudt (hogere determinisme dan baselines) zonder de citatie-overhead.
- Spec Kit wordt geïdentificeerd als de zwakste keuze op de gemeten dimensies (laagste determinisme, geen automatische detectie), hoewel de auteurs erkennen dat de workflow-voordelen ervan kunnen verschillen.

De auteurs concluderen dat hoewel citatie-discipline de determinisme vermindert, het een unieke, geautomatiseerde verificatielaag biedt die essentieel is voor productieomgevingen waar de correctheid van de specificatie cruciaal is. Toekomstig werk wordt gesuggereerd om hybride benaderingen te verkennen en de integratie van deze checks in CI/CD-pipelines.