Tientallen AI-specialisten met bewust tegengestelde persoonlijkheden werken samen aan hetzelfde project. Niet om consensus te bereiken — maar om elke blinde vlek te elimineren.
van IT-projecten faalt
Niet door slechte code — maar door verkeerde aannames in de analysefase die niemand ter discussie stelde.
duurder dan begroot
Omdat architectuurbeslissingen door één persoon werden genomen, zonder tegenspraak of alternatieve scenario's.
van bugs ontstaat in design
Pas ontdekt tijdens testing of productie — wanneer het herstellen 100× duurder is dan voorkomen.
De oorzaak is steeds dezelfde: één team, één perspectief, geen ingebouwde tegenspraak. Fouten worden pas laat ontdekt omdat niemand de rol heeft om actief te zoeken naar wat er mis kan gaan.
Tientallen AI-specialisten met bewust tegengestelde persoonlijkheden werken samen aan hetzelfde project. Niet om het eens te worden — maar om elke aanname te toetsen, elk risico te vinden, elke beslissing vanuit meerdere invalshoeken te benaderen.
Echt scenario: vervanging van een 23-jaar oud COBOL-systeem bij een Nederlandse verzekeraar. 4,2 miljoen polissen. 340 downstream-integraties.
De brief zegt 'vervang het PAS door een modern platform'. Ik heb 48 uur besteed aan het in kaart brengen van de werkelijke bedrijfsprocessen — en ik moet iets kritisch melden. Het COBOL-systeem is niet alleen een policy-store. Het bevat 23 jaar aan ongedocumenteerde bedrijfsregels direct in de berekeningsengine. Ik heb 847 unieke premieberekeningsvarianten gevonden, waarvan 312 geen documentatie hebben. Drie varianten lijken wettelijk verplicht te zijn op grond van DNB-regelgeving uit 2009 die nooit formeel is vastgelegd. Aanbeveling: voordat we ook maar één architectuurlijn ontwerpen, hebben we een extractiefase van 6 weken nodig. Zonder die fase bouwen we op drijfzand.
Lena heeft gelijk over de bedrijfsregels — dit is het grootste risico in dit project. Maar ik ben het oneens met een sequentiële extractiefase van 6 weken. Dat is een waterval-aanname. Mijn tegenvoorstel: we voeren de extractie parallel uit aan het architectuurontwerp via een strangler fig-patroon. We vervangen het COBOL-systeem niet — we wurgen het. Nieuwe polissen gaan vanaf dag één door het moderne platform. Bestaande polissen blijven in COBOL tot hun verlengingsdatum, waarna ze automatisch migreren. Dit levert ons drie dingen tegelijk op: (1) we leren de bedrijfsregels door live COBOL-gedrag in productie te observeren, (2) we reduceren het migratierisico tot bijna nul omdat we nooit een big-bang cutover doen, en (3) we leveren al na 8 weken bedrijfswaarde in plaats van 14.
Tjerk, ik ben dol op het strangler fig-patroon in theorie. In de praktijk, met 340 downstream-integraties, zie ik een catastrofaal faalscenario dat je niet hebt behandeld. De downstream-systemen weten niet dat ze met twee verschillende backends praten. Wanneer polis P-4471823 in COBOL bestaat en polis P-4471824 in het nieuwe platform, wat gebeurt er dan als het claimmanagementsysteem alle polissen opvraagt van klant C-991234 die beide heeft? Je krijgt een split-brain scenario. Ik heb dit exacte patroon bij drie enterprise-verzekeraars zien mislukken. We hebben een unified query layer nodig — een leesmodel dat van beide backends aggregeert. Dat is 4-6 weken extra architectuurwerk, maar niet onderhandelbaar. Zonder dit introduceren we een dataconsistenierisico dat een DNB-audit kan triggeren.
Mira heeft het echte probleem geïdentificeerd. Hier is mijn implementatievoorstel: we bouwen een CQRS-aggregatielaag met event sourcing. Elke statuswijziging — of die nu afkomstig is van COBOL of het nieuwe platform — publiceert naar een Kafka-topic. Een dedicated projectieservice consumeert alle events en onderhoudt een unified leesmodel in PostgreSQL met een gematerialiseerde view per downstream-integratiepatroon. De 340 downstream-systemen praten nooit rechtstreeks met een van beide backends — alleen met het leesmodel. Dit betekent: nul split-brain risico, we kunnen events herspelen om het leesmodel op elk moment te herbouwen, en de 340 integraties hebben nul wijzigingen nodig. Één zorg: het COBOL-systeem heeft elke nacht een batchverwerkingsvenster van 02:00-05:00 CET. Gedurende dit venster is de event stream 3 uur stil. We hebben een compenserend transactiemechanisme nodig voor dat venster.
Svens CQRS-aanpak is solide. Het batchvenster-probleem is oplosbaar via een CDC-connector op de COBOL DB2-database — we tappen rechtstreeks in het DB2-transactielogboek in plaats van te vertrouwen op de applicatie voor het uitzenden van events. Maar ik moet een datakwaliteitsprobleem aankaarten dat alles beïnvloedt: 127.000 polissen met dubbele klant-ID's, 43.000 polissen met ongeldige postcodes, en 8.200 polissen waarbij het premieberekeningsresultaat niet overeenkomt met de opgeslagen premie — afrondingsfouten die 23 jaar zijn opgestapeld. Die 8.200 premieverschillen zijn kritiek. Als we die polissen as-is migreren, migreren we onjuiste data. Als we ze corrigeren tijdens de migratie, wijzigen we financiële records — wat DNB-notificatie vereist en mogelijk klantcommunicatie.
Bas heeft iets blootgelegd dat de projectscope fundamenteel verandert. Die 8.200 premieverschillen zijn niet alleen een datakwaliteitsprobleem — het is een potentiële schending van Wft Artikel 4:20. Verzekeraars zijn verplicht premies te berekenen die het risicoprofiel nauwkeurig weerspiegelen. Gemiddeld verschil: €2,34 per polis per jaar. Over 23 jaar: potentieel €440.000 aan te veel of te weinig betaalde premies. Dit is een beslissing op bestuursniveau, niet een technische beslissing. Ik meld dit nu omdat het ontdekken na go-live catastrofaal slechter zou zijn. Op architectuurvlak: het nieuwe platform moet vanaf dag één onveranderlijke auditlogging implementeren. Elke premieberekening moet worden gelogd met de exacte invoer, de exacte regelversie en de exacte uitvoer. Het COBOL-systeem heeft dit niet — en dat is precies waarom we in deze situatie zitten.
Dit debat was precies wat dit project nodig had. Samenvatting van wat we collectief hebben ontworpen: (1) Strangler fig-patroon — bevestigd, met Mira's unified query layer toegevoegd. (2) CQRS + Event Sourcing — Svens projectieservice, met Bas' CDC-connector die applicatie-level events vervangt. (3) Datakwaliteitsremediatie — parallele workstream, 2 weken assessment, bestuursbeslissing vereist over de 8.200 polissen. (4) Onveranderlijke auditlogging — Elena's vereiste, ingebouwd in het platform vanaf sprint 1. Wat we in dit gesprek hebben voorkomen: een split-brain dataconsistentiefout die 340 systemen treft, een 3-uur event-gap tijdens batchverwerking, een regelgevingsovertreding die een DNB-audit kon triggeren, en een 6-weken sequentiële vertraging. Herziene tijdlijn: 16 weken naar eerste polis op het nieuwe platform (was 22 weken). Nul big-bang cutover. Nul DNB-risico.
↑ Echt voorbeeld: Tientallen agents debatteren over een COBOL-systeemvervanging. In 4 minuten vinden zij vier kritieke risico's die een traditioneel team pas na 3 maanden zou ontdekken.
Zes gestructureerde fasen. In elke fase werken meerdere agents parallel — en reviewen elkaars output voordat het naar de volgende fase gaat.
De Productielijn
tientallen AI-specialisten. Één productielijn. Nul blinde vlekken.
Traditionele aanpak
Eén architect neemt alle beslissingen
Fouten pas ontdekt in testfase
Weken wachten op reviews
Tunnelvisie door homogeen team
Migratie als afterthought
Doorlooptijd: 4–8 maanden
Bright MultiAgent
Tientallen specialisten debatteren elke beslissing
Fouten gevonden in de ontwerpfase
Realtime reviews, 24/7 iteratie
Bewust tegengestelde perspectieven
Migratie als integraal onderdeel
Doorlooptijd: 2–4 weken
Elke agent is getraind met een specifieke persoonlijkheid en perspectief. Samen vormen zij een team dat structureel beter presteert dan een homogene groep — omdat tegenspraak tot betere beslissingen leidt.
Ziet het grote plaatje. Toetst elke beslissing op schaalbaarheid en enterprise-fit. Stelt de vraag: "Werkt dit ook als de organisatie verdubbelt?"
Stelt de vragen die niemand durft te stellen. Graaft door tot het échte probleem boven tafel komt. Beschermt het project tegen scope creep.
Denkt in werkende code, niet in theorie. Vertaalt complexe architectuur naar pragmatische implementatie. Bouwt altijd met testbaarheid als uitgangspunt.
Professioneel sceptisch. Zoekt actief naar wat er mis kan gaan. Vindt de edge cases die anderen over het hoofd zien. Accepteert geen "dat gaat vast goed".
Bewaker van regelgeving en veiligheid. Vertaalt Wft, GDPR en DORA naar concrete architectuurvereisten. Zorgt dat compliance geen afterthought is maar een fundament.
Voorzichtig en methodisch. Nul downtime is de norm, niet de uitzondering. Plant elke migratiestap met rollback-mogelijkheid. Denkt altijd aan de bestaande data.
Alles wat u wilt weten over AI-gedreven softwareontwikkeling met tientallen agents.
Contact
Brightworld analyseert de situatie en geeft een concreet beeld van de mogelijkheden.