🤖 AI

IACDM: Interactive Adversarial Convergence Development Methodology -- A Structured Framework for AI-Assisted Software Development

Dit artikel introduceert IACDM, een tool-agnostisch, achtfasenraamwerk dat is ontworpen om de verificatiekloof in door AI ondersteunde ontwikkeling te dichten door ongeverifieerde "vibe coding" te vervangen door een gestructureerd proces van diepgaande probleemontdekking, aanhoudend kennisbeheer en systematische adversariele kritiek.

Oorspronkelijke auteurs: Jasmine Moreira

Gepubliceerd 2026-05-01

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jasmine Moreira

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

Het Grote Probleem: "Vibe Coding" is een Valstrik

Stel je voor dat je een supersnelle, superslimme robotassistent hebt die volledige softwareprogramma's kan schrijven terwijl je alleen maar met hem praat. Je zegt: "Bouw me een bankapp," en de robot spuugt binnen seconden code uit. Dit heet "Vibe Coding."

Het paper betoogt dat dit, hoewel het geweldig klinkt, in feite gevaarlijk is.

De Illusie: Ontwikkelaars voelen alsof ze sneller werken.
De Realiteit: Ze werken eigenlijk langzamer, omdat ze later enorme fouten moeten herstellen.
Het Gevaar: Omdat de robot alleen maar het volgende woord raadt (zoals een zeer geavanceerde automatische tekstinvulling), weet hij niet of zijn code correct is. Hij weet alleen of de code er goed uitziet.

Het paper noemt dit de "Verification Gap" (Verificatiekloof). De robot kan zijn eigen werk niet controleren. Het is als een student die een essay schrijft, maar geen manier heeft om te weten of de feiten waar zijn, tenzij een leraar het nakijkt.

De Oplossing: IACDM (De "Architect & Inspecteur"-methode)

De auteur, Jasmine Moreira, stelt een nieuwe manier van werken voor die IACDM heet. In plaats van de robot gewoon te laten "viben" en code te schrijven, dwing je hem tot een strikt, 8-stapsproces waarbij hij zowel de Bouwer als de Kritische Beoordelaar is.

Denk eraan als het bouwen van een huis. Je zou niet zomaar tegen een aannemer zeggen: "Bouw me een huis," en dan verschijnen wanneer het klaar is. Je zou een blauwdruk hebben, een inspecteur en een reeks controlepunten.

Hier is hoe de 8 stappen werken, met eenvoudige analogieën:

Fase 0: De "Terugvertelling" (Probleemontdekking)

Voordat je één regel code schrijft, moet je ervoor zorgen dat jij en de robot het eens zijn over wat je bouwt.

De Analogie: Stel je voor dat je een op maat gemaakt taart bestelt. In plaats van alleen maar te zeggen "Ik wil een taart", vraag je de bakker om je precies uit te leggen wat hij denkt dat je hebt besteld.
De Truc: Als de bakker zegt: "Je wilt een chocoladetaart met aardbeien," maar jij wilde eigenlijk vanille, dan vang je de fout op voordat ze beginnen met bakken. Deze stap zorgt ervoor dat je niet het verkeerde ding bouwt.

Fase 1: De Blauwdruk (Architectuur)

Nu ontwerp je de structuur.

De Analogie: Het tekenen van de blauwdrukken voor het huis. Je bepaalt waar de muren komen, waar de deuren zijn en hoe de loodgieterswerkzaamheden zijn aangesloten.
De Regel: Je legt geen enkele baksteen (schrijft geen code) voordat de blauwdruk is goedgekeurd.

Fase 2: De "Red Team"-aanval (Adversariale Kritiek)

Dit is het meest unieke deel. De robot moet zijn eigen ontwerp aanvallen.

De Analogie: Stel je voor dat je een "Beveiligingsagent" en een "Loodgieter" huurt om naar je huisblauwdruk te kijken.
- De Beveiligingsagent probeert manieren te vinden waarop een inbreker binnen kan komen.
- De Loodgieter probeert te vinden waar de leidingen zouden kunnen barsten.
De Lenzen: Het paper gebruikt "Gespecialiseerde Lenzen" (zoals Beveiliging, Prestaties of Ethiek) om de robot te dwingen te zoeken naar specifieke soorten fouten. De robot mag niet zeggen: "Het ziet er goed uit!" Hij moet proberen zijn eigen ontwerp te breken.

Fase 3: Vereenvoudiging

Als de "Beveiligingsagent" een zwakke plek vindt, repareer je die niet zomaar; je herontwerpt de hele muur om deze eenvoudiger en sterker te maken.

De Analogie: Als een brugontwerp te ingewikkeld en wankel is, voeg je niet meer staal toe om het vast te houden; je herontwerpt de brug zodat deze eenvoudiger is en minder steun nodig heeft.

Fase 4: De Convergentiepoort

Je controleert: "Is het ontwerp stabiel?"

De Regel: Als het ontwerp te veel verandert tussen versies, blijf je werken. Als het stabiel is en de "Beveiligingsagent" geen kritieke aanvallen meer heeft, krijg je groen licht om te bouwen.

Fasen 5–7: Bouwen, Testen en Leren

Nu schrijf je eindelijk de code, test je deze en leer je van het proces.

De Analogie: Het leggen van de bakstenen, het controleren van de ramen en het opschrijven wat je hebt geleerd, zodat je het volgende huis nog beter kunt bouwen.

Waarom Dit Werkt (De "Geheime Ingrediënten")

Het paper maakt drie hoofdpunten over waarom deze methode beter is dan de robot gewoon te vragen om "snel te gaan":

Het Gereedschap Maakt Niet Uit: Het maakt niet uit of je de "beste" AI of de "goedkoopste" AI gebruikt. De robot is altijd een giswerk. Het proces (de poorten en controles) is wat het resultaat goed maakt, niet de robot zelf.
Kleine Happen: Vraag de robot niet om het hele huis in één gesprek te bouwen. Hij raakt in de war (zoals een mens die probeert een boek van 100 pagina's te onthouden). Verdeel het huis in kamers (modules) en bouw ze één voor één.
De "Terugvertelling" is Cruciaal: De grootste fout die mensen maken, is denken dat de robot hen begrijpt. De "Terugvertelling" (Fase 0) dwingt de mens om te beseffen: "Wacht, ik heb dat niet duidelijk uitgelegd," voordat er ook maar één regel code is geschreven.

De Conclusie

IACDM is een regelboek dat ons stopt met te snel op AI te vertrouwen. Het behandelt AI niet als een toverstaf die problemen direct oplost, maar als een krachtige maar gebrekkige assistent die een strenge menselijke supervisor, een duidelijke blauwdruk en een team van "kritische beoordelaars" nodig heeft om zijn werk te controleren voordat het ooit wordt gebruikt.

Zoals het paper zegt: "Een geconvergeerd ontwerp is geen voltooid ontwerp, maar een dat zeker klaar is om te evolueren." Het gaat om het bouwen van een fundament dat sterk genoeg is om te groeien, in plaats van een huis dat instort op het moment dat je erin trekt.

1. Het Probleem: De Verificatiekloof en "Vibe Coding"

Het paper identificeert een kritiek falend patroon in de wijdverbreide adoptie van door AI ondersteunde ontwikkeling (specifiek het "vibe coding"-fenomeen van het genereren van apps vanuit natuurlijke taal zonder verificatie). Ondanks het gebruik van geavanceerde Large Language Models (LLM's) zijn ervaren ontwikkelaars meetbaar trager en produceren ze minder veilige code dan verwacht.

Empirisch Bewijs:
- METR-studie (2025): Ontwikkelaars die AI-tools gebruikten, ondervonden een 19% vertraging in objectieve taakvoltooiing, ondanks een waargenomen snelheidswinst van 20%.
- Veiligheidsfalen: 10,3% van de door AI gegenereerde applicaties in een productiedemonstratie bevatte kritieke beveiligingsfouten (bijvoorbeeld verkeerd geconfigureerde Row Level Security), waarbij onderzoekers 303 kwetsbare eindpunten vonden over 170 projecten.
- Kwaliteit van Code: Longitudinale data toont een verschuiving naar copy-paste code en een daling in refactorering, wat leidt tot versnelde technische schuld.
Oorzaak: De Verificatiekloof. LLM's zijn stochastische generators die optimaliseren voor statistische plausibiliteit, niet voor semantische correctheid. Ze bezitten geen interne verificatiecapaciteit. Zonder externe tools of processen kan een LLM niet bepalen of zijn output correct is. Het paper stelt dat het proces de kwaliteit bepaalt, niet het specifieke AI-tool dat wordt gebruikt.

2. Methodologie: IACDM (Interactive Adversarial Convergence Development Methodology)

IACDM is een gestructureerd, tool-onafhankelijk raamwerk ontworpen om de verificatiekloof te dichten door Externe Verificatieagenten (VA) in te voeren bij discrete poorten. Het positioneert AI opnieuw van een passieve codegenerator naar een actief ontwerppartner dat afwisselt tussen generatieve en adversariële rollen.

Kernpilaren

Diepgaande Probleemontdekking: Het begrijpen van het probleemdomein voordat er een technische oplossing wordt geprobeerd.
Persistent Kennisbeheer: Het onderhouden van een gestructureerde externe repository (specs/) om contextvensterlimieten te overwinnen en continuïteit tussen sessies te waarborgen.
Systematische Adversariële Kritiek: Het gebruik van gespecialiseerde "lenzen" om ontwerpen aan te vallen voordat de implementatie plaatsvindt.

Het 8-fasenproces

De methodologie organiseert ontwikkeling in 8 fasen (0–7), met strikte instap/uitstap-poorten:

Fase 0: Probleemontdekking (HSA): Gebruikt Hiërarchische Semantische Analyse (HSA) om iteratief probleembegrip te construeren (Domein → Probleem → Elementen → Processen → Product). Het hanteert een teach-back-mechanisme waarbij de AI het probleem aan de mens uitlegt om semantische uitlijning te verifiëren. Uitstap-poort: Score ≥90/100.
Fase 1: Architectuur: Definieert modules, interfaces en technische contracten. Uitstap-poort: Ontwerprichtlijn.
Fase 2: Adversariële Kritiek: De AI treedt op als "Red Team" en valt de architectuur aan met 19 gespecialiseerde lenzen (7 Universeel, 8 Situatief, 4 Domeinoverdracht).
- Universele Lenzen: Aannames, Architecturaal, Implementeerbaarheid, Wetenschappelijk, Beveiliging, Prestaties, Regulatorisch.
- Domeinoverdracht Lenzen: Besturingstechniek, Speltheorie, Taalkunde, Werktuigbouwkunde (toegepast wanneer specifieke signalen worden gedetecteerd).
- Output: Een Dekkingsmatrix die bevindingen koppelt aan modules.
Fase 3: Vereenvoudiging: De AI verfijnt de architectuur om complexiteit te verminderen terwijl kritieke bevindingen worden opgelost. Uitstap-poort: Complexiteitsaudit.
Fase 4: Convergentiepoort: Valideert dat structurele wijzigingen minimaal zijn (<15% ten opzichte van de vorige versie) en dat alle kritieke problemen zijn opgelost.
Fase 5: Code-implementatie: Implementatie vindt plaats per module om contextefficiëntie te maximaliseren.
Fase 6: Tests: Verplicht testen tegen interfaces en handmatige validatie.
Fase 7: Post-Review: Systematisch leren en evolutie van de methodologie.

Het GA/VA-model

Generatieve Agent (GA): De LLM (produceert artefacten).
Verificatie Agent (VA): Kan Automatisch zijn (compilers, linters, tests) of Menselijk (operator).
Poorten: Discrete punten waar voortgang wordt geblokkeerd totdat de VA het artefact goedkeurt. Dit zorgt ervoor dat fouten worden gedetecteerd bij $t = gate_k$ in plaats van $t = production$.

3. Belangrijkste Bijdragen

Formalisering van de Verificatiekloof: Het paper biedt een theoretische en empirische basis voor waarom door AI ondersteunde ontwikkeling faalt zonder externe verificatie, en stelt dat modelcapaciteit invariant is ten opzichte van semantische waarheid.
Hiërarchische Semantische Analyse (HSA): Een nieuw protocol voor probleemontdekking dat vereisten behandelt als geconstrueerd in plaats van verkregen, gebruikmakend van een 5-niveau hiërarchie om semantische verankering af te dwingen.
Gespecialiseerd Lens-model: Een gestructureerd systeem voor adversariële kritiek dat "validatietheater" (AI die met de gebruiker instemt) voorkomt door het model te dwingen specifieke, niet-onderhandelbare perspectieven voor het vinden van fouten aan te nemen (bijvoorbeeld Speltheorie, Besturingstechniek).
Proces boven Tool: Demonstreert dat de methodologie tool-onafhankelijk is. Het werkt met elke LLM (Claude, GPT, Copilot) omdat het de procesarchitectuur adresseert, niet de interne gewichten van het model.
Granularisatiestrategie: Maximaliseert AI-contextefficiëntie ( $E = I_0/C$ ) door werk op te breken in kleine, hoog-cohesieve modules, waardoor het "lost in the middle"-fenomeen in lange contexten wordt voorkomen.

4. Resultaten en Validatie

Interne Validatie: De methodologie werd toegepast op 20+ projecten binnen een industriële O&O-inrichting (naam achtergehouden).
- Adoptie: Kleine projecten vereisten 1–2 iteraties van kritiek; grote/ complexe projecten vereisten 3–5.
- Uitkomst: Consistente toepassing over meerdere praktijkspecialisten resulteerde in robuuste ontwerpen die klaar waren voor implementatie.
Beschikbaarheid Tools: Per maart 2026 is de methodologie geïmplementeerd als VS Code-extensies (versus-claude, versus-copilot) met 36 onafhankelijke installaties buiten de oorspronkelijke instelling.
Beperkingen: Het paper erkent expliciet dat empirische validatie momenteel beperkt is tot één instelling (L1) en dat de kosten-batenanalyse van de poorten (L3) verdere meting vereist.

5. Betekenis en Toekomstig Werk

Epistemologische Verschuiving: IACDM transformeert softwareontwikkeling van een ondoorzichtig generatieproces naar een waarneembaar generatie-verificatie-correctiecyclus. Het maakt de "verificatiekloof" een beheersbare procesvariabele in plaats van een inherente modelfout.
SE 3.0 Positionering: Terwijl het opkomende "SE 3.0"-paradigma zich richt op het bouwen van AI-systemen die beter kunnen redeneren, stelt IACDM dat een mens-in-de-lus processtructuur de directe, noodzakelijke oplossing is. Het zorgt ervoor dat, zelfs naarmate modellen verbeteren, menselijke verificatieautoriteit de bottleneck voor kwaliteit blijft.
Onderzoeksmogelijkheden: Het paper schetst specifieke onderzoeksrichtingen, waaronder:
- Het valideren van het "teach-back"-mechanisme als een onafhankelijk foutdetectietool.
- Het meten van de correlatie tussen gestructureerde poorten en productiedefectpercentages.
- Het bepalen van het optimale "granularisatiepunt" dat AI-contextefficiëntie afweegt tegen menselijke cognitieve belasting.

Conclusie: IACDM biedt een gedisciplineerd raamwerk om AI in te zetten voor softwareontwikkeling door het onvermogen van het model tot zelfverificatie te erkennen. Door adversariële kritiek, diepgaande probleemontdekking en externe verificatiepoorten af te dwingen, streeft het ernaar de "vibe coding"-valkuil te elimineren en veilige, robuuste en architectonisch sound software te produceren.