🤖 AI

Specification-Based Code-Text-Code Reengineering for LLM-Mediated Software Evolution

Dit artikel stelt een specificatiegebaseerd Code2Text2Code-herontwerpkader voor dat semantische drift en gedragsinconsistenties in door LLM-gemedieerde software-evolutie mitigeert door broncode om te zetten in een neutrale tekstuele specificatie voor iteratieve verificatie voordat de doelcode wordt gegenereerd.

Oorspronkelijke auteurs: Oleg Grynets, Vasyl Lyashkevych, Arsen Dolichnyi, Roman Piznak, Taras Zelenyy, Volodymyr Morozov

Gepubliceerd 2026-05-26

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Oleg Grynets, Vasyl Lyashkevych, Arsen Dolichnyi, Roman Piznak, Taras Zelenyy, Volodymyr Morozov

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 probeert een complex, handgeschreven recept uit de keuken van een grootouder in Oekraïne uit de jaren 50 te vertalen naar een moderne, digitale receptenapp voor een slimme oven in 2024.

Als je een vertaler (een AI) gewoon vraagt "dit oude recept om te zetten in een nieuw een", krijgen ze misschien de woorden goed maar verprutsen ze het koken. Ze houden misschien vast aan een instructie voor een "houten lepel" terwijl de nieuwe oven een "digitale sensor" nodig heeft, of ze voegen per ongeluk een "geheime ingrediënt" toe dat niet in het origineel stond. Het resultaat ziet eruit als een recept, maar het kan je taart verbranden.

Dit artikel stelt een slimmere manier voor om deze vertaling te doen, niet alleen voor recepten, maar voor computersoftware. Ze noemen dit Code–Tekst–Code Herontwerp.

Hier is hoe het werkt, opgesplitst in eenvoudige stappen:

1. Het Probleem: De "Directe Vertaling" Valstrik

Meestal, wanneer mensen AI gebruiken om software van de ene taal naar de andere te veranderen (zoals van Python naar Java), doen ze een Code-naar-Code vertaling.

Het Risico: De AI kopieert misschien de stijl van de oude code in plaats van de betekenis. Het is als een gedicht woord voor woord vertalen en de emotie verliezen. De nieuwe code ziet er misschien correct uit, maar gedraagt zich anders, of mist verborgen regels waarop de oude code vertrouwde.

2. De Oplossing: De "Neutrale Vertaler" (De Tussenpersoon)

In plaats van rechtstreeks van Oude Code naar Nieuwe Code te springen, voegen de auteurs een tussenstap in: De Neutrale Tekst Specificatie.

Denk hierbij aan een gedetailleerde, platte-Nederlandse blauwdruk die beschrijft wat de software doet, zonder te vermelden hoe het in de oude taal was gebouwd.

Stap 1 (Code naar Tekst): De AI leest de oude code en schrijft een neutrale beschrijving. Het zegt dingen als: "Deze functie neemt een lijst met getallen, telt ze op en slaat het resultaat op in een database." Het negeert de specifieke programmeertrucs die in de oude code werden gebruikt.
Stap 2 (De Check): Mensen of andere tools controleren deze beschrijving om ervoor te zorgen dat deze perfect overeenkomt met het origineel. Hebben we een stap gemist? Hebben we er een nieuwe verzonnen?
Stap 3 (Tekst naar Code): De AI leest deze schone, neutrale beschrijving en schrijft de nieuwe code in de doeltaal. Omdat de AI niet meer naar de oude code kijkt, kopieert het niet per ongeluk de oude stijl. Het bouwt de nieuwe code precies zoals de blauwdruk beschrijft.

3. De "Veiligheidsnet" Hulpmiddelen

Het artikel legt uit dat dit niet alleen gaat over het schrijven van tekst; het gaat om het bouwen van een veiligheidssysteem rond het proces:

De "Feitencontroleur" (Retrieval): Voordat de AI iets schrijft, zoekt het feiten op in een bibliotheek met documenten, diagrammen en codefragmenten om zeker te zijn dat het niet giswerk doet. Het is alsof een chef-kok een kookboek controleert voordat het zout toevoegt.
De "Chunking" Strategie: Je kunt niet een hele bibliotheek boeken in één hap lezen. Het systeem breekt de code op in kleine, logische "stukken" (zoals hoofdstukken) zodat de AI niet in de war raakt of verbindingen mist.
De "Blauwdruk" (Grafieken & Ontologie): Het systeem bouwt een kaart (een grafiek) die laat zien hoe verschillende onderdelen van de software met elkaar verbonden zijn. Als de oude software een brug had tussen twee eilanden, moet de nieuwe software diezelfde brug hebben. Deze kaart helpt te meten of de vertaling succesvol was.

4. Succes Meten: Hebben We Iets Verloren?

Hoe weet je dat de nieuwe software hetzelfde is als de oude? De auteurs hebben een "Verliescalculator" ontwikkeld.
Stel je voor dat je meubels verplaatst van een oud huis naar een nieuw huis.

Structurele Behoud: Heb je alle kamers verplaatst? (Ja/Nee)
Interface Stabiliteit: Kun je de voordeur nog steeds op dezelfde manier openen? (Ja/Nee)
Totale Gelijkenis: Een score die aangeeft hoeveel van het oorspronkelijke "huis" de verhuizing heeft overleefd.

5. Wat Ze Vonden

De onderzoekers testten deze methode uit op vele verschillende soorten code (SQL-databases, webscripts, algemene programmering).

Het Resultaat: Het gebruik van de "Neutrale Tekst" tussenpersoon werkte beter dan het proberen om code direct te vertalen. Het verminderde fouten en zorgde ervoor dat de nieuwe code zich meer gedroeg volgens de oorspronkelijke intentie.
De Haken: Soms heeft de AI een mens nodig om een verwarrend deel van de oude code te verduidelijken. Het is nog niet volledig automatisch; het is een "mens-in-de-lus" proces.

Het Grote Plaatje

Dit artikel betoogt dat we software-updates niet moeten behandelen als een simpele "kopieer-plak" klus. In plaats daarvan moeten we het behandelen als herontwerp.

Oude Manier: "Hier is de oude code; geef me de nieuwe code." (Risicovol, ondoorzichtig).
Nieuwe Manier: "Hier is de oude code. Leg eerst uit wat het doet in plat Nederlands. Controleer die uitleg. Bouw dan de nieuwe code op basis van die uitleg." (Veilig, transparant en controleerbaar).

Kortom, ze leren AI om op te houden met het vertalen van woorden en te beginnen met het vertalen van betekenis, gebruikmakend van een duidelijke, neutrale blauwdruk om ervoor te zorgen dat niets verloren gaat in de warboel.

Technische Samenvatting: Specificatie-gebaseerde Code–Tekst–Code-herschikking voor door LLM-gemiddelde software-evolutie

1. Probleemstelling

Grote Taalmodellen (LLM's) worden steeds vaker ingezet voor software-migratie, refactorering en code-regeneratie. Directe Code-naar-Code-transformatie-approaches ondervinden echter aanzienlijke beperkingen. Deze omvatten:

Semantische Drift: Modellen kunnen oppervlakkige syntaxis behouden terwijl ze onderliggende bedrijfslogica veranderen of verborgen gedragswijzigingen introduceren.
Niet-idiomatische Output: Gegenereerde code kan constructen uit de brontaal behouden die ongepast zijn voor de doelomgeving.
Verlies van Traceerbaarheid: Er is vaak geen duidelijke link tussen de broncode, de interpretatie van het model en het gegenereerde artefact.
Contextuele Gaten: Directe vertaling houdt vaak geen rekening met data-afhankelijkheden, uitzonderingsbehandeling en niet-functionele aannames.

Het artikel betoogt dat door LLM's gemiddelde software-evolutie niet enkel als code-generatie moet worden beschouwd, maar als een gecontroleerd herschikkingsproces dat tussenliggende representatielagen vereist om semantische consistentie en structurele behoud te waarborgen.

2. Methodologie: Het Code–Tekst–Code Kader

Het voorgestelde kader introduceert een specificatie-gebaseerd Code–Tekst–Code herschikkingsmodel. De kern-transformatiestroom is gedefinieerd als:
$C_0 \rightarrow S_n \rightarrow C_1$
Waarbij $C_0$ de broncode is, $S_n$ een neutrale tekstuele specificatie is, en $C_1$ de gegenereerde doelcode is.

A. De Neutrale Tekstuele Specificatie ( $S_n$ )

In tegenstelling tot eenvoudige code-samenvatting, is $S_n$ een gestructureerd, verifieerbaar artefact dat is ontworpen om vast te leggen:

Programmagedrag, identificatoren en computationele stroom.
Voorwaarden, neveneffecten en data-afhankelijkheden.
Domeinspecifieke intentie zonder bias van de brontaalsyntaxis.
Het fungeert als een "semantische mediator" die scheidt wat de software doet van hoe het is geïmplementeerd.

B. Kennisrepresentatielaag

Het kader integreert meerdere representatielagen om traceerbaarheid en validatie te ondersteunen:

AST & Metadata-extractie: Gestructureerde extractie van feiten (functienamen, handtekeningen, afhankelijkheden) om het generatieproces te beperken en hallucinaties te verminderen.
Ontologie & Semantische Annotatie: Het mappen van tussentijdse representaties naar gestructureerde kennis (OWL/SKOS) om redenering en hergebruik te ondersteunen.
Grafische Representatie: Het gebruik van Code Property Graphs (CPG) om afhankelijkheden (oproepen, lezingen, schrijfsels) te volgen en transformatieverliezen te schatten.
Hybride Retrieval: Het combineren van vectorzoekopdrachten (voor semantische gelijkenis) met grafen-doorloop (voor structurele afhankelijkheden) en metadata-filtering om zowel de Code2Text- als de Text2Code-fasen te verankeren.

C. Pijplijnarchitectuur

De end-to-end pijplijn omvat:

Feitelijke Context-extractie: Het verzamelen van identificatoren en afhankelijkheden voordat de specificatie wordt gegenereerd.
Code2Text-generatie: Het creëren van de initiële neutrale specificatie met behulp van RAG en feitelijke context.
Iteratieve Validatie & Verfijning: Het vergelijken van de specificatie met de broncode om ontbrekend gedrag of overmatige aannames op te sporen.
Mens-in-de-Lus: Optionele correctie door experts voor ambigu bedrijfslogica of verborgen aannames.
Text2Code-generatie: Het genereren van doelcode op basis van de gevalideerde specificatie, waarbij een idiomatische implementatie in de doeltaal wordt gewaarborgd.
Doelverificatie: Het valideren van syntaxis, functionele equivalentie en interface-stabiliteit.
DBMS-feedback (voor SQL): Het gebruik van uitvoeringsgebaseerde validatie om dialect-specifieke correctheid te waarborgen.

D. Semantisch Bewuste Chunking

Het artikel benadrukt dat naïeve chunking semantische eenheden breekt. Het stelt een "ideale code-chunk" voor die wordt gedefinieerd door atomiciteit, zelf-parsbaarheid en semantisch bewustzijn, beoordeeld via metrieken zoals Boundary F1 en Chunk Certainheid.

3. Belangrijkste Bijdragen

Het artikel presenteert vijf primaire bijdragen:

Conceptuele Interpretatie: Het herformuleren van Code–Tekst–Code niet als een vertaalpijplijn, maar als een specificatie-gebaseerd herschikkingsproces waarbij de neutrale tekst een gecontroleerd kennisartefact is.
Pijplijnarchitectuur: Een uitgebreid systeem dat feitelijke extractie, iteratieve validatie, menselijke correctie en DBMS-ondersteunde feedback integreert.
Kennisrepresentatiemodel: Een unificerend model dat AST-metadata, ontologieën, grafische afhankelijkheden en neutrale tekst combineert om broncode, documentatie en gegenereerde artefacten te koppelen.
Experimentele Evaluatie: Een dataset die meerdere talen beslaat (Java, Python, C++, SQL-dialecten) en een evaluatieprotocol dat tussentijdse representaties vergelijkt (Pseudocode, Graph IR, Compiler IR, Natural Language IR).
Formele Schatting van Verlies: Een grafische formalisering om transformatieverliezen te kwantificeren met behulp van:
- Directionele Structurele Behoud ( $\alpha$ ): Het meten van behoud van bronafhankelijkheden.
- Reverse Compatibiliteit ( $\beta$ ): Het meten van de introductie van onnodige doelafhankelijkheden.
- Interface Behoud ( $\delta_{IO}$ ): Het waarborgen van input/output-stabiliteit.
- Totale Grafische Gelijkenis ( $S$ ): Een gewogen harmonisch gemiddelde van de bovenstaande.

4. Experimentele Resultaten

De auteurs voerden experimenten uit met een dataset van 1.000 scripts per taal over negen programmeertalen en vijf SQL-dialecten.

Vergelijking van Tussentijdse Representaties: Natural Language IR (de neutrale specificatie) toonde de sterkste praktische geschiktheid voor door LLM's gemiddelde transformatie in vergelijking met pseudocode, grafische IR of compiler-achtige IR.
Retrieval-evaluatie: Vectorretrieval bleek nauwkeuriger voor semantische relevantie, terwijl grafenretrieval lagere latentie bood voor navigatie van afhankelijkheden. Een hybride aanpak werd aanbevolen.
Documentatietransformatie: In TechDoc-naar-BusinessDoc-experimenten slaagden 22 van de 24 chunks de validatie. Falen betrof logische vervorming of weglating van reikwijdte, wat de noodzaak van validatielussen benadrukt.
Prompt Tuning: Met behulp van DSPy/MIPROv2 ontdekten de auteurs dat de originele, zorgvuldig beperkte baseline-prompt beter presteerde dan automatisch gegenereerde varianten. Dit suggereert dat voor beperkte herschikkingsopdrachten expliciete beperkingen (neutraliteit, structuur) belangrijker zijn dan prompt-complexiteit.
Grafische Metrieken: De formele metrieken slaagden erin structureel behoud en interface-stabiliteit te kwantificeren, en bieden een methode om "plausibele maar onjuiste" transformaties op te sporen.

5. Betekenis en Claims

Het artikel claimt dat specificatie-gebaseerde Code–Tekst–Code-herschikking een gecontroleerd, traceerbaar en monitorbaar alternatief biedt voor ondoorzichtige directe code-generatie.

Transparantie: Door de tussentijdse specificatie expliciet te maken, wordt de interpretatie van het model zichtbaar, controleerbaar en corrigeerbaar.
Kwaliteitscontrole: Het kader gaat verder dan lokale syntactische correctheid om semantische dekking, retrieval-verankering en structureel behoud te evalueren.
Intelligente Monitoring: De auteurs positioneren het kader niet alleen als een transformatietool, maar als een object van "intelligente monitoring", waarbij semantische consistentie en transformatieverliezen continu worden beoordeeld.
Herschikking versus Vertaling: Het werk stelt dat software-evolutie die door LLM's wordt gemiddeld, een verschuiving vereist van eenvoudige vertaling naar een meerlagig representatieproces dat code, technische documentatie, bedrijfsvereisten en grafische structuren omvat.

Het artikel concludeert dat hoewel de aanpak veelbelovend is, het zorgvuldige behandeling van chunking, retrieval-verankering en mens-in-de-lus-validatie vereist om risico's van semantische drift en hallucinaties te mitigeren, met name in hoog-risico domeinen zoals financiële of zorgsystemen.