5 veelvoorkomende patronen die AI-falen veroorzaken

Adam Horner heeft technologieteams opgebouwd binnen fintech en bedrijfssoftware. Hij is nu de oprichter van The CTO Playbook, waar hij kennis overdraagt en werkt als parttime CTO.

We spraken met hem om te ontdekken welke patronen hij ziet achter de successen en mislukkingen bij AI-integratie. Dit vertelde hij ons.

Een variant van dezelfde uitdaging

Ik ben Adam Horner, CTO-coach en parttime CTO bij The CTO Playbook. Het eerste deel van mijn loopbaan bracht ik door als ingenieur en medeoprichtend CTO, waarbij ik technologieteams opbouwde en aanstuurde binnen fintech en bedrijfssoftware. Daaronder vielen ook meerdere jaren bij Palantir, als een van hun eerste medewerkers in het Verenigd Koninkrijk.

De overstap naar coaching kwam voort uit een eenvoudige observatie: een effectieve technologie-executive worden is echt moeilijk, en de meeste mensen bewandelen dat pad zonder routekaart of iemand aan hun zijde die het al heeft meegemaakt. Dat is het werk dat ik nu doe: CTO's helpen de kloof te overbruggen die ik de CTO-kloof noem.

De AI-invalshoek is voor mij geen afzonderlijk onderwerp. Die loopt door bijna elk coachingsgesprek dat ik voer, omdat elke CTO met wie ik werk een variant van dezelfde uitdaging aangaat: hoe leid je een organisatie door een transformatie van deze omvang, in jouw specifieke fase, met jouw specifieke team, en kom je daaruit als een sterker bedrijf?

Het rommelige midden van de groeicurve

Mijn eigen organisatie is klein en bewust slank. We zijn een oprichtersteam van vier dat volledig met AI als uitgangspunt werkt en die ervaring gebruikt om dicht bij de realiteit van productontwikkeling in een vroeg stadium te blijven. Daarnaast werk ik als parttime CTO bij een fintech-start-up die nog geen accreditatie heeft en die de specifieke druk ervaart van het op de markt brengen van een gereguleerd product met een extern bouwteam.

Maar het bredere beeld, en waar de echte diepgang van de organisatorische blootstelling vandaan komt, wordt gevormd door de CTO's die ik coach. Dat varieert van oprichtersteams en vroege startups die uit eigen middelen zijn opgebouwd, via snelgroeiende bedrijven met steun van durfkapitaal en private equity, tot middelgrote bedrijven die echte organisatorische complexiteit beheersen, en grote ondernemingen met meerdere afdelingen die op schaal opereren.

Het rommelige midden van de groeicurve is waar ik het grootste deel van mijn tijd aan besteed, en daar zijn de leiderschapsuitdagingen doorgaans het scherpst.

Hoe AI ingenieurs naar het grotere geheel laat kijken

Voor mij is de belangrijkste verandering geen hulpmiddel of proces geweest, maar een verwachting. Wanneer je als leider het team toestemming geeft — en, nog belangrijker, de verplichting oplegt — om de volledige leveringslevenscyclus vanaf de basis opnieuw te beoordelen, doet de reikwijdte van die herbeoordeling ertoe. Niet alleen hoe code wordt geschreven of geïmplementeerd, maar alles wat het leveringsproces raakt: klantenondersteuning, klantwaarde en de bedrijfsdoelstelling achter een bepaald onderdeel van het werk.

Toen de kosten voor het schrijven en onderhouden van code hoog waren, was het tot op zekere hoogte logisch om ingenieurs strak op het technische probleem gericht te houden. Maar die kosten zijn sterk gedaald. De beperkende factor is niet langer hoe snel je kunt bouwen, maar hoe duidelijk iedereen die erbij betrokken is begrijpt wat daadwerkelijk de moeite waard is om te bouwen en waarom.

Ingenieurs die het product, de klant en de bedrijfsdoelen achter een verandering begrijpen, kunnen beslissingen nemen en handelen op manieren die eerder simpelweg niet mogelijk waren. Wat verbeterde, was geen metriek. Het was de kwaliteit van de vragen die het team begon te stellen voordat er ook maar één regel code werd geschreven.

Adam's gedachten

De beperkende factor is niet langer hoe snel je kunt bouwen, maar hoe duidelijk iedereen die erbij betrokken is begrijpt wat daadwerkelijk de moeite waard is om te bouwen en waarom.

Hoe triage- en herstelcycli met AI kunnen worden verkort

Een voorbeeld betrof het opnieuw nadenken over de manier waarop klantenondersteuning en engineering samenwerkten rond bevestigde softwarefouten. Voorheen werden triage- en herstelcycli gemeten in dagen of weken. Ondersteuningsteams moesten in de tussentijd gefrustreerde klanten te woord staan, terwijl ingenieurs naast hun andere werkzaamheden ook de afleidingskosten van actuele problemen moesten dragen. Toen de leveringslevenscyclus opnieuw werd beoordeeld met AI-ondersteunde ontwikkeling in beeld, werden herstelcycli drastisch verkort en werd een groot deel van het proces geautomatiseerd.

Vooraf kwam er meer werk bij de ondersteuningsfunctie te liggen: problemen moesten duidelijk worden vastgelegd en gecategoriseerd. Maar de winst was dat ze in uren in plaats van dagen werden opgelost. Ingenieurs konden gefocust blijven. Klanten kregen sneller antwoord. De samenwerking tussen twee functies die altijd simpelweg als traag was geaccepteerd, bleek volledig opnieuw onderhandelbaar.

Waarom organisaties niet overal AI op moeten loslaten

Wat een menselijke taak zou moeten zijn en wat een AI-taak, verschilt per organisatie. Het juiste startpunt is niet een lijst met activiteiten, maar een duidelijk begrip van waar je waarde zit en waar je risico geconcentreerd is.

De onderdelen van het proces die centraal staan in wat het bedrijf doet — de logica, het onderscheidend vermogen, de gebieden waar fouten zichtbaar of kostbaar zijn — rechtvaardigen menselijke uitvoering en menselijk toezicht. Al het andere bevindt zich op een spectrum.

Een cybersecuritybedrijf zal veel menselijke aandacht besteden aan de beveiligingseigenschappen van zijn code, omdat dat de kern van het bedrijf is. Een bedrijf voor workflowautomatisering kan diezelfde grondigheid richten op de besluitvormingslogica binnen een kritieke workflow, terwijl het beveiligingstools beschouwt als iets wat AI voldoende goed kan afhandelen.

Wat verkeerd is, is het toepassen van een algemeen beleid in een van beide richtingen. De vraag die je moet stellen is niet: "Kan AI dit?" maar: "Wat zijn de kosten als dit misgaat?"

En nog iets: Een verrassend groot deel van de complexiteit die mensen willen automatiseren, is in feite onopgeloste processchuld. Los dat eerst op. Daardoor wordt het later eenvoudiger en goedkoper om AI te implementeren.

Adam deelt

Het juiste startpunt is niet een lijst met activiteiten, maar een duidelijk begrip van waar je waarde zit en waar je risico geconcentreerd is.

Waarom CTO's moeten beginnen met het automatiseren van oplevering, niet van code

Het is echt moeilijk om AI-resultaten tussen organisaties te vergelijken, omdat de meeste leiders, zowel binnen de technologie als in het bredere bedrijf, nog steeds moeite hebben om de impact en ROI van hun AI-investeringen duidelijk te meten. Zonder dat is het moeilijk om te weten hoe goed succes er daadwerkelijk uitziet, en nog moeilijker om te pleiten voor meer van dergelijke investeringen.

Maar over het geheel genomen loopt het bereik van AI-resultaten sterk uiteen. Aan de ene kant heb ik gewerkt met organisaties die hun achterstand effectief hebben weggewerkt en nu rechtstreeks werken aan klantwaarde en bedrijfsdoelstellingen. Dat vormt een fundamentele verandering in de manier waarop techniek zich verhoudt tot de rest van het bedrijf.

Ik zag een gemeenschappelijk patroon bij de organisaties die dit bereikten: geen enkele begon aan de linkerkant van de levenscyclus van softwareontwikkeling. Ze begonnen niet met het genereren van code. Ze begonnen rechts: CI/CD-pijplijnen, vertrouwen in implementaties en geautomatiseerde codebeoordeling. Eerst het opleveringsgedeelte van het proces robuust en betrouwbaar maken, creëerde de voorwaarden voor al het andere. Van daaruit verschoof de focus naar tests, beperkingen en controles vóór het genereren, en naar structuur in plaats van snelheid.

De teams die de meeste vooruitgang boekten, waren de teams die het meest autonoom opereerden — niet omdat ze menselijk inzicht hadden verwijderd, maar omdat ze er genoeg van in hun proces hadden vastgelegd om met vertrouwen aanzienlijk grotere stukken werk op zich te nemen. De achterstand verdween niet omdat ze sneller code schreven. Die verdween omdat de volledige relatie tussen intentie en oplevering ondubbelzinnig werd.

Aan de andere kant heb ik gezien dat er daadwerkelijk medewerkers vertrokken door de groeiende kloof tussen degenen die snel met AI vooruitgaan en degenen die dat niet doen. Wanneer AI-implementatie begint, is er bijna altijd een kleine groep die snel beweegt en een grotere groep die dat niet doet. Het natuurlijke instinct is dan om de snelle groep haar gang te laten gaan. Wat dat stilletjes en snel creëert, is wrijving, wantrouwen en achterdocht tussen teams, waardoor de winst sneller erodeert dan de vroege vooruitgang zich kan opstapelen. Het advies dat ik nu aan het begin van iedere samenwerking geef, is hetzelfde: laat niemand achter. Het tempo van de implementatie moet worden bepaald door hoe snel je de hele organisatie kunt meenemen, niet door hoe snel je meest enthousiaste technici individueel kunnen bewegen.

Een organisatie met twee snelheden voelt vanaf de voorhoede als vooruitgang. Achteraan voelt het alsof je wordt achtergelaten, en dat gevoel heeft gevolgen.

Waarom de kennisbank van een organisatie opnieuw moet worden ontworpen voor AI

De duidelijkste tekortkoming die ik heb gezien in de mogelijkheden van AI bevindt zich in besluitvorming onder onzekerheid.

AI is in wezen een voorspellingsmachine, en voorspellen is niet hetzelfde als oordelen. AI heeft niets op het spel staan, geen besef van consequenties en geen verantwoordelijkheid voor de uitkomst. Verwachten dat AI namens jou beslissingen neemt, zal nooit beter zijn dan zijn vermogen om te voorspellen; in echt onzekere of nieuwe situaties is dat vermogen beperkt. De organisaties die het meest teleurgesteld zijn geraakt in AI, zijn meestal de organisaties die er juist op die momenten zwaar op leunden.

Het andere gebied waarop de impact tekortschiet, stiller maar net zo aanzienlijk, is waar de implicaties van contextvensters onvoldoende worden begrepen. Geef AI onvolledige of slecht gestructureerde context en het zal je nog steeds een zelfverzekerd antwoord geven. Het verschil kennen tussen een goed geïnformeerde uitvoer en een antwoord dat alleen aannemelijk klinkt, vereist menselijk inzicht dat nog niet door genoeg teams is ontwikkeld.

Daarom is de kennisbank van een organisatie van cruciaal belang. Daarmee bedoel ik alle context die momenteel in het hoofd van mensen zit: de manier waarop dingen altijd zijn gedaan, de standaardbenaderingen en de ongeschreven regels voor hoe de organisatie daadwerkelijk werkt. AI kan niet werken met institutionele kennis die nooit naar buiten is gebracht, en de meeste organisaties beschikken over een enorme hoeveelheid daarvan.

Het goede nieuws is dat het naar buiten brengen ervan niet vereist dat alles perfect gestructureerd is. Multimodale AI betekent dat een video-uitleg, een ruwe diagram en een onbewerkt document allemaal waardevolle input zijn. De prioriteit is eerst het naar buiten brengen en daarna pas structureren.

Wat ik consequent zie, is dat het op zichzelf al waardevol is om deze context uit de hoofden van mensen te halen en in welke vorm van documentatie dan ook vast te leggen, nog voordat AI er überhaupt mee aan de slag gaat. Het brengt discrepanties aan het licht, legt gebrekkige aannames bloot en onthult kapotte werkprocessen die niemand had opgemerkt omdat ze er te diep in verweven waren.

Die basis versterkt vervolgens alles wat AI daarna kan doen. Het is een van de zaken waarin een CTO momenteel de meeste impact kan bereiken door tijd te investeren, en een van de zaken die het meest consequent over het hoofd worden gezien, ondanks het feit dat verkopers van automatisering van bedrijfsprocessen ons dit al jaren vertellen!

Hoe je voorkomt dat sceptische ontwikkelaars een organisatie vertragen

Een veelvoorkomend probleem dat ik zie, is niet echt een tekortkoming van AI. Het is een tekortkoming in de invoering ervan, en die volgt meestal een herkenbaar patroon.

Een sceptische ontwikkelaar — en daar zijn er verrassend veel van — doet met minimale context een halfslachtige poging, krijgt een slecht resultaat en presenteert dat resultaat als bewijs dat AI de taak niet kan uitvoeren. De conclusie wordt vol vertrouwen uitgesproken. De methode wordt zelden onderzocht. Wat dit meer maakt dan alleen individuele frustratie, is het effect dat daaruit voortvloeit.

De integratie van AI in een team of ontwikkelingscyclus is een teamsport, en een paar ontwikkelaars die willen aantonen dat het niet werkt, kunnen de hele organisatie vertragen, niet alleen hun eigen uitvoer.

De les die ik hieruit trek, gaat niet over de beperkingen van AI. Het gaat erom dat invoering net zo goed een leiderschapsuitdaging als een technische uitdaging is. De kwaliteit van wat AI produceert, is onlosmakelijk verbonden met de kwaliteit van de context en intentie die je eraan meegeeft, en het opbouwen van dat begrip binnen een team vereist dezelfde doelgerichte inspanning als elke andere ingrijpende verandering in de manier waarop mensen werken. Zo veranderen we de perceptie van gebrekkige ‘magie’ in bruikbare ‘geavanceerde technologie’.

Adam deelt

Een sceptische ontwikkelaar doet met minimale context een halfslachtige poging, krijgt een matig resultaat en presenteert dat resultaat als bewijs dat AI het werk niet kan doen. De conclusie wordt vol vertrouwen uitgesproken. De methode wordt zelden onderzocht.

Waarom kleine teams een voordeel zijn met AI

De aanname dat een goed functionerend, productief engineeringteam een bepaald aantal mensen nodig had om voldoende context te kunnen vasthouden en in een betekenisvol tempo vooruitgang te boeken, heeft geen stand gehouden in het licht van de manier waarop AI-ondersteunde ontwikkeling daadwerkelijk werkt.

De beperkende factor in elk team is altijd cognitief geweest: hoeveel context iedere persoon kan vasthouden, hoe duidelijk die context kan worden overgebracht aan de mensen om hen heen en hoeveel energie die communicatie kost. Wat is veranderd, is dat de eenheid die het werk uitvoert niet langer alleen een persoon is. Iedere persoon in het team gebruikt meerdere AI-agenten, en die AI-agenten dragen context mee en passen die toe op manieren die de rekensom volledig veranderen. Amazons tweepizzaregel was een redelijke vuistregel voor een wereld vóór AI.

Hier is een voorbeeld.

Een organisatie waarmee ik werk had altijd al een interne beheerinterface voor hun platform willen hebben, maar kon de investering nooit rechtvaardigen. Eerder hadden ze dit begroot als een project van meerdere maanden waaraan het hele team zou werken. In plaats daarvan zetten ze er twee mensen op: beiden met diepgaande kennis van de bedrijfsactiviteiten en het bestaande platform, een hoge mate van zelfstandigheid en een duidelijke reeks beperkingen waarbinnen ze konden werken. Zes weken later hadden ze een werkende eerste versie.

De kennis van de bedrijfsactiviteiten van die twee mensen bleek net zo belangrijk als de AI-tools. Minder vragen, minder overhead, snellere beslissingen. Maar de waardevolste uitkomst was niet de tool zelf. Het was wat de organisatie leerde over hoe je op deze manier werkt.

De teams die ik nu het effectiefst zie werken, bestaan uit twee tot drie mensen, die elk meerdere AI-agenten gebruiken, en dat is geen beperking. Voor het juiste soort werk is het een voordeel.

Waarom frequente communicatie cruciaal is bij AI-aangedreven werkstromen

Samenwerking kan moeilijk worden met AI.

Er is veel frequentere communicatie nodig omdat alles sneller gaat. Dat is een van de redenen waarom kleinere teams op dit moment beter werken.

Het lijkt gewoon te vermoeiend om de status en consistentie te behouden in een groot team met meerdere parallelle agentgestuurde codeerprocessen per persoon. Sommige teams waarmee ik werk, zijn overgestapt op twee dagelijkse overlegmomenten om de consistentie te behouden.

Waarom CTO's alert moeten zijn op schaduw-AI

Schaduw-AI is het eerder waargenomen probleem van schaduw-IT, maar dan met een nieuw budget en een nieuwe naam.

Ongecontroleerd en onbeperkt gebruik van AI-tools binnen de hele organisatie kan de risico's op verlies van gegevens en intellectueel eigendom gemakkelijk vergroten — "exfiltratie", zoals de CISO het noemt — vaak volledig onbedoeld door de gebruikers.

De meeste organisaties verlaten snel fase 1 van het CMM (de experimenteerfase van het "wilde westen") om beleidsregels en technische beperkingen in te voeren die de risico's verkleinen.

Waarom CTO's zich op hun eigen ontwikkeling moeten richten

Adams gedachten

De leiders die het sterkst uit deze periode komen, zijn niet per se degenen met de beste tools of de grootste teams. Het zijn degenen die het beoordelingsvermogen, de invloed en de helderheid van denken ontwikkelen om goed leiding te geven wanneer niemand een duidelijke routekaart heeft.

Er is momenteel veel onrust in de sector over wat AI betekent voor engineeringteams, voor het aantal medewerkers en voor de rol zelf.

Of die onrust gerechtvaardigd is, doet er bijna niet toe. Wat ertoe doet, is dat we ons in een periode van ingrijpende en snelle veranderingen bevinden, en dat het goed navigeren hiervan leiders vereist die actief hun eigen capaciteiten ontwikkelen en niet alleen de verandering om hen heen managen.

Wat me, gezien alles wat er gebeurt, nog steeds verbaast, is hoeveel CTO's en senior technologieleiders opereren zonder enige gerichte investering in hun eigen groei. Geen coach, geen gestructureerde ontwikkeling, geen sparringpartner. Ik heb die fout eerder gemaakt, en de fouten die ik maakte en de tijd die ik verloor waren niet onvermijdelijk.

De leiders die het sterkst uit deze periode komen, zijn niet per se degenen met de beste tools of de grootste teams. Het zijn degenen die het beoordelingsvermogen, de invloed en de helderheid van denken ontwikkelen om goed leiding te geven wanneer niemand een duidelijke routekaart heeft.

Volg ons

Je kunt het werk van Adam Horner volgen op LinkedIn. Ga voor 1-op-1-coaching, cohortcursussen en de podcast naar The CTO Playbook. En voor een gratis e-mailcursus van 5 dagen voor CTO's in een vroeg stadium ga je naar Early CTO Map.

Er komen nog meer interviews met experts op The CTO Club!