🤖 AI

Specification Portability Across LLM Development Agents: Cross-Agent Compatibility in Specification-Driven Software Migration

Dit artikel toont aan dat specificaties gegenereerd door de ene AI-agent voor Oracle-naar-PostgreSQL-migratie vaak niet effectief overdraagbaar zijn naar andere agenten, wat een significante agent-afhankelijke degradatie in de kwaliteit van de implementatie onthult en de noodzaak benadrukt van expliciete strategieën zoals retrieval-augmented ingestie om cross-agent compatibiliteit in software engineering-workflows te waarborgen.

Oorspronkelijke auteurs: Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

Gepubliceerd 2026-08-24

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

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

In de moderne wereld van softwarecreatie is een nieuw soort werknemer toegetreden aan het team: het grote taalmodel. Dit zijn krachtige computerprogramma's die getraind zijn op enorme hoeveelheden tekst en code, in staat om een beschrijving van een taak te lezen en de instructies te schrijven die een computer nodig heeft om deze uit te voeren. Naarmate deze tools gebruikelijker worden, verschuift de focus van ontwikkelaars van simpelweg vragen om code te schrijven naar het geven van gedetailleerde blauwdrukken, ook wel specificaties genoemd. Deze specificaties fungeren als operationele gidsen, die het model precies vertellen wat het moet bouwen, hoe het zich moet gedragen en welke regels het moet volgen. Deze benadering, genaamd specificatiegestuurde ontwikkeling, belooft de creatie van software betrouwbaarder en gestructureerder te maken. Er is echter een kritische vraag ontstaan nu teams beginnen met het gebruik van meerdere verschillende modellen om een enkel systeem te bouwen: als het ene model een perfect blauwdruk schrijft, zal een ander model dan in staat zijn om het te lezen en hetzelfde te bouwen? De aanname was dat een goed plan een goed plan is, ongeacht wie het leest, maar de realiteit van hoe deze machines informatie interpreteren is veel complexer.

Onderzoekers bij EPAM Systems besloten deze aanname te testen door softwaremigratie te behandelen als een gecontroleerd experiment. Ze kozen voor een specifieke, moeilijke taak: het migreren van databasecode van het ene systeem, Oracle, naar het andere, PostgreSQL. Deze twee systemen spreken vergelijkbare talen maar hebben verschillende dialecten, wat een precieze vertaling van logica, datatypen en functies vereist. Het team stelde eerst een nulmeting vast door één enkel model een specificatie te laten genereren en vervolgens diezelfde specificatie direct te gebruiken om de nieuwe code te schrijven. Dit werkte redelijk goed; van meer dan duizend bronbestanden genereerde het systeem succesvol meer dan 600, en bijna 400 van die nieuwe scripts draaiden correct in de doelomgeving. Dit bewees dat de methode van het gebruiken van een tussenstap in de vorm van een specificatie levensvatbaar was. Maar de echte test kwam toen ze een tweede, ander model in de mix introduceerden.

De onderzoekers creëerden een scenario waarin één model, zoals Amazon Kiro, een specificatie zou schrijven, en vervolgens een totaal ander model, zoals Google Gemini of GitHub Copilot, dat document zou ontvangen om de code te genereren. Ze wilden zien of het tweede model het plan van het eerste model kon begrijpen zonder kwaliteitsverlies. De resultaten waren opmerkelijk en verrassend. De omvang van de specificatie bleek irrelevant voor de uitkomst. Het ene model produceerde een massief, gedetailleerd document met bijna 1.600 regels tekst, terwijl een ander een beknopte versie produceerde van slechts ongeveer 200 regels. Toch voorspelde de lengte van het document niet hoe goed de code zou werken. Sterker nog, de belangrijkste bevinding was dat de oorsprong van de specificatie enorm veel uitmaakte. Wanneer Google Gemini een specificatie kreeg die door Amazon Kiro was geschreven, stortte de kwaliteit van de resulterende code in. De nieuwe scripts werkten niet, bevatten syntactische fouten en leken totaal niet op het beoogde doel. Dit falen was geen eenmalige glitch; de onderzoekers herhaalden het experiment en zagen dezelfde dramatische daling in prestaties, wat bevestigde dat de twee modellen er simpelweg niet in slaagden om het eens te worden over de interpretatie van dezelfde set instructies.

Deze incompatibiliteit was echter niet universeel, wat een laag van nuance aan de ontdekking toevoegde. Terwijl Gemini diep worstelde met de specificaties van Kiro, ging GitHub Copilot veel beter om met dezelfde vreemde documenten en presteerde soms zelfs even goed met hen als met de eigen documenten. Dit suggereerde dat het probleem niet was dat vreemde plannen inherent slecht waren, maar dat verschillende modellen verschillende manieren hebben om tekst te lezen en te begrijpen. Om dit aan te pakken, testte het team verschillende manieren om de kloof te overbruggen. Ze probeerden de vreemde specificaties te herschrijven naar een nieuw formaat dat het ontvangende model wellicht de voorkeur zou geven, en ze probeerden de tekst te comprimeren om deze korter te maken. Het herschrijven hielp Gemini aanzienlijk en bracht de prestaties terug naar een bruikbaar niveau, maar het comprimeren van de tekst bood geen echt voordeel. De meest veelbelovende strategie betrof een techniek genaamd retrieval-augmented generation. In plaats van de volledige specificatie in één keer aan het model te voeren, gaven de onderzoekers het model een hulpmiddel om door het document te zoeken en alleen de specifieke delen eruit te halen die het nodig had voor de huidige taak. Deze aanpak won niet op elk enkel aspect, maar het was de enige methode die een consistent sterke balans bood tussen prestaties voor zowel de worstelende als de succesvolle modellen.

De studie concludeert dat in een wereld waar software wordt gebouwd door een team van verschillende kunstmatige intelligentie-agenten, een specificatie niet kan worden beschouwd als een neutraal, universeel document. Een plan geschreven door de ene agent is niet automatisch een geldige instructieset voor een andere. De effectiviteit van de code hangt sterk af van de specifieke relatie tussen het model dat het plan schreef en het model dat de software bouwt. Als een team één agent vervangt voor een andere, kunnen zij niet simpelweg aannemen dat de bestaande blauwdrukken zullen werken; zij moeten mogelijk de taal van het plan aanpassen of veranderen hoe de nieuwe agent toegang krijgt tot de informatie. Het onderzoek suggereert dat de toekomst van multi-agent software engineering een nieuwe focus zal vereisen op hoe specificaties worden gestructureerd en geleverd, om ervoor te zorgen dat de kennis die in een plan besloten ligt, daadwerkelijk begrepen kan worden door de machine die de taak heeft om het te bouwen.

Technisch overzicht: Specificatie-portabiliteit tussen LLM-ontwikkelingsagenten

1. Probleemstelling

Het artikel behandelt een kritieke interoperabiliteitskloof in opkomende multi-agent software engineering (SDE) workflows. Naarmate Large Language Models (LLM's) transformeren van prompt-gebaseerde assistenten naar autonome agenten die code genereren op basis van specificaties, rijst een nieuwe vraag: Is een specificatie die door de ene LLM-agentomgeving is gemaakt, betrouwbaar consumeerbaar door een andere?

Huidig onderzoek richt zich op single-agent prestaties, contextretrieval of vereistenverduidelijking. Het blijft echter empirisch onduidelijk of een specificatie gegenereerd door Agent A (bijv. Amazon Kiro) zijn operationele effectiviteit behoudt wanneer deze wordt geconsumeerd door Agent B (bijv. Google Gemini) om de doelcode te produceren. De auteurs hypothetiseren dat specificaties geen "agent-neutrale" artefacten zijn; hun effectiviteit kan aanzienlijk degraderen afhankelijk van de oorsprong van de specificatie en de ingestiestrategie die door de implementatie-agent wordt gebruikt.

2. Methodologie

De studie maakt gebruik van een gecontroleerd, twee-fasen experimenteel ontwerp met een Oracle-naar-PostgreSQL database migratie als de transformatietaak. Dit domein is gekozen omdat het het behoud van complexe applicatiesemantiek vereist bij het vertalen van domeinspecifieke constructen (procedurele logica, triggers, datatypen).

Fase 1: Specificatie-gestuurde Migratie-pipeline

Taak: Een specificatie-eerst pipeline werd geëvalueerd op 1.006 PL/SQL bronbestanden.
Proces: De broncode werd gedecomposeerd in database-objecten. Een agent genereerde een intermediaire tekstuele specificatie, die vervolgens werd gebruikt om de PostgreSQL-implementatie af te leiden.
Resultaat: 623 bestanden werden succesvol geregenereerd, en 380 daarvan werden succesvol uitgevoerd in PostgreSQL 16. Dit stelde de haalbaarheid van de aanpak vast, maar testte nog niet de cross-agent transfer.

Fase 2: Cross-Agent Compatibiliteitsexperimenten

Dataset: 1.802 Oracle-scripts met bijbehorende PostgreSQL-implementaties.
Geëvalueerde Agenten: Amazon Kiro, Google Gemini (via Antigravity), GitHub Copilot (via Spec Kit), Claude Code, en Cursor.
Experimentele Condities:
1. Native Baseline: Elke agent genereerde zijn eigen specificatie en implementatie.
2. Cross-Agent Transfer: Specificaties gegenereerd door één agent werden gevoed aan een andere (bijv. Kiro-spec $\to$ Gemini-implementatie).
3. Adaptatiestrategieën: Om potentiële degradatie te mitigeren, werden drie strategieën getest op vreemde specificaties:
  - Rewriting (Herschrijven): De implementatie-agent herschrijft de vreemde specificatie naar zijn voorkeursformaat voordat er gecodeerd wordt.
  - Compression (Compressie): Het samenvatten van de vreemde specificatie om de lengte te reduceren.
  - Retrieval-Augmented Generation (RAG): De agent heeft toegang tot de vreemde specificatie via retrieval-tools in plaats van de volledige tekst direct te incasseren.

Evaluatiemetrieken

De studie maakte gebruik van een multidimensionale metriekset om lexicale, syntactische, structurele en operationele kwaliteit te onderscheiden:

Token F1: Token-niveau gelijkenis.
Exact Match: Percentage outputs identiek aan het doel.
SQL Syntax Validity: Geldigheid van de gegenereerde SQL (met behulp van sqlglot).
AST Exact Match & Mean Similarity: Structurele gelijkenis van Abstract Syntax Trees.
Immediate Runnability: Percentage scripts dat zonder handmatige aanpassing uitvoerbaar is (genoteerd als een ondergrens vanwege beperkingen in de testomgeving).

3. Belangrijkste Resultaten

A. Specificatiegrootte is geen voorspeller van kwaliteit

In tegenstelling tot de aanname dat meer gedetailleerde specificaties betere code opleveren, vond de studie geen correlatie tussen de lengte van de specificatie en de kwaliteit van de implementatie.

Kiro genereerde de grootste specificaties (~1.597 regels).
Gemini genereerde aanzienlijk kleinere specificaties (~193 regels).
Ondanks het verschil in omvang produceerden de grotere Kiro-specificaties niet universeel superieure code over alle agenten of metrieken heen.

B. Asymmetrische en Agent-afhankelijke Degradatie

Cross-agent transfer produceerde zeer variabele resultaten, wat bevestigt dat specificatie-portabiliteit directioneel is ( $C_{i \to j} \neq C_{j \to i}$ ).

Kritiek Falen: Wanneer Gemini direct een door Kiro gegenereerde specificatie consumeerde, stortte de prestatie in.
- Token F1 daalde naar 0.035 (vs. 0.73 native).
- SQL Syntax Validity daalde naar 2.33% (vs. 45.54% native).
- AST Mean Similarity daalde naar 0.015.
- Dit falingspatroon werd gereproduceerd in een tweede onafhankelijke run, wat willekeurige nondeterminisme uitsluit.
Stabiliteit in andere paren: Andere combinaties (bijv. Copilot die Kiro-specificaties consumeert) bleven relatief stabiel of vertoonden gemengde verbeteringen, wat aangeeft dat degradatie geen universele wet is maar specifiek is voor de koppeling tussen agent en specificatie.

C. Effectiviteit van Adaptatiestrategieën

Rewriting: Verbeterde de prestaties van Gemini aanzienlijk bij het consumeren van Kiro-specificaties, wat suggereert dat de representatievorm (niet alleen de inhoud) een primaire bron van incompatibiliteit is. Deze strategie was minder effectief voor Copilot.
Compression: Bood geen universeel voordeel; eenvoudige reductie van de lengte loste incompatibiliteit niet op.
Retrieval-Augmented Ingestion (RAG): Hoewel RAG niet elke enkele metriek domineerde, was het de enige strategie die op de Pareto-fronten verscheen voor zowel Gemini als Copilot bij het afhandelen van vreemde specificaties. Dit identificeert RAG als de meest robuuste algemene trade-off strategie onder de geteste alternatieven.

4. Belangrijkste Bijdragen

Empirisch Bewijs van Niet-Portabiliteit: Het artikel levert het eerste gecontroleerde empirische bewijs dat specificaties gegenereerd in de ene LLM-omgeving niet automatisch effectief zijn in een andere, wat de aanname van agent-neutrale intermediaire artefacten uitdaagt.
Multidimensionaal Evaluatiekader: De studie introduceert een uitgebreide evaluatiesuite (Token F1, AST-gelijkenis, uitvoerbaarheid) specifiek voor cross-agent specificatie-transfer, reikend verder dan eenvoudige codegeneratie-benchmarks.
Analyse van Adaptatiestrategieën: Het evalueert systematisch rewriting, compressie en RAG, en identificeert dat representatie-adaptatie (rewriting) en selectieve toegang (RAG) effectiever zijn dan eenvoudige inhoudsreductie.
Voorstel voor een Formeel Model: De auteurs stellen een model voor waarbij de implementatiekwaliteit $Q_{code}$ een functie is van de oorsprong van de specificatie ( $A_g$ ), de implementatie-agent ( $A_i$ ), de ingestiestrategie ( $I_s$ ) en de context ( $C$ ), waarbij onderscheid wordt gemaakt tussen kennisbehoud en operationele interpretatiebehoud.

5. Betekenis en Claims

Het artikel claimt bescheiden dat de bevindingen empirisch en contextspecifiek zijn, beperkt tot de geëvalueerde agenten, datasets en metrieken. Het claimt niet dat vreemde specificaties universeel inferieur zijn, maar wel dat hun effectiviteit agent-afhankelijk is.

Primaire Betekenis:

Workflow Implicaties: In heterogene multi-agent SDD workflows moeten specificaties niet worden behandeld als statische, uitwisselbare artefacten. Het overdragen van een specificatie tussen agenten kan expliciete adaptatie vereisen (bijv. rewriting of RAG) om implementatie-degradatie te voorkomen.
Ontwerprichtlijnen: De resultaten motiveren de ontwikkeling van gestructureerde specificatie-representaties (het scheiden van kennis, representatie, afhankelijkheden en granulariteit) en agent-specifieke weergaven van specificaties.
Toekomstige Richting: De studie suggereert dat retrieval-gebaseerde toegang tot specificaties een robuuste strategie is voor onbekende agent-koppelingen, maar dat verder onderzoek nodig is naar dependency-aware retrieval en gestructureerde specificatiemodellen om het portabiliteitsprobleem volledig op te lossen.

De auteurs concluderen dat "specificatie-portabiliteit" een openstaand probleem is dat expliciete aandacht vereist voor de manier waarop informatie wordt gestructureerd, overgedragen en geïnterpreteerd tussen verschillende LLM-ontwikkelingsomgevingen.