LLM-Assisted Repository-Level Generation with Structured Spec-Driven Engineering

Dit artikel stelt Gestructureerde Specificatie-gedreven Engineering (SSDE) voor, een paradigma dat gestructureerde specificaties gebruikt om de ambiguïteit en kwaliteitsbeperkingen van prompts in natuurlijke taal te overwinnen, waardoor hoogwaardige, verifieerbare codegeneratie op repository-niveau mogelijk wordt.

De kern

Stel je voor dat je een zeer getalenteerde, maar licht afwezige, leerlingkok probeert te leren hoe je een enorme, complexe banketmaaltijd voor een hele stad bereidt.

Het Probleem: De "Vage Opdracht"
Op dit moment, als je een top-tier AI (de leerling) vraagt om code te schrijven voor een volledig softwaresysteem, geef je het meestal gewoon een lange beschrijving in natuurlijke taal, zoals: "Maak een website waar mensen vergaderingen kunnen boeken." Dit is alsof je de kok vertelt: "Maak een heerlijke maaltijd."

Het artikel stelt dat de AI, hoewel uitstekend in het snijden van een enkele ui (het schrijven van een kleine functie), de weg kwijtraakt wanneer het wordt gevraagd om de hele banketmaaltijd te bereiden (een volledige software-repository). Natuurlijke taal is te vaag. De AI kan een verkeerde gok maken, een stap vergeten, of een gerecht creëren dat er goed uitziet maar niet goed smaakt. Erger nog, omdat de instructies vaag waren, is het moeilijk om te bewijzen waarom de maaltijd mislukt is.

De Oplossing: Het "Gestructureerde Receptenboek"
De auteurs stellen een nieuwe werkwijze voor die Gestructureerde Specificatie-gedreven Engineering (SSDE) wordt genoemd. In plaats van een vage conversatie, stellen ze voor om de AI een strikt, gestructureerd "receptenboek" te geven.

In dit artikel gebruiken ze twee soorten gestructureerde recepten:

1. Gherkin Specificaties: Denk hierbij aan "Als-Dan" testcases. In plaats van te zeggen "Laat het werken", schrijf je: "ALS een gebruiker op 'Boek' klikt, DAN moet de kamer worden gemarkeerd als 'Bezet'." Het is een checklist van exacte gedragingen.
2. Domeinmodellen: Dit zijn als architecturale blauwdrukken of een kaart van de ingrediënten. Ze tonen hoe verschillende onderdelen van het systeem (zoals "Gebruikers", "Kamers" en "Datums") met elkaar verbonden zijn.

Het Experiment: De Proeverij
De onderzoekers zetten een pilotstudie op. Ze traden op als hoofdkoks en gaven vijf verschillende AI-modellen (de leerlingkokken) de taak om de "business logica" (de kookregels) te bouwen voor drie verschillende softwaresystemen.

Ze testten verschillende combinaties:

• De Controlegroep: Alleen de vage beschrijving in natuurlijke taal.
• De Testgroepen: De vage beschrijving PLUS het gestructureerde "receptenboek" (de blauwdrukken en de "Als-Dan" checklists).

De Resultaten: Structuur Wint
De bevindingen waren duidelijk:

• Betere Nauwkeurigheid: Wanneer de AI het gestructureerde "receptenboek" (de blauwdrukken en checklists) had, maakte het veel minder fouten dan toen het alleen de vage beschrijving had.
• De "Blauwdruk" Boost: Het geven van de AI van de specifieke code-ondertekeningen (de exacte lijst van ingrediënten en gereedschappen) samen met de blauwdrukken hielp het meest. Het was alsof je de kok niet alleen het recept gaf, maar ook het exacte merk bloem en de specifieke maat van de pan die moest worden gebruikt.
• Nog Ruimte om te Groeien: Hoewel de gestructureerde aanpak veel beter was, maakte de AI nog steeds enkele fouten. De onderzoekers ontdekten echter dat meer dan 70% van deze fouten simpele, detecteerbare fouten waren — dingen zoals het refereren naar een variabele die niet bestaat, of het maken van een Python-syntaxisfout. Deze hoeven zelfs geen test-oracle (d.w.z. het uitvoeren van de code met voorbeeldinvoer om te zien wat er uitkomt): een standaard compiler of linter zou ze oppikken.

De Toekomstige Routekaart
Het artikel stelt dat we, om dit perfect te laten werken, het volgende moeten doen:

1. Een Feedbacklus Toevoegen: In plaats van de AI slechts één keer te vragen, moeten we het de code laten schrijven, controleren tegen het "receptenboek", en automatisch zijn eigen fouten laten herstellen.
2. Betere Datasets Bouwen: We hebben meer voorbeelden nodig van deze gestructureerde receptenboeken om de AI beter te trainen.
3. Veranderingen Aanhouden: Echt software verandert voortdurend. We moeten de AI leren hoe het slechts één onderdeel van de banketmaaltijd moet updaten (zoals het vervangen van het dessert) zonder de hele maaltijd te bederven.

De Conclusie
Het artikel concludeert dat als we stoppen met het behandelen van AI als een toverstaf die werkt op vage wensen, en beginnen met het behandelen ervan als een bekwame werknemer die een strikt, gestructureerd blauwdruk volgt, we het kunnen krijgen om volledige softwaresystemen betrouwbaar te bouwen. Het verandert de AI van een "creatieve gokker" in een "precieze bouwer".

Technische samenvatting

Technische Samenvatting: LLM-ondersteunde Generatie op Repository-niveau met Gestructureerde Spec-gedreven Engineering

Probleemstelling

Hoewel Large Language Models (LLM's) hoge bekwaamheid tonen bij het genereren van code op functie- of bestandsniveau, neemt hun betrouwbaarheid aanzienlijk af bij schaling naar repository-niveau systemen. Huidige workflows die uitsluitend vertrouwen op prompts in natuurlijke taal lijden onder inherente ambiguïteit, waardoor communicatie "verliesgevend" wordt en de generatie van verifieerbare outputs (bijvoorbeeld softwaretests) wordt gehinderd. Het simpelweg verhogen van de verbaaliteit van instructies in natuurlijke taal lost het fundamentele gebrek aan precisie niet op dat vereist is voor betrouwbare, grootschalige codegeneratie en -verificatie. De auteurs stellen dat een verschuiving van ongestructureerde natuurlijke taal naar gestructureerde specificaties noodzakelijk is om betrouwbare, verifieerbare en hoogwaardige generatie op repository-niveau mogelijk te maken.

Methodologie: Gestructureerde Spec-gedreven Engineering (SSDE)

Het artikel introduceert Gestructureerde Spec-gedreven Engineering (SSDE), een paradigma waarbij gestructureerde artefacten (in plaats van vrije vorm natuurlijke taal) dienen als primaire input om LLM-agenten te sturen. De auteurs voerden een pilotstudie uit om de haalbaarheid van deze visie te onderzoeken.

Experimentele Opzet

• Taak: Generatie van Model-View-Controller (MVC) businesslogica (specifiek Python-controllers) voor drie bestaande softwaresystemen: Symboleo, CheECSEManager en MeetingGroups.
• Modellen: Vijf LLM's werden geëvalueerd, variërend van open-source (Qwen 3, Llama 3.2) tot gesloten-bron (Claude Sonnet 4.5, GPT 5.1, GPT 5 Nano) modellen van verschillende groottes.
• Input-configuraties: De studie vergeleek vier soorten contextuele inputs die aan de LLM werden verstrekt naast een controller-sjabloon:
  1. Specificatie in Natuurlijke Taal: Vrije vorm beschrijvingen van systeemdoel en beperkingen.
  2. Gherkin-specificatie: Gestructureerde, uitvoerbare scenario's die systeemgedrag definiëren.
  3. Domeinmodel: Abstracte softwaremodellen (Umple of Ecore) die domeinconcepten en relaties vastleggen.
  4. Signatuurmodel: De gegenereerde klassen- en functiesignaturen (API) afgeleid van de domeinmodellen.
• Evaluatie:
  • Kwantitatief: Een door mensen geverifieerde Python-unit test-suite (gekoppeld aan Gherkin-scenario's) werd uitgevoerd tegen de gegenereerde controllers. De primaire metriek was de Test Pass Rate (TPR).
  • Kwalitatief: Handmatige inspectie van gegenereerde code om terugkerende foutpatronen en codekwaliteitsattributen te identificeren.
  • Herhaling: Elke configuratie werd 10 keer uitgevoerd per LLM om rekening te houden met stochastische bias.

Belangrijkste Resultaten

De pilotstudie leverde enkele kritieke bevindingen op over de effectiviteit van gestructureerde inputs:

1. Superioriteit van Gestructureerde Inputs: Het toevoegen van enige vorm van gestructureerde specificatie (Gherkin, Domeinmodel of Signatures) verbeterde de outputkwaliteit aanzienlijk in vergelijking met de baseline van uitsluitend het gebruik van Specificaties in Natuurlijke Taal.
2. Gherkin Potentieel: Hoewel Gherkin-specificaties gecombineerd met modellen aanvankelijk een iets lagere gemiddelde TPR toonden (6,8% lager) en een hogere variantie dan combinaties met natuurlijke taal, presteerden ze beter dan natuurlijke taal in 14 van de 30 specifieke combinaties. De auteurs wijzen op potentieel voor deze aanpak om natuurlijke taal te overtreffen met verdere verfijning.
3. Waarde van Signatures: Het verstrekken van de signatures (API) van de model-laag, gegenereerd vanuit domeinmodellen, bleek zeer effectief. Deze configuratie verbeterde de gemiddelde TPR met +7,82% en verlaagde de standaardafwijking met -2,47% in vergelijking met het gebruik van ruwe domeinmodellen, wat suggereert dat LLM's baat hebben bij expliciete API-definities boven abstracte model-syntax.
4. Foutanalyse: Meer dan 70% van de testfouten werd veroorzaakt door fouten die detecteerbaar zijn via statische code-analyse (bijvoorbeeld het aanroepen van niet-bestaande API's, typefouten in gegevens, ongeldig geverifieerde beperkingen). Dit geeft aan dat een significant deel van de generatiefouten structureel is in plaats van logisch, waardoor ze vatbaar zijn voor automatische correctie.
5. Modelprestaties: Claude Sonnet 4.5 kwam naar voren als de beste performer, met TPR's van meer dan 80% in verschillende configuraties. Echter, hoge standaardafwijkingen over de runs benadrukten de stochastische aard van LLM's, waarbij specifieke fouttypen consequent door gegenereerde controllers worden doorgegeven.

Belangrijkste Bijdragen

• Voorstel van SSDE: Het artikel introduceert Gestructureerde Spec-gedreven Engineering als een haalbaar paradigma om de kloof te overbruggen tussen hoge-level vereisten en codegeneratie op repository-niveau, door gebruik te maken van de verifieerbaarheid van gestructureerde artefacten.
• Empirische Haalbaarheidsstudie: De auteurs leveren de eerste pilotstudie die aantoont dat gestructureerde inputs (Gherkin, Domeinmodellen, Signatures) de kwaliteit van door LLM gegenereerde code op repository-niveau tastbaar kunnen verbeteren in vergelijking met prompts in natuurlijke taal.
• Identificatie van Foutpatronen: De studie categoriseert faalmodi, waarbij blijkt dat het merendeel van de fouten structureel en detecteerbaar is, wat wijst op een duidelijke weg voor automatische feedbackloops.
• Onderzoeksroadmap: Het artikel schetst een concreet pad voor de toekomst voor het vakgebied, met focus op drie pijlers:
  1. Verbetering van Outputkwaliteit: Implementatie van feedbackloops met behulp van statische analyse en dynamische testen om LLM's in staat te stellen structurele fouten zelf te corrigeren.
  2. Evalueren van Real-world Impact: Voorbijgaan aan generatie in één keer om agentische workflows, token-kosteneffectiviteit en netto productiviteitswinst te evalueren (rekening houdend met de inspanning om gestructureerde specificaties te onderhouden).
  3. Toepasbaarheid: Ontwikkelen van technieken voor partiële repository-updates om continue evolutie te hanteren en het integreren van SSDE met diverse modelleringstools en representaties van de fysieke wereld.

Betekenis en Claims

Het artikel stelt dat SSDE een tastbaar pad biedt naar hoogwaardige, verifieerbare codegeneratie op repository-niveau. Door te verschuiven van ambiguïteit in natuurlijke taal naar gestructureerde specificaties, maakt de aanpak gebruik van decennia aan software-engineeringkennis (bijvoorbeeld Model-Driven Engineering, Gherkin) om LLM's te sturen.

De auteurs betogen dat hoewel LLM's momenteel worstelen met systemen op grote schaal, de integratie van gestructureerde specificaties codegeneratie transformeert van een "black box"-proces naar een proces dat verifieerbaar en onderhoudbaar is. De studie suggereert dat het merendeel van de huidige generatiefouten geen onoverkomelijke logische gaten zijn, maar eerder structurele inconsistenties die kunnen worden opgelost via automatische feedbackmechanismen. Uiteindelijk beoogt SSDE de manuele engineeringlast te verminderen door effectieve mens-computer samenwerking te bevorderen, waarbij ingenieurs optreden als architecten van specificaties en LLM's de vertaling naar implementatie verzorgen.