🤖 AI

Causal Software Engineering: A Vision and Roadmap

Dit artikel stelt "Causale Software-engineering" voor als een nieuw paradigma dat verder gaat dan correlatieve AI door systematisch causale modellen en redenering toe te passen voor beslissingen met hoge risico's, en biedt een routekaart voor hulpmiddelen, workflows en benchmarks om kritische "wat-zou-als"-vragen te beantwoorden gedurende de volledige softwarelevenscyclus.

Oorspronkelijke auteurs: Roberto Pietrantuono, Luca Giamattei, Stefano Russo, Julien Siebert, Neil Walkinshaw

Gepubliceerd 2026-05-06

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Roberto Pietrantuono, Luca Giamattei, Stefano Russo, Julien Siebert, Neil Walkinshaw

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 de kapitein bent van een enorme, high-tech ruimteschip. Elke dag moet je kritieke beslissingen nemen: Moet ik de motorinstellingen wijzigen? Moet ik het schip omleiden via een nieuw sterrenstelsel? Als ik de werktempo van de bemanning verlaag, komen we sneller of langzamer aan?

Op dit moment vertrouwen de meeste software-engineers (de kapiteins van de digitale wereld) op een kaart die alleen correlaties toont. Het is alsof je kijkt naar een weerbericht waarin staat: "Elke keer als het regent, dragen mensen paraplu's." De kaart vertelt je dat regen en paraplu's samen voorkomen. Maar het vertelt je niet wat er zou gebeuren als je de regen zou stoppen, of als je iedereen zou dwingen om op een zonnige dag paraplu's te dragen.

Dit artikel, "Causale Software Engineering," stelt een nieuwe manier van navigeren voor. Het suggereert dat we stoppen met alleen kijken naar wat samen gebeurt, en beginnen met het begrijpen van oorzaak en gevolg.

Hier is de visie opgesplitst in eenvoudige concepten:

1. Het Probleem: De "Toeval"-Valstrik

De auteurs vertellen een verhaal over een softwareteam dat een traag computerprogramma heeft opgelost. Ze veranderden één instelling (laten we het de "Opnieuw-knop" noemen), en plotseling werd het programma sneller. Het team vierde, denkend dat de knop de held was.

Maar hier zit de adder onder het gras: Op precies hetzelfde moment voegde het automatische systeem van de computer meer werkers (servers) toe en verschoven de gebruikersverkeer naar een andere locatie. Het programma werd sneller door alle die dingen die tegelijk gebeurden, niet alleen door de knop.

Omdat het team alleen keek naar wat samen gebeurde (correlatie), dachten ze dat de knop de magische oplossing was. Later, toen ze dezelfde knop probeerden te gebruiken op een ander systeem zonder de extra werkers, crashte het programma. Ze hadden een toeval verward met een oorzaak.

2. De Oplossing: De "Wat-Zou-Gebeuren"-Machine

Het artikel stelt Causale Software Engineering (CSE) voor. In plaats van alleen te vragen: "Wat gebeurt er meestal met X?", vraagt CSE: "Wat zal er gebeuren als we X doen?"

Stel je het voor als een vluchtsimulator voor softwarebeslissingen.

Oude manier (Correlatie): "Elke keer als we door een storm vliegen, schudt het vliegtuig. Dus, als we door een storm vliegen, moeten we schudden verwachten."
Nieuwe manier (Causaliteit): "Als we de motortrilling veranderen (de interventie), hoe zal het schudden dan veranderen, zelfs als de storm er nog is? En als we gisteren de trilling hadden veranderd, hadden we dan het crash kunnen voorkomen?"

3. De Drie Nieuwe Hulpmiddelen

Om dit werkbaar te maken, stellen de auteurs drie nieuwe hulpmiddelen voor die engineers zouden gebruiken, zoals een checklist voor een piloot:

De "Causale Ontwerpspecificatie" (Het Blauwdruk): Voordat er een verandering wordt aangebracht, schrijven engineers een eenvoudige kaart op. Ze noteren:
- Wat we veranderen (de interventie).
- Wat we willen laten gebeuren (het doel).
- Wat anders nogal eens de boel kan verstoren (de "verstorende factoren", zoals verkeersschommelingen of andere updates).
- Analogie: Het is alsof een chef-kok een recept schrijft waarin expliciet staat: "Als ik zout toevoeg, moet ik ook controleren of de oventemperatuur is veranderd, anders kan ik niet zeker weten of het zout de soep lekkerder heeft gemaakt."
Het "Interventie-logboek" (De Zwarte Doos): Elke keer dat er een verandering wordt aangebracht, registreert het systeem niet alleen wat er veranderde, maar ook wat er nog meer op dat exacte moment gebeurde.
- Analogie: In plaats van alleen te zeggen "De motor is gerepareerd", zegt het logboek: "De motor is gerepareerd, maar tegelijkertijd daalde de brandstofdruk en nam de windsnelheid toe." Dit helpt om de echte oorzaak te scheiden van de ruis.
Het "Levend Model" (De Kristallen Bol): Dit is een slim systeem dat de blauwdrukken en logboeken gebruikt om de toekomst te voorspellen. Het raadt niet zomaar; het berekent de "oorzaak" terwijl het de "ruis" negeert.
- Analogie: Het is alsof een GPS die je niet alleen laat zien waar het verkeer is, maar je vertelt: "Als je deze omweg neemt, bespaar je 10 minuten, zelfs als de hoofdweg momenteel vrij is."

4. Het Routekaart: Een Vierstaps Beklimming

De auteurs verwachten niet dat dit over nacht gebeurt. Ze stellen een routekaart voor met vier fasen, zoals het beklimmen van een berg:

Niveau 1: Duidelijk Zien (Causale Observabiliteit): We moeten betere sensoren bouwen die niet alleen data registreren, maar de structuur begrijpen van hoe dingen met elkaar verbonden zijn. We moeten weten welke draden echt met de motor verbonden zijn, niet alleen welke trillen.
Niveau 2: Veilig Experimenteren (Interventie door Ontwerp): We moeten veranderingen in kleine, veilige stappen aanbrengen (zoals het testen van een nieuwe motor op slechts één vleugel van het vliegtuig) zodat we zeker weten wat het resultaat heeft veroorzaakt.
Niveau 3: Tijdreizen (Contraventionele Zekerheid): We hebben hulpmiddelen nodig die kunnen beantwoorden: "Als we gisteren dingen anders hadden gedaan, was het crash dan voorkomen?" Dit helpt ons te leren van fouten zonder het vliegtuig opnieuw te laten crashen.
Niveau 4: De Betrouwbare Medepiloot (Causale Copilots): Tot slot krijgen we AI-assistenten die niet zomaar raden. Ze worden "geleid" door de regels van oorzaak en gevolg. Ze zullen je niet vertellen om een knop in te drukken tenzij ze zeker weten dat het het probleem echt zal oplossen, en ze zullen toegeven wanneer ze niet genoeg data hebben om zeker te zijn.

5. Hoe Weten We Of Het Werkt?

Het artikel stelt dat we deze nieuwe hulpmiddelen moeten testen met specifieke "examens":

De "Werkte Het?"-Test: Geef de computer een bekende verandering en kijk of het het resultaat correct identificeert.
De "Wat-Zou-Gebeuren?"-Test: Geef de computer een verleden ramp en vraag: "Was dit voorkomen als we X hadden gedaan?" Kijk of zijn antwoord overeenkomt met het echte verhaal.
De "Stresstest": Probeer het systeem te bedriegen met nepdata om te zien of het toegeeft: "Ik kan niet zeker zijn," in plaats van een zelfverzekerde maar verkeerde gok te doen.

De Conclusie

Het artikel betoogt dat software-engineering verschuift van raden op basis van patronen naar beslissen op basis van oorzaken. Door elke software-update te behandelen als een bewuste experiment en het "waarom" achter elk resultaat vast te leggen, kunnen we systemen bouwen die veiliger, betrouwbaarder en makkelijker te repareren zijn wanneer er iets misgaat. Het gaat erom te verschuiven van "Het regent meestal als de lucht grijs is" naar "Als we de sproeiers aanzetten, wordt het gras nat, zelfs als de lucht grijs is."

Technische Samenvatting: Causale Software Engineering: Een Visie en Routekaart

Probleemstelling

Moderne software engineering (SE) maakt zwaar gebruik van door AI aangedreven tools (anomalie-detectie, AIOps, agents op basis van LLM's) om beslissingen met hoge risico's te nemen onder onzekerheid. Echter, huidige benaderingen vertrouwen voornamelijk op correlatiemodellen die patronen en gelijktijdige voorkomen identificeren in historische data (bijvoorbeeld: "wanneer de metriek $Y$ hoog is, verschijnt gebeurtenis $E$ vaak"). Deze modellen worstelen om interventievragen te beantwoorden ("Wat gebeurt er als we een time-out wijzigen?") of contrfactuele vragen ("Zou een uitval zijn voorkomen onder een ander releaseplan?").

Het kernprobleem is dat correlatiesignalen vaak leiden tot valse conclusies wanneer verborgen verstorende factoren (bijvoorbeeld auto-scaling-gebeurtenissen, verkeersverschuivingen) meedraaien met de interventie. Bijgevolg kunnen ingenieurs de causale drijfveren van systeemgedrag verkeerd identificeren, wat leidt tot inefficiënte of schadelijke herstelstrategieën. Het artikel betoogt dat SE moet overstappen van "post hoc-correlatiejacht" naar interventiebewuste besluitvorming die is gebaseerd op expliciete causale aannames.

Methodologie en Voorgesteld Paradigma

De auteurs stellen Causale Software Engineering (CSE) voor als een nieuw paradigma dat causale modellen en redenering integreert in standaard SE-werkstromen. CSE vervangt bestaande praktijken niet, maar verrijkt ze met drie kerncomponenten:

Expliciete Aannames: Het expliciet en controleerbaar maken van causale structuren (bijvoorbeeld verboden of vereiste koppelingen tussen variabelen) en verstorende factoren.
Onzekerheidsbewuste Effectschattingen: Het leveren van causale effectschattingen met gekwantificeerde onzekerheidsmarges in plaats van puntvoorspellingen.
Contrfactuele Diagnose: Het mogelijk maken van redenering over wat er zou zijn gebeurd onder andere omstandigheden.

De CSE-werkstroom

De methodologie introduceert een "causaal-eerst"-werkstroom die het softwarelevenscyclus beslaat, ondersteund door drie lichtgewicht artefacten:

Causale Ontwerpspecificaties: Versiebestanden die zijn gekoppeld aan requirements en Architecture Decision Records (ADR's) en die sleutelvariabelen, uitkomsten, kandidaat-verstorende factoren en toelaatbare interventies definiëren.
Interventielogboeken: Gestructureerde records van wijzigingen (deployments, feature toggles) die de beoogde interventie ( $X$ ), gelijktijdige verstorende factoren ( $Z$ ) en waargenomen uitkomsten vastleggen, en CI/CD-acties koppelen aan operationele realiteit.
Levende Causale Modellen: Runtime-modellen die de ontwerpspecificaties instantiëren met live telemetrie en experimentele data om "wat-als"-vragen te beantwoorden en contrfactuele diagnose uit te voeren.

Het raamwerk maakt gebruik van de do-operator ($do(X=x)$) om onderscheid te maken tussen het observeren van een gebeurtenis en het interveniëren erop, waardoor de schatting van verstorende-vrije causale effecten $P(Y|do(X=x))$ mogelijk wordt.

Belangrijkste Bijdragen

Het artikel schetst een gestructureerde visie en routekaart voor de adoptie van CSE, georganiseerd in vier co-evoluerende routes en een gefaseerd volwassenheidsmodel:

1. Vier Routes naar Causale Bereidheid

De auteurs definiëren vooruitgang via vier routes, waarbij elke route gaat van huidige "Prestaties" naar "Uitdagingen" en uiteindelijk naar "Dromen":

Route 1: Causale Observabiliteit (CRL-1): Overgang van retrospectieve root-cause-analyse naar causale observabiliteit. Uitdagingen omvatten het bouwen van verstorende-factoren-bewuste modellen uit monitoringdata en het waarborgen dat causale grafieken stabiel blijven bij systeem-evolutie.
Route 2: Intervenibiliteit-by-Design (CRL-2): Het transformeren van bestaande leveringsmechanismen (CI/CD, feature flags, canaries) naar causale instrumentatie. Uitdagingen betreffen het ontwerpen van veilige experimenten (canary/A-B-tests) die identificeerbaarheid waarborgen en het doorgeven van onzekerheid naar go/no-go-beslissingen.
Route 3: Contrfactuele Waarborging (CRL-3): Het schalen van contrfactuele redenering van lokaal debuggen naar systeemwijde waarborging. Uitdagingen omvatten het uitvoeren van contrfactuele Root Cause Analysis (RCA) op schaal en het standaardiseren van weerleggingscontroles (bijvoorbeeld placebo-tests).
Route 4: Governance & Uitlijning (CRL-4/5): Het integreren van causale redenering in veiligheidscases en compliance. Uitdagingen omvatten het creëren van controleerbare causale claims voor regelgevers en het ontwikkelen van "causale copilots" (LLM-agents die zijn beperkt door causale consistentie).

2. Causale Bereidheidsniveaus (CRL's)

Het artikel stelt een volwassenheidsmodel voor (CRL-0 tot CRL-5) om de voortgang van organisaties en tooling te meten, variërend van op correlatie gebaseerde systemen (CRL-0) tot volledig gecertificeerde causale copilots en causale certificering (CRL-5).

3. Evaluatie- en Benchmarkagenda

Om vooruitgang te meten, stellen de auteurs drie families van benchmarks voor:

Interventie-effect-benchmarks: Data sets met bekende wijzigingen en grondwaarheid-impact om effectschatting en onzekerheidskalibratie te testen.
Contrfactuele incident-benchmarks: Data sets van incidenten met versiegeschiedenis om contrfactuele RCA-capaciteiten te evalueren.
Causale test-benchmarks: Scenario's (bijvoorbeeld simulators, foutinjectie) om te evalueren of testgeneratie causale factoren kan identificeren in plaats van alleen correlaties.

Het artikel benadrukt dat resultaten effectschattingen moeten rapporteren met onzekerheid, sensitiviteitsanalyses en faalmodi wanneer aannames breken.

Resultaten en Claims

Als visie- en routekaartartikel presenteren de auteurs geen empirische experimentele resultaten of een specifiek geïmplementeerd hulpmiddel. In plaats daarvan zijn de "resultaten" het conceptuele raamwerk en de routekaart zelf. Het artikel claimt:

Haalbaarheid: CSE is haalbaar door bestaande SE-artefacten (specificaties, logboeken, modellen) te verrijken in plaats van een volledige overhaul van de engineering-stack te vereisen.
Noodzaak: Huidige door AI aangedreven tools zijn ontoereikend voor beslissingen met hoge risico's omdat ze causale redenering missen; CSE biedt de noodzakelijke structuur om "wat-als"- en "wat-zou-er-zijn-gebeurd"-vragen te beantwoorden.
Actieerbaarheid: De voorgestelde routekaart (Routes 1–4) biedt een concreet pad voor onderzoekers en praktici om over te stappen van op correlatie gebaseerde naar op causaliteit gebaseerde engineering.

Betekenis

Het artikel positioneert CSE als een kritieke evolutie voor software engineering in een tijdperk van complexe, adaptieve systemen. De betekenis ligt in:

Paradigmaverschuiving: Het verplaatsen van het vakgebied van patroonherkenning naar causale redenering, waarmee de fundamentele beperking van correlatie-AI in dynamische omgevingen wordt aangepakt.
Operationalisering van Causaliteit: Het bieden van een praktische, artefact-gebaseerde aanpak (specificaties, logboeken, levende modellen) die past in bestaande pijplijnen, waardoor causale redenering toegankelijk wordt voor praktiserende ingenieurs.
Vertrouwen mogelijk maken: Het bieden van een pad naar "evidence-backed assurance" waarbij beslissingen over veiligheid, eerlijkheid en betrouwbaarheid zijn gebaseerd op controleerbare causale claims in plaats van ondoorzichtige correlaties.
Community-inspanning catalyseren: Het opgeroepen tot gedeelde data sets, gemeenschappelijke evaluatiepraktijken en SE-specifieke causale tooling om causale redenering om te zetten in een routine-engineeringpraktijk.

De auteurs concluderen dat CSE de volgende generatie betrouwbare assistenten, contrfactuele testen en evidence-backed assurance zal mogelijk maken, en uiteindelijk zal transformeren hoe softwaresystemen worden ontworpen, beheerd en bestuurd.