ORGANISATIE9 min leestijd23 maart 2026

Waarom je bedrijf AI niet adopteert (en wat eraan te doen)

Het bedrijf zelf kan, met gemak, volledig onbewust, zo georganiseerd zijn dat het ondanks de wil niet in staat is om te bewegen. Vijf structurele blokkades die AI-adoptie tegenhouden.

Ik heb gedurende mijn carrière, mede door het freelancen, aardig wat bedrijven van binnen mogen zien. Ieder bedrijf is een soort stam met eigen verhoudingen in macht. De energie van de eigenaar bepaalt voor een groot deel hoe de stam vormt. Is de baas onverschillig? Dan is het bedrijf dat ook. Is de baas een controlfreak? Iedereen loopt op zijn tenen. Is de baas chaotisch? Dan zijn de producten dat ook.

Bedrijven hebben eigen rituelen en een eigen sfeer die volstrekt uniek is. Dat maakt het ook heel begrijpelijk waarom van binnenuit de stam bepaalde dingen onzichtbaar zijn. Hieronder vijf structurele blokkades die ik overal tegenkom.

1. De sprint-gevangenis

Geen ruimte om te experimenteren. Iedere twee weken moet er iets opgeleverd worden, en alles wat niet direct bijdraagt aan de velocity is afleiding. Leren? Dat doe je maar in je eigen tijd. Onderzoeken? Schrijf maar een ticket, dan plannen we het in over drie sprints.

Dit systeem is ooit bedacht om chaos te temmen. Maar ergens onderweg is het een gevangenis geworden. De ironie: de sprint zou wendbaarheid moeten brengen, maar blokkeert nu de grootste wendbaarheid die er is.

Mijn vermoeden is dat de sprint fundamenteel incompatibel is met AI-assisted development. Waar je met een sprint probeert te voorkomen dat dingen enorm uit de hand lopen, is dat probleem veel minder groot geworden. Een feature bouwen is gewoon minder tijdrovend en moeilijk geworden, waarmee de hele redenen die aan het fundament liggen van een scrum-werkwijze wegvallen.

Ik zeg niet dat je morgen scrum moet afschaffen. Maar het zou goed zijn om te erkennen dat de methodologie die je gebruikt ontworpen is voor een wereld die aan het verdwijnen is.

2. De compliance-muur

“We mogen geen externe AI-tools gebruiken.” Punt. Geen discussie. Security, GDPR, IP-risico’s, de code lekt naar OpenAI. De redenen stapelen zich op. En eerlijk, sommige zorgen zijn legitiem. Je wilt niet dat bedrijfsgevoelige code in een trainingsset belandt. Prima. Ik snap dat.

Maar laten we eerlijk zijn over wat hier vaak echt aan de hand is. Die muur is niet gebouwd op een echte risicoanalyse. Er is niemand gaan zitten om uit te zoeken wat de daadwerkelijke risico’s zijn. De muur is gebouwd op angst, onzekerheid, en het gemak van “nee” zeggen. Want “nee” is veilig. “Nee” hoef je niet te verdedigen.

Ondertussen zijn er allang oplossingen. Lokale modellen die volledig op je eigen infrastructuur draaien. Enterprise agreements met strikte data-policies. Self-hosted opties voor wie het echt zelf in de hand wil houden.

De vraag is niet of het veilig kan. De vraag is of iemand de moeite neemt om het uit te zoeken. En terwijl het bedrijf wacht op een perfecte, goedgekeurde, door alle lagen gevalideerde oplossing, zijn de concurrenten al drie straten verder.

3. De meetcultuur

Velocity. Story points. Lines of code. Pull requests per week. Alles wordt gemeten, want wat je meet kun je managen. Toch?

Maar AI past niet in deze metrics. Stel je voor dat je een probleem oplost in een uur waar je normaal een dag over deed. Fantastisch toch? Nee. Je velocity daalt. Je output in story points zakt. Op papier presteer je slechter. De grafiekjes gaan de verkeerde kant op. En niemand vraagt zich af of je misschien gewoon efficiënter bent gaan werken.

Of erger nog: je besteedt een ochtend aan het leren werken met een nieuwe tool. Je experimenteert, je leest documentatie, je probeert dingen uit. Nul output. Nul punten. Rode vlaggen in het dashboard. De volgende standup moet je uitleggen waarom je “niks” gedaan hebt. Terwijl wat je deed misschien wel het belangrijkste was wat je die week kon doen.

De meetcultuur straft innovatie af. Het beloont voorspelbaar stampwerk en zichtbare drukte. Het beloont degene die binnen de lijntjes kleurt, niet degene die vraagt of we misschien andere lijntjes nodig hebben.

4. De kennissilo

In veel teams zit er een iemand die alles weet. De held. Degene die je belt als het echt mis is. Het probleem is niet de held zelf. Het probleem is wat er om hem heen ontstaat. Langzaam, ongemerkt, groeit er een cultuur waar kennis macht is. Waar status komt door dingen te weten die anderen niet weten. Waar vragen stellen een teken van zwakte is.

In zo’n cultuur is AI een bedreiging. Want AI democratiseert kennis. Ineens kan de junior die net twee maanden binnen is ook dit complexe probleem oplossen, omdat hij het gewoon aan Claude vraagt en een bruikbaar antwoord krijgt. Ineens is die held een stukje minder onmisbaar. Ineens is al die opgespaarde kennis, al die jaren van context verzamelen, niet meer het monopolie dat het was.

En dan ontstaat er iets geks. Als je goed bent wanneer je bent zoals de held, en de held gebruikt geen AI, dan gebruik jij het ook niet. Niet omdat je er bewust over nagedacht hebt. Maar omdat de sociale dynamiek in het team dicteert wat acceptabel is en wat niet.

Niemand zegt dit hardop. Maar iedereen voelt het.

5. De angstcultuur

Fouten maken is niet veilig. Dat hoeft niemand te zeggen. Je voelt het. Je voelt het in hoe er gereageerd wordt als iets misgaat. In de stilte die valt als een deploy faalt. In wie de schuld krijgt en hoe snel die schuld toegewezen wordt. Je leert het snel: kop naar beneden, geen risico’s nemen.

AI-assisted development betekent experimenteren. Het betekent dingen proberen die niet meteen werken. Het betekent code genereren die je moet reviewen, aanpassen, soms volledig weggooien. Het betekent fouten maken. Veel fouten. Zo leer je waar de grenzen liggen.

Maar in een angstcultuur doe je dat niet. Je doet wat je weet dat werkt. Je gebruikt de patronen die bewezen zijn. Stel je voor dat die AI-gegenereerde code een bug veroorzaakt in productie. Wie krijgt de schuld? Niet de AI. Die heeft geen functioneringsgesprek. Jij wel.

Innovatie vereist veiligheid om te falen. Het vereist een omgeving waar je kunt zeggen: ik heb iets geprobeerd en het werkte niet, en dat de reactie is: “Interessant, wat heb je geleerd?” In plaats van: “Hoe heeft dit kunnen gebeuren?”

Zonder die veiligheid verandert er niks. Dan blijft iedereen doen wat ze altijd al deden. En vraagt de directie zich af waarom die AI-transitie maar niet van de grond komt.

Waar staan we?

Bij de developer is de weerstand persoonlijk. Bij het bedrijf is het structureel. Beide zijn begrijpelijk, beide zijn echt.

En onder dat alles zit liminaliteit. We staan op een drempel. Het oude werkt niet meer helemaal, het nieuwe is er nog niet. Dat is ongemakkelijk, maar het is ook precies waar verandering begint.

De vraag is nu: wat doe je ermee? Die vraag ziet er anders uit afhankelijk van waar je staat. Ben je een developer die voor zichzelf wil uitzoeken wat AI voor je kan betekenen? Of ben je verantwoordelijk voor een team, een afdeling, een bedrijf dat deze stap moet maken? De obstakels zijn anders. De startpunten zijn anders.

Lees het hele boek

Door de weerstand: een pragmatische kijk op AI-assisted development

Dit artikel is een hoofdstuk uit het boek. Wil je het hele verhaal lezen, inclusief de archetypen en de praktische startpunten? Vraag het boek aan en ik stuur het je persoonlijk per email.

Vraag het boek aan →

Over de auteur

Dion Snoeijen is founder van PolySynergy en heeft 20+ jaar ervaring met softwareontwikkeling. Sinds 2024 werkt hij volledig AI-Assisted en bouwt hij custom software waarin AI als versterker is geïntegreerd.