Er draait code in productie die niemand kan uitleggen. AI-gegenereerde software die werkt, tests haalt en naar productie gaat — zonder dat iemand begrijpt wat het doet. Drie lagen om dark code te bestrijden.
Stel: uw bureau levert volgende week een webapp op aan een klant. De developer heeft het in drie dagen gebouwd met AI. Het werkt, de tests slagen, de klant is blij. Zes maanden later belt diezelfde klant: er is een storing. De developer die het bouwde is inmiddels weg. De nieuwe developer opent de codebase en begrijpt er niets van. Niet omdat de code slecht is — maar omdat niemand het ooit heeft begrepen.
Dit scenario speelt zich in 2026 dagelijks af bij bureaus en bedrijven wereldwijd. De industrie heeft er een naam voor: dark code.
Wat is dark code precies?
Dark code is geen slechte code. Het is geen spaghetti, geen technische schuld, geen haastwerk. Dark code is code die op geen enkel moment in het ontwikkelproces door een mens is begrepen.
Het verschil met eerdere problemen is fundamenteel. Bij technische schuld wist iemand ooit hoe de code werkte — die kennis is alleen verloren gegaan over tijd. Bij dark code heeft die kennis nooit bestaan. Een AI-model genereerde de oplossing, geautomatiseerde tests gaven groen licht, en de code ging live. Niemand heeft zich afgevraagd: begrijp ik eigenlijk wat hier gebeurt?
Twee krachten versterken dit probleem dagelijks:
AI schrijft anders dan mensen. Code die u zelf typt, begrijpt u automatisch — u heeft het immers bedacht. Code die een AI genereert, is net zo vreemd als code van een collega die u nooit heeft gesproken. Het kost bewuste moeite om het te doorgronden.
De druk om snel te leveren is enorm. AI maakt het mogelijk om in dagen te bouwen waar voorheen weken voor nodig waren. Niemand wil die snelheid opgeven. Maar snelheid zonder begrip is een recept voor problemen die pas maanden later zichtbaar worden.
Waarom de standaardreacties tekortschieten
De meeste bedrijven herkennen het probleem inmiddels, maar grijpen naar oplossingen die het symptoom behandelen — niet de oorzaak.
Monitoring en dashboards laten u zien wanneer er iets kapotgaat. Dat is waardevol. Maar het vertelt u niet waarom het kapotging, en ook niet hoe u het veilig kunt fixen zonder nieuwe problemen te introduceren. U observeert de schade, niet de oorzaak.
Extra lagen in uw pipeline — guardrails, orchestratie, fallbacks — verminderen het risico dat dark code schade aanricht. Maar elke laag is ook een extra laag die u moet begrijpen en debuggen. U stapelt complexiteit op complexiteit.
Acceptatie is de derde reactie: "het model weet wat het doet, dus het komt wel goed." Dit is de gevaarlijkste houding. Want het gaat goed — tot het moment dat het niet meer goed gaat. En op dat moment staat u voor een codebase die geen enkel mens in uw organisatie kan uitleggen aan een auditor, een klant of een rechter.
Bovendien wordt deze houding verleidelijker naarmate modellen beter worden. Hoe indrukwekkender de output, hoe makkelijker het is om te denken dat begrip overbodig is. Maar de kwaliteit van de output zegt niets over uw vermogen om problemen op te lossen als het misgaat.
Een betere aanpak in drie stappen
Dark code is geen technisch probleem dat u oplost met betere tooling. Het is een organisatievraagstuk. Hoe zorgt u ervoor dat uw team — of het nu twee mensen zijn of twintig — begrijpt wat het naar productie stuurt?
1. Schrijf op wat u wilt bouwen vóór u begint
Dit klinkt triviaal. Dat is het niet.
De verleiding in 2026 is om meteen te beginnen: prompt erin, code eruit, deployen. Maar de vijf minuten die u spendeert aan opschrijven wat de software moet doen, welke randvoorwaarden er gelden en wat het gewenste resultaat is, zijn de vijf minuten die u later dagen aan debugging besparen.
Amazon leerde dit op de harde manier. Na een grote storing in december herbouwden ze hun interne AI-codetool zodat die eerst requirements en takenlijsten genereert uit een prompt — vóór er één regel code wordt geschreven. Ze noemen het spec-driven development.
Het mooie is: een goede specificatie is tegelijk uw testcriterium. Als u helder kunt opschrijven wat de code moet doen, heeft u automatisch de maatstaf waartegen u het eindresultaat beoordeelt. De spec wordt de eval.
2. Bouw begrip in de code zelf in
Kennis over hoe software werkt, mag niet alleen in de hoofden van mensen zitten. Het moet zichtbaar zijn in de code — voor collega's, voor opvolgers, en voor AI-modellen die er later mee moeten werken.
Dat betekent drie dingen concreet:
Structuur documenteren: elke module beschrijft wat het doet, waar het van afhangt, en wat ervan afhangt. Niet in een apart wiki-document dat na twee weken verouderd is, maar in de code zelf.
Gedrag vastleggen: interfaces beschrijven niet alleen welke data erin gaat en eruit komt, maar ook hoe het systeem zich hoort te gedragen. Wat gebeurt er bij een fout? Hoe vaak mag er opnieuw geprobeerd worden? Wat zijn de prestatiegrenzen?
Begripsvragen automatiseren: stel de vragen die een ervaren developer zou stellen — waarom deze architectuurkeuze? Welke afhankelijkheden zijn er geïntroduceerd? Hoe gedraagt dit zich als er iets faalt? — en laat die automatisch beantwoord worden voordat code naar productie gaat.
3. Stel een begripscheck in als kwaliteitspoort
Voordat code naar productie gaat, moet het niet alleen de vraag "werkt het?" doorstaan, maar ook "begrijpen we het?"
Dit hoeft geen zwaar proces te zijn. Een gestructureerde check — deels geautomatiseerd met AI — die de kernvragen van een senior developer beantwoordt, is genoeg. Waarom is deze aanpak gekozen? Wat zijn de risico's? Is het leesbaar voor iemand die de context niet heeft?
Het resultaat is een vliegwiel: de vragen die u stelt, verbeteren de specificaties. Betere specificaties leiden tot betere code. Betere code leidt tot minder dark code. En minder dark code betekent minder onverwachte problemen in productie.
Waarom dit nu urgent is voor bureaus en het MKB
Dark code is niet alleen een probleem voor grote techbedrijven. Het raakt elk bureau dat websites en apps bouwt voor klanten, en elk MKB-bedrijf dat software inzet.
Compliance-risico: de EU AI Act vereist dat u kunt uitleggen hoe uw AI-systemen werken. "Dat heeft de AI gebouwd" is geen acceptabel antwoord voor een toezichthouder.
Beveiligingsrisico: code die niemand begrijpt, kan kwetsbaarheden bevatten die niemand opmerkt. En als er een patch nodig is, weet niemand waar te beginnen.
Aansprakelijkheid: als uw software schade veroorzaakt bij een klant, wordt u geacht te kunnen uitleggen hoe die software werkt. Dat is lastig als het antwoord "geen idee" is.
Afhankelijkheid: als de enige "kennis" over uw codebase bestaat in de vorm van een AI-model dat morgen een andere versie draait, heeft u geen fundament.
De balans: snel én bewust
Niemand pleit voor terug naar watervaldocumenten van veertig pagina's. De snelheid die AI biedt, is een enorm concurrentievoordeel — en bedrijven die dat benutten bouwen betere software in minder tijd.
Maar snel bouwen zonder te begrijpen wat u bouwt, is een tikkende tijdbom. Niet als het goed gaat — maar op het moment dat het misgaat. En in software gaat het altijd een keer mis.
De oplossing is niet vertragen. De oplossing is begrijpen op snelheid: specificeer wat u wilt, bouw begrip in de code in, en stel een check in die ervoor zorgt dat er nooit code naar productie gaat die niemand kan uitleggen.
Dark code is een keuze. Kies ervoor om het niet te accepteren.