Databronnen in dit artikel: CodeRabbit 2025.12 / New Relic 2026-rapport, Microsoft Work Trend Index 2026, Microsoft FY26 Frontier Firms-aankondiging, GitHub Spec Kit, AWS Kiro, OpenAI Codex, Claude Code, Alibaba Qoder, JetBrains 2026.1 AI Pulse. De cases zijn representatieve scenario’s en verwijzen niet naar specifieke bedrijven.

Je grootste fout is niet dat je geen tools hebt gekocht, maar dat je geen CLAUDE.md hebt geschreven

De CIO van een regionale bank klaagde bij me: de AI-tools zijn aangeschaft, de modellen zijn geïmplementeerd, het personeel is getraind — en toch bleef de deliverytijd in de eerste helft van 2026 vrijwel onveranderd. De leider van het kernteamsysteem was nog directer: “De code die AI schrijft is bruikbaar, maar we moeten hem elke keer helemaal herschrijven — het begrijpt onze bankregels niet, begrijpt de compliance-eisen niet, en weet niet hoe het moet integreren met dat 30 jaar oude legacy-systeem.”

Het probleem is niet dat AI niet sterk genoeg is — het probleem is dat jullie de regels niet hebben vastgelegd. CodeRabbit publiceerde in december 2025 een analyse van 470 open-source PR’s met cijfers die breed werden geciteerd: AI-ondersteunde PR’s bevatten gemiddeld 10,83 problemen, puur handmatige PR’s 6,45 — 1,7 keer zoveel, 70% meer bugs dan handmatig werk. In 2026 is het verhaal niet omgedraaid: New Relic constateerde in de 2026 State of AI Coding Report dat 78% van de teams meer incidenten rapporteerde na het uitrollen van AI-code, en 62% van de technisch leiders gaf toe dat hun teams “vol vertrouwen AI-code vrijgeven zonder regel-voor-regel review” (New Relic officieel rapport 2026, score 0,866, primaire bron). Beide datasets vertellen hetzelfde verhaal — AI mist geen capaciteit, het mist context.

Vanuit het perspectief van augustus 2026 moet elk verhaal over “versnelde AI-transformatie” worden bekeken tegen de volgende achtergrond:

| Kamp | Vooruitgang (2026 H1) | Tegenvoorbeeld (2026 H1) |
|—|—|—|—|
| EY | Microsoft 365 Copilot uitgerold naar 150.000 medewerkers, bespaart 2,5 miljoen uur / $250 miljoen; uitbreiding naar 400.000 medewerkers wereldwijd | Geeft tegelijkertijd toe dat de 95% versnelling en 37% kostenverlaging in financiële operaties alleen gelden onder de voorwaarde van “eerst standaardiseren” |
| Atos | Uitgerold naar 54 landen / 56.000 medewerkers; draait tegelijkertijd 19.000 AI-agents met een uniform controle-vlak voor identiteit/beveiliging/compliance/governance | Houdt strikt vast aan “eerst de governance-capaciteiten van Agent 365 live, dan pas opschalen” |
| Microsoft zelf | 2026 Work Trend Index: 82% van de leiders is van plan om binnen 12-18 maanden AI-agents in te zetten om de workforce uit te breiden | Erkent in dezelfde periode dat “de organisatorische verandering achterloopt op individueel gebruik” — dit is de kernparadox binnen het Frontier Firm-concept |

Bron: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5; New Relic 2026 State of AI Coding Report.

Deze twee vergelijkingen maken één ding duidelijk: zonder governance is opschalen gewoon risico vermenigvuldigen met N. De “snelheid” van EY/Atos/Microsoft gaat niet om de snelheid van het model, maar om het feit dat “de organisatie eerst de vraag beantwoordt hoe AI ingezet moet worden”. Dit is de achtergrond waartegen Spec-Driven Development (SDD) in H1 2026 echt mainstream werd — niet omdat engineers een voorkeur hebben voor documentatie, maar omdat je zonder specs simpelweg niet kunt overleven in een omgeving met 19.000 agents.

Dit artikel behandelt drie zaken: 1) waarom defecten in AI-code tot meer dan 1,7 keer ernstiger zijn dan handgeschreven code; 2) hoe GitHub, AWS, OpenAI, Anthropic en Alibaba in H1 2026 naar hetzelfde paradigma toe bewegen — AI-gedrag sturen via documentatie; 3) waarom spec-driven development een organisatorische capaciteit is, geen toolkeuze, en wat de drie implementatiefasen in H1 2026 zijn.

Staflengte = AI-defecten als veelvoud van menselijk; basislijn 1.0× = menselijk niveau

Basis 1.0×

Totaal aantal problemen

1.7×
AI 10.83 vs menselijk 6.45 / PR

Logica / correctheidsfouten

1.75×

Codekwaliteit / onderhoudbaarheid

1.64×

Beveiligingsbevindingen (gecombineerd)

1.57×

Onjuiste wachtwoordverwerking

1.88×

XSS-kwetsbaarheden

2.74×
↑ Hoogste

AI-code zonder normatieve beperkingen scoort op elke dimensie hoger dan menselijk
Financieel/telecom = compliance-afstemming, wachtwoordbeheer, versleuteling van gevoelige velden; AI ziet dit allemaal niet

I. AI-defectpercentage is geen modelprobleem, maar een contextprobleem

In het CodeRabbit-rapport wordt één zin steeds opnieuw geciteerd: “AI mist lokale bedrijfslogica: modellen voorspellen codepatronen op basis van statistiek, niet op basis van semantisch begrip. Zonder strikte beperkingen missen ze de systeemregels die senior engineers hebben geïnternaliseerd.”

Deze zin verklaart waarom CodeRabbit’s eigen AI-programmeerplatform (een bedrijf dat zich specifiek richt op AI-codebeoordeling) deze cijfers eerder zag dan anderen — ze bekijken dagelijks duizenden pull requests en zien dagelijks hoe AI-geschreven code eruitziet. De “belangrijkste” bevinding is niet het totaal, maar de verdeling:

Logica/correctheid +75%: bedrijfslogicafouten, afhankelijkheidsfouten, control flow-fouten, configuratiefouten — dit soort problemen komt niet altijd naar boven in tests, maar veroorzaakt wel incidenten in de productieomgeving.
Codekwaliteit +64%: inconsistente naamgeving, onduidelijke structuur, afwijking van projectpatronen — dit is de “categorie met de grootste verschillen”. Senior engineers zien in één oogopslag: “dit is niet hoe wij hier schrijven”.
Beveiliging +57% (XSS-klasse het hoogst met 2,74×): onjuiste wachtwoordverwerking (1,88×), onveilige objectreferenties (1,91×), lekken van gevoelige informatie, onveilige deserialisatie (1,82×) — in de financiële sector is dit niet de vraag “kan het werken”, maar “mag het wel uit”.

Het probleem is niet dat AI niet sterk genoeg is. Het probleem is dat het niets ziet.

Terug naar het echte knelpunt van die CIO: drie concrete faalpunten van AI in financiële kernsystemen.

Ten eerste: AI ziet de 30 jaar oude reconciliatielogica niet. De risicoregels van een bank staan in stored procedures van het kernssysteem — 30 jaar geleden geschreven, niemand kent ze nog volledig. De door AI gegenereerde code ziet er logisch correct uit, maar in de productieomgeving activeert ze die reconciliatiecheck die niemand zich herinnert, en de hele batch transacties faalt.

Ten tweede: AI ziet de compliance-eisen niet. Wachtwoorden moeten via het keymanagementsysteem, gevoelige velden moeten versleuteld worden opgeslagen, logs mogen geen klantinformatie bevatten — dit zijn harde toezichtseisen, vastgelegd in interne richtlijnen. AI weet dit niet, schrijft code die draait maar de compliance-review niet doorstaat.

Ten derde: AI ziet je technische schuld niet. Dat 30 jaar oude hostsysteem gebruikt een eigen interfaceprotocol, de documentatie is allang verdwenen. AI schrijft code volgens de gangbare RESTful-standaard, en bij de livegang blijkt de interface niet te matchen — twee weken herbewerking.

Terug naar die andere cijfers van New Relic: 62% van de teams “stuurt vol vertrouwen AI-code live zonder review”, 78% rapporteert meer incidenten na de livegang. Die twee cijfers samen zeggen eigenlijk: het defectpercentage van AI-code is op zichzelf niet het probleem — “ik weet niet welke defecten de AI-code heeft” is het probleem.

Typisch scenario: een regionale bank introduceert AI-ondersteunde ontwikkeling van de risicobeheermodule van haar kernsystemen. Binnen drie maanden stijgt het aantal afgewezen zaken bij de compliance-review aanzienlijk. De belangrijkste problemen zijn interne regels rond wachtwoordbeheer, encryptie van gevoelige velden en logcompliance. Deze regels staan allemaal in interne documenten, maar de AI ziet ze niet. Toen het team later de kernregels in een CLAUDE.md-bestand zette, daalde het aantal afwijzingen aanzienlijk.

Twee: De vijf platforms in H1 2026 — verschillende wegen, dezelfde “regelgedreven” bestemming

In juli 2025 lanceerde GitHub Spec Kit; begin 2026 volgden AWS Kiro, OpenAI Codex en Anthropic Claude Code; in mei 2026 nam Alibaba Qoder “Spec-Driven Workflow” op in haar productpositionering. In H1 2026 kwamen de vijf platforms bij hetzelfde paradigma uit: documentatie als leidraad voor AI-gedrag. Dit is geen uitvinding van één bedrijf, maar de collectieve reactie van de sector op de “AI-codekwaliteitscrisis”.

Laten we per platform kijken naar de nieuwste ontwikkelingen in H1 2026:

GitHub Spec Kit: referentie-implementatie, vijf fasen met poortcontroles. In september 2025 open-sourced, tegen de eerste helft van 2026 uitgegroeid tot de referentie-implementatie in de industrie. 5 kerncommando’s + 2 aanvullingen: /speckit.constitution (niet-onderhandelbare principes), /speckit.specify (wat en waarom), /speckit.plan (hoe aan te pakken), /speckit.tasks (taken opsplitsen), /speckit.implement (uitvoeren), plus /clarify en /analyze. Het belangrijkste ontwerpkenmerk is modelonafhankelijkheid — dezelfde spec/plan/tasks-bestanden zijn niet gebonden aan een specifieke uitvoeringsagent; Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf en Qwen Code kunnen ze allemaal gebruiken. Daardoor is het uitgegroeid tot een “organisatiebreed SDD-protocol” in plaats van een GitHub-specifiek product (vibecoding.app review juni 2026, score 0,816, secundaire bron).

AWS Kiro: van normgedreven denken naar de IDE. Gelanceerd in juli 2025, en in de eerste helft van 2026 doorgegroeid tot een volwaardige Agent IDE. Een workflow in drie fasen: requirements → ontwerp → taken. Het verschil met Spec Kit zit ‘m in de ‘hooks’ — bij Kiro kunnen spec-bestanden vooraf gedefinieerde agent-acties triggeren, waardoor stappen zoals compliance, audits of deployment — die normaal een extern systeem vereisen — direct in de workflow worden ingebed. Kies voor Kiro als je je team wilt dwingen om specificaties te schrijven — want zonder spec-bestand start Kiro simpelweg niet (AWS Kiro officieel, juli 2025; Kiro.dev-documentatie, 2026).

OpenAI Codex: AGENTS.md + composable Skills. In 2025-2026, AGENTS.md moved to the center of the ecosystem. Skills are the key extension of H1 2026: they pre-assemble workflows like “reading Excel sheets,” “generating SQL,” or “running data migrations,” so you can call them like Lego blocks. By June 2026, Codex had surpassed 5 million weekly active users, 20% of whom are non-developers — an overlooked signal: spec-driven work is no longer just for engineering teams; it’s for everyone. Product, operations, and risk teams are all writing AGENTS.md (OpenAI announcement, June 2, 2026; thebcms.com review, 2026, score 0.801).

Claude Code: CLAUDE.md + .claude/rules/ + Skills. Anthropic noemt het projectinstructiedocument CLAUDE.md (februari 2026 naar de officiële markt), .claude/rules/ (regels op basis van directoryhiërarchie), Skills (deelbare workflows). Claude Code is het best beoordeelde hulpmiddel onder ontwikkelaars in H1 2026 — JetBrains 2026.1-onderzoek geeft een CSAT van 91% en een NPS van 54, twee onafhankelijke onderzoeken (Pragmatic Engineer 2026.2) bevestigen dit. Dit is de hoogste score in de huidige AI-programmeertools-sector (uvik.net 2026.5, 0.956 score, samenvatting van primaire bronnen). Claude Code groeide in 9 maanden van 0 naar 2,5 miljard dollar aan geannualiseerde omzet (2026.2 Anthropic G-ronde), 112.000 stars op GitHub (Skills-repository) — ontwikkelaars stemmen met hun voeten en tonen de echte waarde van op regels gebaseerde aanpak.

Alibaba Qoder: regelgedreven in de Chinese markt. Uitgebracht in augustus 2025, geüpgraded naar versie 1.0 op 15 mei 2026, en daarmee officieel getransformeerd van een “AI IDE” naar een “Autonomous Agent Development Workbench”. De Spec-Driven Workflow werd gelanceerd samen met Quest Mode (autonome multi-bestandstaken), Expert Mode (parallelle expertteams) en RepoWiki (repository-kennisdomein). Op 28 mei 2026 kwamen Cloud Agents (volledig beheerde agent-runtime) beschikbaar, gevolgd door Qoder Security (nalevings- en beveiligingsmogelijkheden) op 21 juli, en in dezelfde maand verscheen de mobiele versie (Android/iOS/HarmonyOS). In mei 2026 passeerde het wereldwijde gebruikersaantal de 5 miljoen, en DingTalk CLI vermeldt het als een van de ondersteunde agent-uitvoeringsomgevingen (Yahoo Finance 2025; Alibaba Cloud official 2026; Baidu Baike 2026.7).

Gemeenschappelijk paradigma: leg expliciet vast hoe wij met AI samenwerken in een document, plaats dat in de repository, en laat alle mensen én alle AI-agenten tegen dezelfde set afspraken werken. De vijf platforms verschillen in implementatiedetails (bestandsnamen/aantal fasen/hook-mechanismen), maar het doel is exact hetzelfde.

Waarom gebeurt dit nu allemaal in H1 2026? Omdat de AI-capaciteitsdrempel inmiddels is overschreden — Claude Code als autonome agent, Codex met parallelle multi-agenten, Cursor met multi-file refactoring: AI is geen “autocomplete-tool” meer, maar een “collega”. En de onboarding-documentatie die je een nieuwe collega geeft, moet ook leesbaar zijn voor AI.

3. Normgedreven werken is een organisatorische capaciteit, geen toolkeuze

Dit is het belangrijkste punt voor beslissers. Normgedreven werken is geen kwestie van tools kiezen, maar van definiëren hoe onze organisatie met AI samenwerkt. Of je nu kiest voor GitHub Spec Kit of Claude Code maakt niet uit — wat telt is of je de normen hebt vastgelegd in een document, in de repository hebt geplaatst, en of iedereen én alle AI-systemen daarnaar werken.

Zonder die basis zorgen zelfs de beste tools er alleen maar voor dat je team sneller meer technische schuld creëert.

Als we dit in het perspectief plaatsen van grootschalige uitrol in de eerste helft van 2026, wordt het bewijs nog sterker. In de FY26-retrospective van juli 2026 beschrijft Microsoft de cases van EY en Atos als het ‘Frontier Firm’-sjabloon — niet omdat de modellen nieuw zijn, maar omdat beide bedrijven eerst de vraag ‘hoe zetten we AI in?’ hebben beantwoord:

EY: eerst governance, dan schaalbaar resultaat. EY rolde Microsoft 365 Copilot in 2024-2025 uit naar 150.000 medewerkers, met 2,5 miljoen bespaarde uren en circa 250 miljoen dollar aan besparingen als resultaat. De voorwaarde was dat het AI-governancekader eerst stond: EY bouwde met Power Platform, Copilot Studio, Azure, Foundry en Fabric één uniforme toolchain, waarin compliance, governance en audit in hetzelfde fundament werden ondergebracht. Pas daarna kwamen de 95% versnelling, 37% lagere financiële operationele kosten en tot 90% minder handmatige workflows. De vicepresident van EY zei het tijdens de AI Tour van 2026 heel direct: “Wij rollen niet eerst AI uit en repareren daarna de governance; wij bouwen eerst de governance en rollen daarna AI uit.”

Atos: één controle-vlak voor 19.000 agents. Atos is één van de eerste organisaties wereldwijd die Microsoft 365 E7 (Frontier Suite) heeft uitgerold, met Copilot voor 56.000 medewerkers in 54 landen. Tegelijkertijd draaien er 19.000 AI-agents – van interne IT en business units tot klantprojecten, allemaal gebouwd met Foundry + Copilot Studio. De sleutel tot dit succes is “één controle-vlak”: Entra (identiteit) + Defender (beveiliging) + Intune (apparaten) + Purview (compliance) + Agent 365 (agent-governance), vijf componenten die aan elkaar zijn gekoppeld. Deze koppeling vertaalt zich in de financiële sector naar “等保 (classificatie en beveiligingstesten) + data-exportbeoordeling + algoritme-registratie + audit + model-governance” – het is een governance-architectuur, geen op zichzelf staande AI-tool.

Microsofts eigen ‘organisatieveranderingsparadox’. In het Work Trend Index-rapport van 2026 geeft Microsoft zelf toe: “het tempo van organisatorische verandering blijft achter bij individueel gebruik.” Van de 20.000 AI-gebruikers die zij ondervroegen, zegt 82% van de leiders te plannen om binnen 12-18 maanden hun personeelsbestand uit te breiden met AI-agenten, maar slechts 24% heeft dit inmiddels op bedrijfsniveau uitgerold. 81% van de leiders verwacht dat AI-agenten in matige tot hoge mate worden geïntegreerd in hun AI-strategie — maar ook hier geldt: slechts 24% heeft dit daadwerkelijk gerealiseerd. Dit betekent dat de meeste organisaties nog 12-18 maanden verwijderd zijn van de kloof tussen ‘voorbereiden’ en ‘daadwerkelijk doen’. Hoe die kloof wordt overbrugd, is vooral een kwestie van normgedreven aanpak.

Bron: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, primaire PDF-bron); Futurum Group 2026.1.26-analyse (secundaire bron).

Inzicht één: investeren in normen levert een hoog rendement op.

CodeRabbit’s data biedt een duidelijke basis voor ROI-berekening: de AI-codeprobleemratio ligt op ongeveer 1,7x en beveiligingskwetsbaarheden nemen met 2,74x af. Dat betekent:

Minder herbewerking (in de financiële sector kost één compliance-review al snel 2-4 weken)
Minder beveiligingsincidenten (de boetes en reputatieschade van één datalek)
Lagere onderhoudskosten (een technische schuldreductie van 40% is een gangbaar cijfer)

Het schrijven van een CLAUDE.md/AGENTS.md-projectstandaard is de engineering-actie met het hoogste ROI in het AI-tijdperk. De EY-case geeft een realistische vertaalslag: 150.000 medewerkers met Copilot, een besparing van 250 miljoen dollar. Let op: EY bespaarde niet omdat “het tool zo goed was”, maar omdat “de standaard de waarde van het tool daadwerkelijk verzilverde”.

Inzicht twee: veranker de standaard in organisatieprocessen, niet in individuen.

Als een standaard alleen in het hoofd van één senior engineer bestaat, is hij verdwenen zodra die persoon vertrekt. Hij moet worden vastgelegd in:

Repository-documentatie (AGENTS.md / CLAUDE.md / constitution.md)
CI-gates (automatische controle op naleving van de standaard)
Gedeelde teamconfiguratie (het Skills-systeem maakt de standaard beschikbaar voor het hele team)

Laat normen een organisatorisch bezit worden, geen persoonlijke vaardigheid. Dit is vooral belangrijk in de financiële sector — jullie compliance-eisen, beveiligingsregels en bedrijfsregels zijn bezittingen van de organisatie, niet het “ervaringskapitaal” van één engineer. De 19.000 agents van Atos draaien in 54 landen, niet omdat “iemand het snapt”, maar omdat “het systeem het afdwingt”.

Inzicht drie: gating is belangrijker dan snelheid.

De vijf fasen van gating in GitHub Spec Kit (constitution → specify → plan → tasks → implement), Claude Code’s “geen code schrijven voordat tests falen”, en Kiro’s “geen spec, geen start” doen allemaal hetzelfde: een “rem” zetten tussen AI en het uiteindelijke resultaat. Elke stap levert een controleerbaar artefact op (spec.md, plan.md, tasks.md), en elke stap kan vóór het genereren van code worden afgekeurd of aangepast.

Hoe autonomer de AI, hoe meer gating nodig is. De Change Advisory Board (CAB) in de financiële sector, algoritme-registratieprocedures en de classificatie- en beveiligingsaudit (等保测评, een Chinees verplicht beveiligingsbeoordelingssysteem voor informatiesystemen) zijn in wezen allemaal vormen van gating vóór productie. AI-code heeft vergelijkbare gating nodig, alleen in een andere vorm. De 62% teams in het New Relic-rapport van 2026 die “vol vertrouwen zonder review deployen”, betalen voor dat vertrouwen met een hoger incidentcijfer (78%).

Fase één kost de meeste tijd, maar heeft de hoogste ROI
Bij de meeste financiële organisaties liggen regels verspreid over documenten/e-mails/hoofden; de eerste ordening kost 3-8 weken

Vier. De drie echte implementatiefasen van H1 2026

Aan de hand van de financiële sector als voorbeeld: een pad in drie fasen, waar ook andere sterk gereguleerde sectoren hun voordeel mee kunnen doen. De praktijk bij EY en Atos in H1 2026 sluit precies op deze drie fasen aan.

Fase één: regels inventariseren (2-4 weken).

Dit is de fase die het meeste tijd kost, maar ook het hoogste rendement oplevert. Breng alle regels die verspreid over de organisatie bestaan in kaart:

Compliance-eisen: het absolute minimum voor financiële instellingen = Niveau 3 van de Chinese classificatie van cyberbeveiliging (等保, vergelijkbaar met NIS2) + beoordeling van grensoverschrijdende dataoverdracht (vergelijkbaar met een GDPR-transfer impact assessment) + algoritmeregistratie (vergelijkbaar met de EU AI Act) — als één onderdeel ontbreekt, kun je AI beter niet uitrollen. Daarbovenop komen nog rapportageverplichtingen aan toezichthouders, bescherming van klantgegevens, beperkingen op grensoverschrijdende datastromen, en de vraag welke data AI überhaupt mag zien.
Beveiligingsregels: wachtwoordbeheer, encryptiestandaarden, verwerking van gevoelige velden, loggingvereisten.
Bedrijfsregels: risicodrempels, claimvoorwaarden, transactielimieten, facturatie-logica.
Technische beperkingen: interfaces van legacy-systemen, databasenaming, versiebeperkingen van frameworks.
Leveranciersbeheer: hoe je in contracten eist dat leveranciers onze standaarden hanteren, en hoe je het AI-gebruik van leveranciers auditeert.

Typisch scenario: tijdens de inventarisatiefase ontdekt een effectenbedrijf dat de regels verspreid liggen over talloze Word-documenten, JIRA-wiki’s, persoonlijke e-mails en Excel-sheets — pas na het opruimen ontstaat een gestructureerde regellijst. Atos pakt het systematischer aan: zij splitsen de regels direct op in vijf categorieën — compliance, security, bedrijfsvoering, techniek en leveranciers — elk met een eigen governance-workflow, allemaal aangesloten op het control plane van Agent 365.

Dit is geen technische klus, maar een organisatorische: je moet compliance, security en de business bij elkaar brengen en de regels vastleggen waar iedereen achter staat. De eerste keer kost dit financiële organisaties doorgaans 3 tot 8 weken — maar het is een blijvend organisatorisch bezit.

Fase 2: vastleggen in de repository (1–2 weken).

Schrijf de regels uit fase 1 uit als documentatie en plaats ze in de repository. GitHub Spec Kit gebruikt constitution.md, Claude Code gebruikt CLAUDE.md, OpenAI Codex gebruikt AGENTS.md, en Alibaba Qoder gebruikt Spec Workflow. De bestandsnamen verschillen, maar het doel is hetzelfde: AI moet de regels laden zodra de repository wordt geopend.

Voorgestelde structuur (mainstream in H1 2026):

Projectoverzicht: Wat doet dit systeem en voor wie?
Niet-onderhandelbare principes: Veiligheids-, compliance- en bedrijfsmatige rode lijnen.
Technische stack en beperkingen: Welk framework, welke database, welke interface-standaarden.
Codeerstandaarden: Naamgevingsconventies, directorystructuur, minimale testdekking (geen verplicht TDD-ritme — specificeer gewoon de testdekking, de verplichte testpaden en de verboden paden; TDD is een optionele organisatorische keuze, geen harde eis vanuit de standaard).
Bedrijfsregels: Risicobeheerlogica, transactieregels, facturatieregels.
Compliance-eisen: Graded protection (等保, classificatie en beveiliging van informatie), grensoverschrijdende data-overdracht, toezichtsrapportage, en of AI-gegenereerde algoritmen geregistreerd moeten worden.
AI-gebruiksrichtlijnen: In welke scenario’s mag AI worden gebruikt, waar is menselijke beoordeling verplicht, en wat zijn de regels voor grensoverschrijdende data?
Leveranciersbeheer: Contractvoorwaarden, auditmechanismen, verantwoordelijkheidsverdeling.

Bijlage: CLAUDE.md-skelet voor de financiële sector (ca. 200 regels, direct te forken en aan te passen)

Hieronder staat een CLAUDE.md-skelet voor de modernisering van de kernsystemen van een joint-stock bank, georganiseerd volgens de volgorde “niet-onderhandelbare principes → compliance-eisen → AI-gebruiksrichtlijnen → bedrijfsregels → technische beperkingen”. Je hoeft niet vanaf nul te beginnen — vul gewoon de lege plekken in met de specifieke regels van jouw organisatie.

# CLAUDE.md — <systeemnaam> AI-samenwerkingsrichtlijnen

> Toepassingsgebied: <systeemnaam> v<versie>, alle AI-agents (Claude Code / Cursor / Copilot / Codex)
> die in deze repository werken, dienen deze richtlijnen na te leven. Dit document wordt
> beheerd door de <governancecommissie>, met kwartaalreviews.
> Laatst bijgewerkt: <YYYY-MM-DD>

## 1. Projectoverzicht
- **Bedrijfspositionering**: naam kernsysteem / doelgroep / belangrijkste transactietypes
- **Kritieke keten**: transactie → risicobeheer → clearing → reconciliatie → rapportage
- **Niet-beschikbaar venster**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (geen wijzigingen toegestaan)
- **Kernafhankelijkheden**: upstream <systeem>, downstream <systeem>, platform voor regelgevende rapportage

## 2. Ononderhandelbare principes (rode lijnen — overtreding = merge geweigerd)

### 2.1 Beveiligings-rode lijnen
- Wachtwoorden, sleutels en tokens moeten verplicht via KMS (Key Management Service), **hardcoding verboden**, **printen in logs verboden**
- Gevoelige klantvelden (identiteitsbewijsnummer / kaartnummer / CVV / mobiel nummer) **moeten versleuteld worden opgeslagen**, platte tekst in database is verboden
- In logs is het volgende verboden: volledig identiteitsbewijsnummer, volledig kaartnummer, wachtwoord in platte tekst, combinatie klantnaam + mobiel nummer
- Externe API-aanroepen moeten verplicht via de API-gateway; directe verbindingen zijn verboden

### 2.2 Compliance-rode lijnen
- Door AI gegenereerde code die toegang heeft tot klantdata moet in de PR-beschrijving worden gelabeld met "data-toegang: <veld>"
- Grensoverschrijdende gegevensoverdracht is verboden; **alle data-export moet via een beoordeling van grensoverschrijdende gegevensoverdracht** (neem contact op met de compliance-afdeling)
- Algoritmische beslissingen (kredietverlening / verzekeringstarifering / antifraude) moeten een menselijke reviewpoort behouden
- Modelwijzigingen vereisen algoritmeregistratie; het registratienummer moet in de PR-beschrijving worden vermeld

### 2.3 Zakelijke rode lijnen
- Wijzigingen in risicobeheer-drempels vereisen dubbele handtekening van risicoverantwoordelijke + business-eigenaar
- Operaties die klantgelden raken, moeten een idempotent ontwerp + rollback bij falen hebben
- Transactielimieten, tarieven en productparameters worden beheerd via het parameterbeheerplatform; geen hardcoding in code

## 3. Technologiestack en beperkingen
- **Talen**: Java 17 (kern) / Kotlin (nieuwe modules) / SQL (database)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Database**: OceanBase 4.x (MySQL-compatibiliteitsmodus), **externe sleutels verboden**
- **Interface-standaarden**: intern altijd gRPC; externe interfaces via OpenAPI 3.0; RESTful alleen voor beheerinterfaces
- **Naamgevingsconventies**: Java-klassen in PascalCase, methoden in camelCase, constanten in UPPER_SNAKE; tabelnamen `t_<domein>_<entiteit>`; indexen `idx_<tabel>_<veld>_<volgorde>`
- **Pakketstructuur**: `com.<bedrijf>.<domein>.<subdomein>.<laag>` (bijv. `com.bank.pay.tx.core.service`)

## 4. Coderichtlijnen
- **Minimale testdekking**: kritieke keten ≥ 80%, utility-klassen ≥ 60%, nieuwe code in PR's moet tests bevatten
- **Verplicht te testen paden**: alle controllers vereisen integratietests (inclusief faalpaden); alle enum-takken vereisen unit-tests
- **Verboden paden**: het wijzigen van de map `<legacy-modules>` is verboden — eerst een adapterlaag aanmaken
- **Afhankelijkheidsbeheer**: nieuwe externe afhankelijkheden vereisen SCA-scan + goedkeuring beveiliging

## 5. Bedrijfsregels (per domein)
### 5.1 Transacties
- Limiet per transactie: <bedrag>; daglimiet: <bedrag>; overschrijding vereist handmatige goedkeuring
- Transactietijdsvenster: <HH:MM> ~ <HH:MM>
- Dubbele transactie-detectie: binnen <tijdsvenster> met hetzelfde <veld> = duplicaat

### 5.2 Risicobeheer
- Prioriteit zwarte lijst-matching: interne zwarte lijst → door toezichthouder uitgegeven lijst → gerechtelijke bevriezing
- Uitvoerdrempel antifraude-model: <score>; overschrijding vereist handmatige tweede review

### 5.3 Facturering
- Tariefswijzigingen vereisen een versienummer + ingangsdatum
- Historische orders worden berekend tegen het tarief dat gold op de ingangsdatum, zonder terugwerkende kracht

## 6. Compliancevereisten
- MLPS niveau 3 (等保三级): <evaluatie-instelling>, <datum volgende evaluatie>
- Beoordeling van grensoverschrijdende gegevensoverdracht: toepassingsgebied (alleen modulen voor grensoverschrijdende activiteiten)
- Algoritmeregistratie: toepassingsgebied (kredietverlening / verzekeringstarifering en andere kritieke algoritmen), registratienummer `<registratienummer>`
- Regelgevende rapportage: veldtoewijzingstabel voor <toezichthouder (CBIRC / People's Bank of China)> bevindt zich in `<pad>`

## 7. AI-gebruiksrichtlijnen
- **Scenario's waarin AI is toegestaan**: CRUD-sjablonen, genereren van unit-tests, documentconcepten, SQL-optimalisatiesuggesties
- **Scenario's die handmatige review vereisen**: risicobeheerlogica, factureringsregels, toegangscontrole, versleuteling/ontsleuteling, grensoverschrijdende data
- **Scenario's die AI niet zelfstandig mag afhandelen**: CAB-goedkeuringsmaterialen, uitvoering van productiewijzigingen, incidentrespons
- **Regels voor gegevensuitvoer**: trainingsdata / prompts / uitvoerlogs mogen het land niet verlaten; gelokaliseerde implementaties (<leverancier>) hebben de voorkeur
- **Auditvereisten**: alle door AI gegenereerde code moet in de PR-beschrijving worden gemarkeerd met "AI-assisted: <toolnaam>"

## 8. Leveranciersbeheer
- **Leverancierstoelating**: SOC 2 / ISO 27001-rapport vereist; AI-modellen moeten een modelkaart verstrekken
- **Contractuele bepalingen**: data-eigendom, modelleerbaarheid, uitstapclausule, auditrecht
- **Auditmechanisme**: kwartaalaudit van AI-gebruik door leveranciers; maandelijkse audit voor hoogrisico-leveranciers

## 9. Beheer en updates
- **Eigenaar**: <governancecommissie> (compliance + beveiliging + architectuur + business)
- **Updatefrequentie**: kwartaalreview; spoedwijzigingen via snel kanaal (dubbele handtekening + 24-uurs publicatie)
- **Wijzigingslog**: zie `CLAUDE_CHANGELOG.md`
- **Overtredingsafhandeling**: eerste overtreding = waarschuwing + verplichte training; tweede overtreding = schorsing AI-tools; derde = intrekking rechten

Dit raamwerk is geen “standaardantwoord”, maar een “invulmal”. Wat elke lege plek invult, is belangrijker dan hoeveel tekst je schrijft — de lege plekken onthullen precies datgene waar jouw organisatie “niet goed over heeft nagedacht”.

Een typisch voorbeeld: bij een middelgrote commerciële bank bevat het CLAUDE.md-bestand specifieke regels voor wachtwoordverwerking — wanneer AI gegenereerde code met wachtwoorden te maken heeft, moet het interne sleutelbeheer-API worden aangeroepen en is hardcoding verboden. Dit soort regels vormt een groot aandeel in de redenen waarom wijzigingen worden afgewezen bij compliancebeoordelingen.

Een belangrijk nieuw veld in H1 2026 is Skills/workflowdefinities — niet alleen documentatie, maar een toolchain die door AI kan worden aangeroepen. Het Skills-systeem van Claude Code (in februari 2026 toegevoegd aan de officiële Anthropic-marktplaats, 112.000 stars op GitHub) maakt processen zoals “Excel-bestanden lezen”, “SQL genereren” en “datamigraties uitvoeren” tot deelbare workflows. Dit is de cruciale evolutie van regeldriven werken in H1 2026: regels zijn niet alleen beperkingen, maar uitvoerbare workflows.

Fase drie: institutionalisering (doorlopend).

Het opstellen van een goede codestandaard is geen eindpunt, maar een beginpunt. Je moet er een vast onderdeel van de organisatieprocessen van maken:

CI-gate-integratie: automatisch controleren of code voldoet aan de standaard (bijvoorbeeld detectie van hardcoded wachtwoorden of ongecodeerde gevoelige velden)
Gedeelde teamconfiguratie: gebruik het Skills-systeem zodat het hele team met dezelfde standaard werkt
Periodiek updatemechanisme: als de regels veranderen, moet de standaard mee veranderen (kwartaalreview)
Meting en feedback: volg het defectpercentage van AI-code, het slagingspercentage van compliance-reviews en de herbewerkingsgraad
Agent-governance: breid governance van mensen uit naar AI-agents — wat Atos doet met Agent 365 is precies dat: dit op “systeemniveau” brengen in plaats van op “individueel niveau”

Zowel EY als Atos hebben in H1 2026 de derde fase als “organisatorische capaciteit” ingericht. EY’s besparing van 2,5 miljoen uur is te danken aan het goed uitvoeren van fase één en drie — fase twee was slechts het vertalen van regels naar door AI leesbare documenten.

Vijf. Variant voor sterk gereguleerde sectoren: drie engineering-benaderingen voor ingebedde compliance

In sterk gereguleerde sectoren zoals financiën, telecom en gezondheidszorg kent de implementatie van een standaard één extra horde vergeleken met de generieke industrie: compliance is geen externe toevoeging aan het proces, maar ingebouwd in de code. De volgende drie benaderingen zijn in H1 2026 gevalideerde manieren om compliance in te bedden. CIO’s en digitaliseringsverantwoordelijken kunnen ze direct gebruiken als referentie bij het inrichten van de organisatie.

5.1 Compliance-vertegenwoordigers ingebed in stream-teams: compliance als aanwezigheid, niet als goedkeuring achteraf

De traditionele aanpak: het business-team schrijft code, het compliance-team beoordeelt achteraf — en tegen de tijd dat de review problemen aan het licht brengt, is de code al twee weken in productie, met herstelkosten van 2 tot 4 weken. De kern van het probleem is dat compliance aan het einde van het proces zit.

De nieuwe aanpak: een compliance-vertegenwoordiger wordt ingebed in elk stream-aligned team, via een dual reporting-lijn: formeel onder de compliance-afdeling, functioneel onder het business-team. Concreet ziet dat er zo uit:

Formatie: één compliance-vertegenwoordiger per 6–8 stream-teams, aangestuurd door de compliance-afdeling, maar fysiek gehuisvest bij het business-team — geen ‘detachering’ voor een paar dagen
Functionele KPI’s: 50% van de beoordeling van de compliance-vertegenwoordiger hangt af van de ‘compliance-defectratio’ en het ‘first-time approval-percentage’ van het business-team, niet alleen van de ‘auditdekking’ van de compliance-afdeling
Vroegtijdige betrokkenheid: de compliance-vertegenwoordiger neemt deel aan de dagelijkse stand-up (één keer per week is voldoende), beoordeelt pull requests, en AI-gegenereerde code moet vóór de merge door de compliance-vertegenwoordiger worden goedgekeurd — niet pas achteraf wanneer het probleem al is ontdekt
Tooling: de compliance-vertegenwoordiger gebruikt Skills-aanroepen met compliance-checklists, in plaats van handmatig elke regel na te lopen

Typisch scenario: een landelijke commerciële bank laat in de eerste helft van 2026 drie streamteams piloten met een ingebedde compliance-vertegenwoordiger, waardoor het percentage afgekeurde AI-code daalt van 35% naar 8% — de kern is niet dat compliance “strenger kijkt”, maar dat compliance “eerder kijkt”. Het cruciale punt hierbij is dat de dotted-line targets van de compliance-vertegenwoordiger zijn afgestemd op de businessdoelstellingen — als de KPI’s van de compliance-vertegenwoordiger nog steeds uitsluitend door de compliance-afdeling worden bepaald, is het inbedden gedoemd te mislukken.

5.2 Compliance als enabling team: van beperkingen naar affordances

De traditionele aanpak: het compliance-team fungeert als “poortwachter”, en het business-team ziet compliance als “lastpak”. Beide partijen spelen een zero-sum-spel.

De nieuwe aanpak: het compliance-team wordt geherstructureerd volgens het enabling team-model van Team Topologies — ze schrijven geen code, ze beoordelen geen pull requests, maar ze leveren drie dingen waarmee het business-team zichzelf kan “complyen”:

Nalevingscontroles in de CI-pipeline: Maak veelvoorkomende nalevingspunten zoals hardcoded wachtwoorden, onversleutelde gevoelige velden, grensoverschrijdende datatransmissie en algoritmische besluitvormingspunten tot verplichte poortwachters in GitHub Actions / GitLab CI. Een PR van het ontwikkelingsteam activeert automatische controles; bij niet-naleving wordt de build direct afgekeurd — zonder dat een compliance-medewerker handmatig alles hoeft door te lopen.
Regelgeving omzetten in affordances (omgevingsgestuurde beperkingen): Bijvoorbeeld: bij het ontwikkelen van functionaliteiten die klantdata verwerken, toont de IDE-plugin een melding als “Voor dit veld wordt aanbevolen KMS aan te roepen”; bij het schrijven van logs wordt automatisch gedetecteerd of er gevoelige informatie in zit en wordt er een melding gegenereerd. Maak naleving een “vanzelfsprekende handeling tijdens het ontwikkelen”, niet “pas bij de release te horen welke regels er zijn overtreden”.
Gedeelde Skills-bibliotheek + compliance-training: Het compliance-team onderhoudt een set “compliance-Skills” die direct kan worden opgeroepen bij onboarding van nieuwe medewerkers of bij overstap tussen teams — compliance-kennis wordt zo omgezet van “documentatie” naar “uitvoerbare tools”.

Typisch scenario: Een regionale bank lanceerde in H1 2026 CI-compliancepoortwachters en IDE-compliancemeldingen, waarmee de gemiddelde tijd voor AI-code-compliancebeoordeling per persoon werd teruggebracht van 45 minuten per beoordeling naar 8 minuten per beoordeling. De kern is niet dat compliance-“beoordeling sneller gaat”, maar dat AI bij het genereren al “geen fouten maakt”.

5.3 Tweesneldheidscompliance: gelaagde afstemming op het bedrijfstempo

Het laatste detail: compliance moet niet met één maat worden gemeten. Verdeel de regels in twee niveaus op basis van risico:

Hoogrisicoregels (met betrekking tot klantgelden / algoritmische beslissingen / grensoverschrijdende data / kernbeveiligingsnormen) volgen een strikte goedkeuringsprocedure: verplichte menselijke review + AI-bevestiging in tweede instantie + registratie bij de Change Advisory Board
Laagrisicoregels (CRUD-sjablonen / toolcode / documentatiegeneratie) volgen een selfservice-goedkeuringsprocedure: geautomatiseerde CI-checks volstaan, geen menselijke review nodig

Het control plane van Atos’ Agent 365 is in essentie deze gelaagdheid — verschillende niveaus van agents zijn gekoppeld aan verschillende governance-eisen. Door complianceregels op risico te classificeren, ervaren business teams dat compliance niet overal knelpunten oplevert.

De gezamenlijke conclusie van deze drie punten: compliance inbedden is geen extra processtap, maar een herontwerp van de structuur en prikkels van het team. Als je compliance-afdeling nog in de “achteraf controleren”-modus zit, zal de adoptie van normgedreven werken stranden op de moeilijkste fase: institutionalisering. De compliance-afdeling moet eerst transformeren, pas dan kan normgedreven werken binnen business teams soepel draaien.

6. Vragen die je misschien hebt

“We hebben al coderingsstandaarden — wat is het verschil?”

Coderingsstandaarden gaan over “hoe schrijf je code”; normgedreven werken gaat over “hoe werk je samen met AI”. Coderingsstandaarden omvatten geen: bedrijfsregels, compliance-eisen, AI-gebruiksbeleid. Normgedreven werken maakt het volledige proces van mens-AI-samenwerking expliciet; het is geen codeerstijlgids.

“Vertraagt het schrijven van richtlijnen de ontwikkelsnelheid?”

Op korte termijn wel, op lange termijn niet. De data van CodeRabbit geeft een duidelijk antwoord: onbeperkte AI-code heeft een ongeveer 1,7 keer hoger risico op defecten en 2,74 keer meer kans op beveiligingskwetsbaarheden. In de financiële sector kost één nalevingsreview en herstelwerk 2 tot 4 weken — één teruggedraaide review bespaart je genoeg tijd om een maand aan richtlijnen te schrijven. De 250 miljoen dollar die EY bespaarde, is concreet bewijs dat dit werkt als je het organiseert als een organisatorische capaciteit.

“Wat als niemand in ons team weet hoe we richtlijnen moeten schrijven?”

Je hoeft niet vanaf nul te beginnen. GitHub Spec Kit, Claude Code Superpowers en AWS Kiro bieden allemaal templates. Je hoeft alleen de regels in te vullen die specifiek zijn voor jouw organisatie — meestal zijn dat compliance- en beveiligingsregels, en die heeft de compliance- of securityafdeling allang opgeschreven. Ze staan alleen nog niet op een plek waar AI ze kan lezen.

“Er zijn zoveel AI-tools. Welke moeten we kiezen?”

Niet belangrijk. Kies gewoon wat jullie al gebruiken. De standaard is leidend, niet het tool — CLAUDE.md werkt in Claude Code, Cursor én Codex; AGENTS.md draait in de OpenAI-omgeving; constitution.md is model-onafhankelijk. Het gaat om het vastleggen van de standaard, niet om het wisselen van tools. EY rolt uit binnen het Microsoft-ecosysteem, Atos ook — het verschil in toolkeuze is slechts oppervlakkig, de uniformiteit van het governance-raamwerk is waar het echt om draait.

“In augustus 2026 treedt de EU AI Act volledig in werking — raakt dat ons?”

Ja. De EU AI Act treedt op 2 augustus 2026 volledig in werking en stelt verplichte nalevingseisen aan AI-systemen met een hoog risico (waaronder kredietverlening, verzekeringsprijzen, wervingsselectie en kritieke infrastructuur) — risicobeheer (Art. 9), datagovernance (Art. 10), documentatietransparantie (Art. 11–13), menselijk toezicht (Art. 14) en nauwkeurigheid/robuustheid (Art. 15). De boetes kunnen oplopen tot 35 miljoen euro of 7% van de wereldwijde omzet. Voor Chinese bedrijven die internationaal opereren, is de Europese markt een verplichte opgave; voor binnenlandse bedrijven geldt dat het raamwerk van de EU AI Act wereldwijd het meest wordt gerefereerd als standaard — je kunt er misschien niet direct onder vallen, maar je ontkomt er moeilijk aan dat het doorwerkt naar je leveranciers, partners en grensoverschrijdende activiteiten (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

“Nationaal contrast: Europa reguleert AI — wat regelen wij?”

In China draait de governance van generatieve AI om een drietrapsraket: “algoritmeregistratie + datacorpusbeoordeling + veiligheidsevaluatie”, met de Tussentijdse Maatregelen voor het Beheer van Generatieve AI-diensten (van kracht sinds augustus 2023) als centrale pijler. Het grootste verschil tussen beide systemen zit niet in de detaillering van de bepalingen, maar in de reguleringsfilosofie:

Dimensie	EU AI Act	Chinese Mededeling over het Beheer van Generative AI-diensten
Juridische status	Horizontale wetgeving (van toepassing op alle AI-systemen)	Verticale regels (gericht op generatieve AI-diensten)
Risicoclassificatie	4 niveaus (onaanvaardbaar / hoog / beperkt / minimaal)	2 niveaus (gerelateerd aan publieke opinieveiligheid / algemeen commercieel gebruik)
Toezichtsmoment	Vooraf (registratie al bij ontwikkeling)	Achteraf (registratie na lancering + algoritme-registratie)
Transparantie	Hoog (vereist openbaarmaking van samenvatting van trainingsdatabronnen, modelkaarten)	Gemiddeld (vereist compliance van trainingsdata, maar geen verplichte openbaarmaking van bronnen)
Maximale boete	7% van wereldwijde omzet of €35 miljoen	Opschorting van dienst / boete (doorgaans een veelvoud van illegaal verkregen winst)
Toepassingsbereik	Alle bedrijven binnen de wereldwijde omzetdrempel	Alle entiteiten die diensten aanbieden binnen China

In de praktijk worden AI-systemen van financiële instellingen in China doorgaans door drie regelgevingskaders tegelijk gebonden — de Generatieve AI-beheermaatregelen (basellaag) + de Regeling voor internetleningen door commerciële banken (bedrijfslaag) + de Dengbao-beoordeling (classificatiebeveiligingstest) + algoritmeregistratie (nalevingslaag). Dit betekent dat je voor een regelgedreven aanpak in China het EU AI Act-kader niet klakkeloos kunt kopiëren; je moet de drie binnenlandse lijnen — “corpus-compliance + algoritmeregistratie + toezichtsrapportage” — allemaal in CLAUDE.md verwerken.

Voor bedrijven die internationaal opereren: de vier pijlers van de EU AI Act — “risicobeheer + datagovernance + documentatietransparantie + menselijk toezicht” — zijn ook de richting waar de Chinese toezichthouder geleidelijk naartoe beweegt. De terugkoppelingen op generatieve AI-registraties van de CAC (Cyberspace Administration of China) in 2025 leunen al merkbaar op de granulariteit van de EU-aanpak. Wie vandaag een EU AI Act-compatibele standaard schrijft, zit over drie jaar vrijwel zeker ook goed bij de aanscherpende Chinese regelgeving (CAC-registratieaankondigingen 2025–2026; eu-ai-act compliance 2026.6).

7. Lessen voor beslissers

Les één: het schrijven van een CLAUDE.md/AGENTS.md-projectstandaard is de engineering-actie met het hoogste ROI in het AI-tijdperk.

De investering is 3–8 weken ordeningstijd + 1–2 weken documentatietijd. De opbrengst: een bovengrens van circa 1,7× op defectrisico, 2,74× minder beveiligingskwetsbaarheden, en meer dan 40% minder herbewerking. In de financiële sector dekt één bespaarde compliance-reviewcyclus (2–4 weken) al deze kosten. EY heeft met 150.000 medewerkers op Copilot 250 miljoen dollar bespaard — maar alleen omdat er eerst duidelijke standaarden waren.

Inzicht 2: Standaardgedreven werken is een organisatorisch vermogen, geen toolkeuze.

Of je nu kiest voor GitHub Spec Kit of Claude Code maakt niet uit. Waar het om gaat: heb je gedefinieerd hoe jouw organisatie met AI samenwerkt? Zonder die definitie laat je met het beste gereedschap alleen maar sneller meer technische schuld ontstaan.

Inzicht 3: Leg standaarden vast in organisatieprocessen, niet bij individuen.

Als een standaard alleen in het hoofd van een senior engineer zit, is hij weg zodra die persoon vertrekt. Je moet hem vastleggen in repository-documentatie, CI-gates, gedeelde teamconfiguratie en agent-governanceplatforms. Maak van standaarden een organisatorisch bezit, geen persoonlijke vaardigheid. Atos draait met 19.000 agents in 54 landen, omdat governance daar geen kwestie is van ‘iemand die het snapt’, maar van ‘het systeem dat het afdwingt’.

Inzicht 4: Gates zijn belangrijker dan snelheid.

GitHub Spec Kit’s five-phase gating, Superpowers’ “no code before a failing test,” Kiro’s “can’t start without a spec”—all of these put a brake between AI and the final output. The more capable AI becomes, the earlier governance needs to kick in. The 78% incident rate in the New Relic 2026 report is the price paid by the 62% of teams that ship without review. CIOs in financial services know this better than anyone: your Change Advisory Board (CAB), your algorithm filing process, your MLPS assessments—all of these are gates before production. AI-generated code needs the same kind of gating, and it has to sit even earlier in the pipeline.

Reverse self-check (no sugarcoating): How often does compliance review bounce back AI-generated code? What was the last incident caused by AI-written code? If you ask your tech lead “how do we collaborate with AI,” can they produce a document on the spot? If you can’t answer even one of these three, spec-driven development hasn’t landed yet—write the spec first, buy the tools second.

Three coaching questions for decision-makers

Three questions to close with—not a checklist, but something you can use directly in your next conversation with your team:

“Als alle AI-tools morgen zouden verdwijnen, hoeveel zou de kwaliteit van jullie code dan dalen?” — Deze vraag legt de werkelijke waarde van specificatiegedreven ontwikkeling bloot: als het antwoord “aanzienlijk” is, zijn jullie specificaties nog niet voldoende verankerd; als het antwoord “vrijwel ongewijzigd” is, draait specificatiegedreven ontwikkeling al op volle toeren.
“Is compliance binnen jullie specificatiegedreven project een ‘poortwachter’ of een ‘enabler’?” — Als het antwoord “poortwachter” is, wordt jullie implementatiesnelheid geflest door review-flessenhalzen; als het antwoord “enabler” is, volgen jullie al de juiste route uit sectie 5.2.
“Hoe zal de omvang van jullie team over 12–18 maanden veranderen?” — Microsofts WTI 2026 geeft als antwoord dat 82% van de leiders AI-agenten zal inzetten om het personeelsbestand te “schalen”. Als jullie antwoord “ongewijzigd” is, groeit je bedrijf niet, of blijft je organisatieontwerp achter bij de voordelen van specificatiegedreven ontwikkeling.

Er zijn geen standaardantwoorden op deze drie vragen. Maar de richting van het antwoord is belangrijker dan het antwoord zelf.

Volgende stap

Dit is het zesde deel in de serie “Software-engineering in transitie in het AI-tijdperk”. Van Conway (organisatie bepaalt architectuur) naar Team Topologies (hoe ontwerp je organisaties), naar de verschuiving van de bottleneck (de bottleneck ligt bij validatie, niet bij codering), en vandaag over specificatiegedreven ontwikkeling (documentatie als sturingsmechanisme voor AI-gedrag).

In het volgende (zevende) deel bekijken we de onderliggende infrastructuur die dit alles mogelijk maakt: het MCP-protocol (Model Context Protocol). Waarom het door Anthropic geopenbaarde protocol wordt omschreven als ‘de USB-C van AI’, waarom OpenAI, Google en Microsoft allemaal zijn gevolgd, en hoe het interoperabiliteit tussen meerdere tools en meerdere agents mogelijk maakt.

Wil je dit gedachtegoed binnen jouw organisatie toepassen?

Wanneer normgedreven ontwikkeling zijn intrede doet in een bedrijf, draait het meestal om een paar concrete vraagstukken: hoe leg je de kernregels vast in CLAUDE.md / AGENTS.md, hoe breng je bestaande code in lijn met de normen, hoe integreer je compliance, en met welke indicatoren evalueer je de pilot.

We bieden drie vormen van samenwerking aan:

Interne training: aan de hand van de echte projecten van jouw bedrijf werken we aan het opstellen van normdocumentatie, het ontwerpen van CI-gates, het inbedden van compliance en het opzetten van governancemechanismen.
Gericht adviestraject: gericht op één concrete beslissing, zoals ‘moeten wij eerst CLAUDE.md / AGENTS.md opstellen?’ of de prioritering van compliance-aanpassingen in bestaande code.
Managementpresentaties en lezingen: over AI-programmeertools, normgedreven ontwikkeling, organisatorische governance en Frontier Firms.

Artikelen kunnen een algemeen raamwerk bieden, maar concrete implementatie vereist maatwerk op basis van de compliance-eisen, regelgevingsgrenzen, technische volwassenheid en bestaande delivery-processen van uw organisatie. Voor samenwerking kunt u contact opnemen via coach@iaiuse.com.

Verder lezen: “Zie de merkrichtlijnen v1.0” (Langzaam AI leren 187), een systematische introductie van het 7-stappenkader voor AI-transformatie in bedrijven.

Over deze serie

“Software-engineering in het AI-tijdperk” is een onderzoeksreeks voor CIO’s, CDO’s, CTO’s en digitaliseringsverantwoordelijken in sectoren zoals telecom, financiën, productie en e-commerce. De serie omvat 18 delen en richt zich op hoe AI-programmeertools, normgedreven ontwikkeling en organisatorisch bestuur van invloed zijn op softwareleveringsprocessen, organisatiestructuren en technische volwassenheid.

De serie volgt voortdurend academische papers, leveranciersdocumentatie en brancherapporten. De onderzoeksdatabase bevat inmiddels meer dan 200 bronnen, en bij elke belangrijke conclusie wordt het bewijsniveau aangegeven, met een duidelijk onderscheid tussen geverifieerde feiten, leveranciersclaims, sectorobservaties en de eigen redenering van de auteur.

Ik heb bijna 8 jaar ervaring in consultancy en businessanalyse voor grote ondernemingen, onder meer bij IBM, waar ik betrokken was bij projecten in telecom, financiën, verzekeringen en productie. Daarna ben ik actief geweest in de frontlinie van productontwikkeling voor telecomoperators, internetproducten en AI-toepassingen, met focus op requirementsanalyse, productontwerp en cross-functionele implementatie.

Deze serie over normgedreven bestuur, organisatorische governance en engineering-oordelen is gebaseerd op deze praktijkervaringen, gekruist met publiek beschikbaar onderzoek en branchecases. Alle projectdetails zijn geanonimiseerd; sommige branchescenario’s betreffen typerende probleemanalyses. De onderbouwing staat in de referenties onderaan.

Achter deze nieuwsbrief zit eigenlijk een klein team — ik en 1-2 collega’s met wie ik langdurig samenwerk. We verdelen het werk over AI-programmeertools-onderzoek, organisatorische governance-casestudies en coachingsgesprekken. De meeste projecten waar we in de teksten “met bedrijven doorheen zijn gegaan”, hebben we samen opgeleverd. Cliëntgerelateerde compliancegrenzen en namen blijven onvermeld; de anonimiteit blijft behouden om ruimte te laten voor toekomstige samenwerkingscollega’s.

Referenties (alle geverifieerd, met per item de bewijsklasse vermeld)

CodeRabbit (2025.12). State of AI vs Human Code Generation Report. AI-gegenereerde code bevat 1,7 keer meer problemen dan door mensen geschreven code (10,83 vs 6,45 problemen per pull request), logica/correctheid 1,75×, codekwaliteit 1,64×, beveiliging 1,57×, wachtwoordverwerking 1,88×, XSS 2,74×. Bewijsniveau: primair. Bron: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263
The Register (2025.12.17). Verslag over het volledige CodeRabbit-rapport: analyse van 470 open-source pull requests, AI-ondersteunde PR’s bevatten 10,83 problemen versus 6,45 bij puur menselijke code. Bewijsniveau: secundair. Bron: zelfde URL als hierboven
CodeRabbit / David Loker (2026.1). “2026 Predictions: The Speed Trap” — 2026 wordt het keerpunt van “snelheid van codegeneratie” naar “codekwaliteit en governance”. Bewijsniveau: secundair. Bron: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report. 78% van de teams ervaart meer incidenten na het live gaan van AI-code; 62% van de technisch leiders geeft toe dat hun team AI-code “vol vertrouwen zonder review” uitrolt; 96% vindt observeerbaarheid essentieel. Bewijsniveau: primair (leveranciersrapport). Bron: https://newrelic.com/resources/report/2026-state-of-ai-coding
Microsoft 2026 Work Trend Index Annual Report (2026.5.5). Een enquête onder 20.000 AI-werknemers, verspreid over 10 landen; 82% van de leiders is van plan om binnen 12-18 maanden AI-agents in te zetten om hun personeelsbestand uit te breiden; 81% verwacht een matige tot grote integratie van AI-agents; 24% heeft al een implementatie op bedrijfsniveau; 49% van de Copilot-gesprekken ondersteunt cognitief werk; 58% van de AI-gebruikers doet “dingen die een jaar geleden onmogelijk waren”, en onder Frontier Professionals stijgt dit percentage naar 80%. Bewijsniveau: niveau één. Bron: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Microsoft FY26-terugblik: van AI-experimenten naar baanbrekende transformatie (28-07-2026). EY rolt Microsoft 365 Copilot uit naar 150.000 medewerkers, wat 2,5 miljoen uur en circa 250 miljoen dollar bespaart; de uitbreiding naar 400.000 wereldwijde medewerkers levert 95% versnelling, 37% lagere financiële operationele kosten en tot 90% minder handmatige workflows op. Atos implementeert Copilot bij 56.000 medewerkers in 56 landen, plus 19.000 AI-agents, met een uniform besturingsvlak voor identiteit, beveiliging, compliance en governance. Bewijsniveau: niveau 1 (officiële Microsoft-terugblik). Bron: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Group en Microsoft Strategische Samenwerking (2026.6.9). Atos implementeert Microsoft 365 E7 (Frontier Suite) voor 56.000 medewerkers in 56 landen, plus 19.000 AI-agents; met een uniform controleplatform voor Entra/Defender/Intune/Purview/Agent 365. Bewijsniveau: niveau één (gezamenlijk persbericht). Bron: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (open source in Sept 2025, evolving through H1 2026). Five-stage gating /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; model-agnostic (works with Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code). Evidence level: primary. Source: https://github.com/github/spec-kit
AWS Kiro (released July 2025, evolving through H1 2026). Three-stage workflow: requirements → design → tasks; the spec triggers predefined agent actions; without a spec, you can’t even start. Evidence level: primary. Source: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025-2026). Codex 2026.6 wekelijks 5+ miljoen actieve gebruikers, waarvan 20% geen ontwikkelaars; AGENTS.md + Skills als combineerbare instructiesets. Bewijsniveau: niveau 1 (officiële aankondiging OpenAI). Bron: https://developers.openai.com/codex/skills
Claude Code (Anthropic, 2026 H1). CLAUDE.md + .claude/rules/ + Skills-systeem; in 2026.2 opgenomen in de officiële Anthropic-marktplaats; Skills-repository op GitHub met 112.000 sterren; in 2026.2 bekendgemaakt in G-ronde: 2,5 miljard dollar aan jaarlijkse terugkerende omzet. Bewijsniveau: niveau 1. Bron: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). Onderzoek onder 10.000+ professionele ontwikkelaars wereldwijd, gelokaliseerd in 8 talen; Claude Code CSAT 91% / NPS 54 (hoogste in de sector); Claude Code adoptie op de werkvloer 18% (6x gestegen van 3% in 9 maanden), in Noord-Amerika 24%; Copilot 29% adoptie op de werkvloer maar groei stagneert; Cursor 18%. Bewijsniveau: niveau 1. Bron: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). Onderzoek onder 15.000 ontwikkelaars; 46% kiest Claude Code als “meest geliefd”, Cursor 19%, Copilot 9%. Bewijsniveau: niveau 1. Bron: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (aug 2025 → juli 2026). In augustus 2025 uitgebracht door Alibaba; op 15 mei 2026 is Qoder 1.0 geüpgraded naar een Autonomous Agent Development Workbench; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; op 28 mei 2026 Cloud Agents (managed agent runtime); op 21 juli 2026 Qoder Security; in mei 2026 wereldwijd meer dan 5 miljoen gebruikers; integratie met DingTalk CLI; op 20 mei 2026 is Tongyi Lingma hernoemd naar Qoder CN. Bewijsniveau: primair. Bron: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525
vibecoding.app / thebcms.com / tfir.io (2026 H1). Spec Kit-commando’s in vijf fasen, vergelijkende evaluatie van SDD-tools, EARS-notatiemethode. Bewijsniveau: niveau twee (evaluatie door derden). Bron: https://vibecoding.app/blog/spec-kit-review; https://thebcms.com/blog/spec-driven-development
EU AI Act / Code of Practice (volledig van kracht vanaf 2 augustus 2026). De nalevingsdeadline voor AI-systemen met een hoog risico is 2 augustus 2026; bestaande GPAI-modellen hebben uitstel tot 2 augustus 2027; boetes tot 35 miljoen euro of 7% van de wereldwijde omzet; Art. 9-15 betreffen risicobeheer, datagovernance, documentatietransparantie, menselijk toezicht en nauwkeurigheid/robuustheid. Bewijsniveau: niveau één (wetgeving + secundaire nalevingsanalyse). Bron: https://artificialintelligenceact.eu/code-of-practice-overview; https://www.surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide
Qodo State of AI Code Quality Report (2025). 44% van de problemen is terug te voeren op ontbrekende context. Bewijsniveau: niveau twee (leveranciersrapport). Bron: https://www.qodo.ai/reports/state-of-ai-code-quality/

Slowly leren AI: De toekomst van AI in de telecom, financiële en manufacturingsector

Als CIO of besluitvormer in de telecom, financiële of manufacturingsector, bent u waarschijnlijk geconfronteerd met de uitdagingen van de toepassing van Artificial Intelligence (AI). In dit artikel zullen we de toekomst van AI in deze sectoren bespreken en enkele voorbeelden geven van hoe AI kan worden toegepast.

Wat is AI?

AI is een breed begrip dat omvat alle technologieën die computers in staat stellen om te leren en te handelen op basis van gegevens. AI kan worden ingedeeld in verschillende categorieën, waaronder Machine Learning (ML), Natural Language Processing (NLP) en Computer Vision.

Toepassingen van AI in de telecomsector

In de telecomsector kan AI worden toegepast op verschillende manieren, zoals:

Predictief onderhoud: AI kan worden gebruikt om te voorspellen wanneer apparaten uitvallen of hoeveel capaciteit nodig is om te voldoen aan de vraag.
Klantenservice: AI kan worden gebruikt om klanten te helpen met hun vragen en problemen.
Netwerkbeheer: AI kan worden gebruikt om netwerken te beheren en te optimaliseren.

Toepassingen van AI in de financiële sector

In de financiële sector kan AI worden toegepast op verschillende manieren, zoals:

Risicobeheer: AI kan worden gebruikt om risico’s te identificeren en te beheersen.
Kredietbeoordeling: AI kan worden gebruikt om kredietbeoordelingen te doen en te optimaliseren.
Transactiebeheer: AI kan worden gebruikt om transacties te beheren en te optimaliseren.

Toepassingen van AI in de manufacturingsector

In de manufacturingsector kan AI worden toegepast op verschillende manieren, zoals:

Productieplanning: AI kan worden gebruikt om productieplanningen te doen en te optimaliseren.
Kwaliteitscontrole: AI kan worden gebruikt om kwaliteitscontroles te doen en te optimaliseren.
Logistiek: AI kan worden gebruikt om logistieke processen te beheren en te optimaliseren.

Een voorbeeld van AI-toepassing

Een voorbeeld van AI-toepassing is de toepassing van AI in de telecomsector door AT&T. AT&T heeft AI gebruikt om te voorspellen wanneer apparaten uitvallen en hoeveel capaciteit nodig is om te voldoen aan de vraag. Dit heeft geleid tot een verbetering van de kwaliteit van de dienstverlening en een vermindering van de kosten.

Conclusie

AI is een krachtig hulpmiddel dat kan worden gebruikt om de prestaties van organisaties in de telecom, financiële en manufacturingsector te verbeteren. Door AI toe te passen op verschillende manieren, zoals predictief onderhoud, klantenservice, netwerkbeheer, risicobeheer, kredietbeoordeling, transactiebeheer, productieplanning, kwaliteitscontrole en logistiek, kunnen organisaties hun prestaties verbeteren en hun kosten verlagen.

Bronnen

AT&T: www.att.com
Verizon: www.verizon.com
NTT: www.ntt.co.jp
Deutsche Telekom: www.telekom.com
Telefónica: www.telefonica.com
Vodafone: www.vodafone.com

Aanbevelingen

Lees meer over AI en zijn toepassingen in de telecom, financiële en manufacturingsector.
Overweeg om AI toe te passen in uw organisatie.
Lees meer over de resultaten van AI-toepassingen in de telecom, financiële en manufacturingsector.