Technisch directeur zegt dat AI een nieuw besturingsmodel nodig heeft

Tyrone Grandison heeft in zijn 35-jarige carrière in de technologie tal van functies op C-niveau bekleed en is momenteel CTO van Cornerstone Assurance Corporation. Hij is ook de auteur van De AI-revolutie en Cultuur die standhoudt.

We spraken met Tyrone om te ontdekken hoe AI het bestuur binnen technologieorganisaties verandert. Dit vertelde hij ons.

35 jaar in de technologie

Ik geef leiding aan een slanke technologieorganisatie die een groeiend bedrijf in verzekeringen en financiële dienstverlening ondersteunt, genaamd Cornerstone Assurance Corporation. Wat deze rol bijzonder interessant maakt, is dat we een moderne technologiestack bouwen en tegelijkertijd actief zijn in een sector met aanzienlijke wettelijke vereisten, gevoelige financiële gegevens, complexe integraties met verzekeraars en zeer weinig tolerantie voor fouten.

Ik begon mijn carrière als computerwetenschapper, lang voordat AI het onderwerp werd van elk bestuurskamer-gesprek en elke conferentietoespraak. In de loop der jaren verschoof mijn werk van het bouwen van technologie naar het leiden van organisaties door de veranderingen die technologie bij hen teweegbracht. Ik heb gewerkt als directeur kunstmatige intelligentie, technologiedirecteur, informatiedirecteur en plaatsvervangend dataofficer. Ik heb ervaring opgedaan bij overheden, academische instellingen, start-ups, adviesbureaus, non-profitorganisaties en grote ondernemingen.

Na 35 jaar in de technologie heb ik het voorrecht gehad om te zien hoe verschillende zaken werden geïntroduceerd als “de technologie die alles zal veranderen”. En sommige deden dat inderdaad.

Elke grote verandering dwingt leiders om beslissingen te nemen voordat ze over perfecte informatie beschikken. Ze stelt bedrijfsmodellen, operationele modellen, cultuur, talent, bestuur en soms ons begrip van wat onze eigen functies eigenlijk zouden moeten inhouden op de proef. AI doet dat allemaal tegelijk.

Wat dit moment voor mij echter bijzonder fascinerend maakt, is dat we verder zijn gegaan dan AI die ons simpelweg helpt informatie te analyseren. We beschikken nu over systemen die kunnen genereren, redeneren, plannen, creëren, code schrijven, hulpmiddelen gebruiken en steeds vaker actie ondernemen. Dat verandert het leiderschapsgesprek fundamenteel.

De vraag was vroeger: “Wat kan AI doen?”

Ik denk dat dit snel de minst interessante vraag wordt. Zelfs de verkeerde vraag.

De veel belangrijkere vragen zijn: Wat moeten we toestaan dat het doet? Waar blijft menselijk oordeel essentieel? Hoe herontwerpen we organisaties wanneer inzicht zelf overvloedig wordt? En hoe benutten we de buitengewone voordelen van deze technologie zonder risico’s te creëren die we niet begrijpen of systemen te bouwen die we niet kunnen besturen?

Daar ligt mijn werk vandaag. Ik werk samen met leidinggevenden en organisaties om hen te helpen het signaal te onderscheiden van de aanzienlijke hoeveelheid ruis rond AI, te begrijpen wat er daadwerkelijk verandert en dat begrip om te zetten in strategie, bestuur, producten en meetbare bedrijfsresultaten.

Hoe AI de levenscycli van softwareontwikkeling transformeert

Een van de grootste veranderingen die ik bij Cornerstone Assurance Corporation heb doorgevoerd, was het herontwerpen van onze softwareontwikkelingslevenscyclus vanuit de aanname dat AI een aanzienlijk percentage van onze code zal schrijven.

Voor die verandering volgden we een vrij traditionele ontwikkelingsworkflow. Een ontwikkelaar pakte een vereiste op, ontwierp de oplossing, schreef de code, maakte tests, diende een pullrequest in en een andere ontwikkelaar beoordeelde die. We gebruikten natuurlijk automatisering, maar mensen verrichtten nog steeds het meeste denkwerk van vereiste tot implementatie.

AI veranderde de economische aspecten van dat model volledig.

Daarom introduceerden we een AI-ondersteunde ontwikkelingspijplijn met GitHub Copilot voor het genereren en refactoren van code, ChatGPT en Claude voor architecturale verkenning onder leiding van AI, het opsplitsen van vereisten, foutopsporing en het genereren van testgevallen, waarbij onze gebruikelijke CI/CD- en beveiligingstools de deterministische controles rond het door AI gegenereerde werk leverden.

Waarom door AI gegenereerde code een nieuw bestuursmodel vereist

De belangrijke verandering was echter niet: “Hé allemaal, jullie hebben nu Copilot.” We veranderden het bestuursmodel.

Goedkeuringspoorten

We behandelen door AI gegenereerde code nu bijna alsof die is ingediend door een zeer snelle juniorontwikkelaar die nooit slaapt, een absurde hoeveelheid documentatie heeft gelezen en af en toe met enorm veel zelfvertrouwen iets zegt dat volledig onjuist is.

Dat betekent dat AI code, unittests, API-contracten, documentatie, databasequery's, infrastructuurdefinities en voorgestelde oplossingen kan genereren, maar dat AI zijn eigen werk niet mag goedkeuren en geen ongecontroleerde toegang tot productie mag hebben.

We hebben expliciete goedkeuringsmomenten door mensen ingevoerd voor beveiligingsgevoelige wijzigingen, authenticatie en autorisatie, de verwerking van klant- en financiële gegevens, externe integraties en productie-infrastructuur.

Geautomatiseerd testen

We hebben ook het geautomatiseerd testen en de codebeoordeling uitgebreid, omdat het knelpunt is verschoven. Wanneer AI de snelheid waarmee je code kunt produceren drastisch verhoogt, houdt je probleem op codegeneratie te zijn. Je probleem wordt dan aantonen dat de code het verdient om te worden uitgevoerd.

Een eenvoudig voorbeeld is het maken van tests. Voorheen kon een ontwikkelaar een functie implementeren en vervolgens de voor de hand liggende unittests schrijven. Nu kunnen we AI ook vragen om adversariële testgevallen te genereren. Wat gebeurt er met ongeldige invoer? Wat gebeurt er wanneer een API een onverwachte reactie retourneert? Wat gebeurt er bij een permissiegrens? Wat gebeurt er wanneer een klantrecord onvolledige gegevens bevat?

Dat geeft de menselijke ontwikkelaar een andere taak. In plaats van al hun tijd te besteden aan het produceren van artefacten, besteden ze meer tijd aan het ter discussie stellen van aannames en het valideren van het gedrag van code.

AI besturen

We hebben ook veranderd hoe we AI zelf besturen. We registreren AI-ondersteunde activiteiten waar dat gepast is, houden gevoelige klantinformatie uit consumentgerichte AI-tools, bepalen welke modellen en diensten toegang hebben tot bedrijfsgegevens en scheiden experimenten van productietoegang. In verzekeringen en financiële dienstverlening zal “het model dacht dat dit een goed idee was” nooit een governancestrategie vormen.

Hoe AI het knelpunt in engineering verschuift

Het belangrijkste resultaat dat ik heb gezien van het integreren van AI in onze ontwikkelworkflows is snelheid, maar ik plaats altijd een kanttekening bij dat antwoord, omdat snelheid in de verkeerde richting geen productiviteit is.

AI heeft onze ontwikkelcyclus drastisch verkort. We zien werk waarvoor een ontwikkelaar voorheen meerdere dagen nodig had, in enkele uren van vereiste naar testbare implementatie gaan. Specifiek voor prototyping schat ik dat we de cyclustijd met ongeveer 50 tot 70 procent hebben verkort.

En documentatie heeft waarschijnlijk de minst glamoureuze, maar meest directe efficiëntiewinst opgeleverd. API-documentatie, releaseopmerkingen, testdocumentatie, code-uitleg en eerste versies van technische specificaties hoeven niet langer te beginnen met een knipperende cursor. AI produceert de eerste 70 of 80 procent en mijn team besteedt zijn tijd aan corrigeren en verbeteren, in plaats van alles vanaf nul te creëren.

Maar er is een nadeel, en ik denk dat technologieleiders hier meer over moeten praten: AI maakt het ongelooflijk goedkoop om snel slechte code te produceren.

We ontdekten dat de beperkende factor verderop in het proces komt te liggen. Als ik vijf keer zoveel code kan genereren, maar mensen die code nog steeds moeten begrijpen, beoordelen, testen, beveiligen, implementeren, monitoren en onderhouden, heb ik de systeemdoorvoer niet noodzakelijk verhoogd. Ik heb misschien alleen een verkeersopstopping bij de codebeoordeling gecreëerd.

Dat is waarschijnlijk de waardevolste les voor mij geweest. Ik optimaliseer mijn ontwikkelorganisatie niet langer in de eerste plaats voor hoe snel we software kunnen schrijven. AI maakt dat onderdeel snel tot een gemeengoed. Ik optimaliseer voor hoe snel we kunnen aantonen dat software het verdient om in productie te draaien. Dat is een heel andere ontwikkelorganisatie.

Waar AI inspraak krijgt versus waar AI beslissingsrecht krijgt

Ik ben er behoorlijk bewust mee bezig om twee dingen van elkaar te scheiden: waar AI een stem krijgt en waar AI mag stemmen. In onze organisatie heeft AI inmiddels in vrijwel elke fase van onze technologiecyclus een stem. AI mag niet over elke beslissing stemmen.

Enkele voorbeelden:

• Architectuur: We gebruiken ChatGPT en Claude als gesprekspartners voor architectuurvraagstukken. Als we een nieuwe service ontwerpen, kan ik het model onze vereisten, beperkingen, bestaande interfaces, beveiligingsgrenzen, verwachte transactievolume en faalscenario's geven. Ik laat het meerdere architecturen voorstellen, afwegingen identificeren, onze aannames ter discussie stellen en zelfs tegen zijn eigen aanbeveling argumenteren. Wat ik niet zal doen, is vragen: "Welke architectuur moeten we gebruiken?" en vervolgens bouwen wat eruit komt. De uiteindelijke architectuurbeslissing blijft bij mensen, omdat architectuur context omvat die veel verder gaat dan technische optimalisatie. Ik moet rekening houden met onze bedrijfsstrategie, wettelijke verplichtingen, operationele volwassenheid, risicotolerantie, kosten, technische schuld en wat mijn team daadwerkelijk om 2:00 uur 's nachts kan ondersteunen.
• Code: Daar geven we AI aanzienlijk meer speelruimte. We gebruiken GitHub Copilot voor het genereren van code, refactoring, documentatie en het maken van unit tests. We gebruiken ChatGPT en Claude ook om fouten op te lossen, implementatiebenaderingen te verkennen en vijandige testgevallen te genereren. AI kan ongelooflijk snel een eerste implementatie schrijven. Een menselijke ontwikkelaar blijft verantwoordelijk voor het wijzigingsverzoek en keurt goed wat uiteindelijk wordt samengevoegd.
• Testen: Dit is waarschijnlijk het verst in de richting van AI verschoven. Ik vind het geweldig om AI te vragen: "Hoe zou je dit breken?" We kunnen gevallen vinden die een ontwikkelaar die net twee dagen aan de functie heeft gebouwd, onbewust over het hoofd zou kunnen zien. AI wordt zo een zeer goedkope, extreem vasthoudende tegenstander.
• Beveiliging: Hier draai ik de verhouding bewust om. AI helpt ons kwetsbaarheden te identificeren, codepatronen te inspecteren, dreigingen te modelleren en aanvalsscenario's te genereren, maar zoals ik al zei, houden mensen de zeggenschap over beveiligingsacceptatie, identiteits- en toegangsbeslissingen, de verwerking van gevoelige gegevens en uitzonderingen. Promptinjectie en het openbaar maken van gevoelige informatie blijven erkende risico's in LLM-toepassingen, dus voor het verbinden van AI met bedrijfssystemen zijn meer controles nodig, niet minder.
• Incidentrespons: Dit bevindt zich ergens in het midden. AI kan logboeken opnemen, gebeurtenissen correleren, duizenden regels telemetrie samenvatten, waarschijnlijke hoofdoorzaken voorstellen en herstelstappen aanbevelen. Dat kan de eerste 30 minuten van een incident aanzienlijk inkorten. Maar als iemand een productieservice wil uitschakelen, een kritieke implementatie wil terugdraaien, een beveiligingsbeleid wil wijzigen of een actie wil ondernemen die gevolgen heeft voor klanten, neemt een mens die beslissing.
• Prioritering van de backlog: Hier gebruik ik dezelfde regel. AI kan supportproblemen, technische inspanning, afhankelijkheden, productgebruik en bedrijfsdoelstellingen analyseren en zeggen: "Dit is hoe ik deze 40 zaken zou prioriteren en dit is waarom." Dat is ongelooflijk nuttig. Maar AI begrijpt onze strategie niet beter dan wij. Product- en technologieleiders nemen de uiteindelijke prioriteringsbeslissing.

Mijn regel is dus vrij eenvoudig: AI krijgt meer autonomie wanneer de actie omkeerbaar, observeerbaar, testbaar en weinig ingrijpend is. De menselijke zeggenschap neemt toe naarmate een actie moeilijker terug te draaien is of grotere gevolgen heeft voor klanten, financiën, beveiliging, regelgeving of reputatie.

Een realistische ontwikkelwerkwijze

Hier is een voorbeeld van een werkstroom voor "van vereiste naar productie met AI in de lus". Stel dat we een nieuwe mogelijkheid moeten toevoegen aan een agentwerkstroom die klant- en beleidsinformatie ophaalt, een aantal bedrijfsregels toepast en de juiste volgende actie aanbeveelt:

1. Het begint met de vereiste. In plaats van dat een engineer een losjes geschreven ticket ontvangt en meteen begint te programmeren, gebruiken we ChatGPT of Claude om de vereiste grondig te bevragen. We geven het user story, acceptatiecriteria, relevante bedrijfsregels, API-contracten en technische beperkingen. Vervolgens vragen we het om onduidelijkheden, ontbrekende randgevallen, afhankelijkheden, beveiligingsproblemen en vragen te identificeren die we moeten beantwoorden voordat iemand code schrijft. Dat klinkt eenvoudig, maar zo wordt verrassend veel kostbare verwarring vroegtijdig voorkomen.
2. Vervolgens komen de architectuur en het opdelen van taken aan bod. We gebruiken Claude en ChatGPT om implementatieopties te verkennen en de vereisten op te splitsen in componenten. Het model kan een API-wijziging, een wijziging van het gegevensmodel, een integratieafhankelijkheid, autorisatievereisten, telemetrie en de benodigde testgevallen identificeren. We vragen het ook om tegenargumenten voor de voorgestelde architectuur te geven. Een menselijke engineer neemt de architectuurbeslissing. AI biedt opties. Wij dragen de gevolgen.
3. Daarna gaan we over tot de implementatie. We gebruiken GitHub Copilot binnen de ontwikkelomgeving om standaardcode te genereren, goed gedefinieerde functies te implementeren, code te refactoren, API-clients te maken, onbekende delen van de codebase uit te leggen en documentatie te genereren. De engineer gaat van elke regel typen naar het aansturen, beoordelen en verfijnen van de implementatie. Dat onderscheid is belangrijk. Ik wil niet dat ontwikkelaars zeer dure operators van automatische aanvullingen worden. Ik wil dat ze nadenken over het systeem.
4. Vervolgens geven we ChatGPT of Claude de vereiste en de implementatie en zeggen we in feite: “Mooi. Breek het nu.” AI helpt bij het genereren van vijandige scenario's en Copilot helpt om die om te zetten in geautomatiseerde unit- en integratietests.
5. Daarna neemt de deterministische machinerie het over. De pull request komt in onze CI/CD-pijplijn terecht. We voeren geautomatiseerde tests, statische analyse, scans op afhankelijkheden en kwetsbaarheden en onze gebruikelijke kwaliteitscontroles uit. Een menselijke engineer beoordeelt de pull request.
6. Daarna implementeren we stapsgewijs. De wijziging gaat via ontwikkeling en acceptatieomgeving voordat deze naar productie gaat. Waar passend gebruiken we functievlaggen of gecontroleerde uitrolpatronen, zodat we de blootstelling kunnen beperken, gedrag kunnen observeren en snel kunnen terugdraaien.
7. En ook de taak van AI zit er nog niet op. Zodra de functie actief is, wordt AI een assistent voor observeerbaarheid. We gebruiken het om logs samen te vatten, foutpatronen met elkaar in verband te brengen, onverwacht gedrag te analyseren en engineers te helpen veel sneller van “er is iets mis” naar een plausibele hoofdoorzaak te gaan.

Hoe je met AI het gedrag van engineers verandert

Ik wou dat ik eerder had begrepen dat engineers AI-tools geven eenvoudig is. Het veranderen van het gedrag van engineers is het moeilijke deel.

Toen we tools zoals GitHub Copilot, ChatGPT en Claude voor het eerst gingen gebruiken, pakte ik de uitrol aan zoals veel technologieleiders dat doen. Geef getalenteerde engineers krachtige tools, stel enkele verstandige waarborgen in en wacht tot de productiviteit toeneemt.

Dat gebeurde inderdaad, maar niet uniform en niet altijd op de manieren die ik had verwacht.

Het eerste wat ik leerde, was dat toegang niet gelijkstaat aan adoptie en dat adoptie niet gelijkstaat aan vaardigheid.

Twee engineers kunnen exact dezelfde AI-tool hebben en totaal verschillende resultaten behalen. De een behandelt AI als automatische aanvulling en bespaart een paar toetsaanslagen. De ander leert hoe je context verstrekt, problemen opsplitst, resultaten kritisch beoordeelt, tests genereert, alternatieven verkent en het model gebruikt als technische gesprekspartner. Het productiviteitsverschil tussen die twee mensen kan enorm worden.

Ik zou veel eerder hebben geïnvesteerd in AI-geletterdheid en werkpatronen. Niet “hier is een cursus promptengineering van twee uur”, maar praktische voorbeelden die zijn gebaseerd op ons daadwerkelijke engineeringwerk.

Opmerkingen van Tyrone

Ik zou veel eerder hebben geïnvesteerd in AI-geletterdheid en werkpatronen. Niet “hier is een cursus promptengineering van twee uur”, maar praktische voorbeelden die zijn gebaseerd op ons daadwerkelijke engineeringwerk.

Hoe AI technologisch leiderschap transformeert

We besteden veel tijd aan de vraag wat AI zal betekenen voor ontwikkelaars, architecten, analisten en andere technische functies. Ik denk dat CTO's die vraag moeten omdraaien en op onszelf moeten richten.

Gedurende het grootste deel van mijn carrière werd technologisch leiderschap beloond met kennis van zaken die anderen niet hadden. Ervaring gaf je het vermogen om patronen te herkennen. Technische expertise gaf je gezag. Je kon een ruimte binnenlopen en een antwoord geven waarvoor iemand anders misschien dagen nodig had gehad om het te vinden.

Nu kan ik iedereen een ongelooflijk capabel AI-systeem in handen geven. Dat verandert leiderschap.

Ik denk niet langer dat mijn waarde als CTO voortkomt uit het hebben van de antwoorden. Het gaat erom betere vragen te stellen, context te bieden, afwegingen te maken, beoordelingsvermogen te gebruiken en een omgeving te creëren waarin mensen en machines elkaar beter maken.

Dat vereist nederigheid. AI zal soms een aanpak herkennen waar ik niet aan had gedacht. Een junior ontwikkelaar met uitstekende AI-vaardigheden kan een aanname ter discussie stellen die iemand met 25 jaar ervaring als vanzelfsprekend beschouwt. Ik denk dat geweldige technologieleiders daarvoor open moeten staan.

De CTO van het AI-tijdperk kan niet simpelweg de technisch slimste persoon in de ruimte zijn. We moeten de mensen worden die de ruimte ontwerpen. Wie krijgt een stem? Waarover mag AI beslissen? Waar blijft menselijk beoordelingsvermogen essentieel? Hoe weten we wanneer we het bij het verkeerde eind hebben?

Dat is de transformatie van leiderschap.

Waarom CTO's voorzichtig moeten zijn met efficiëntiewinst

Mijn belangrijkste advies aan CTO's op dit moment is: verwar snel bewegen niet met vooruitgang boeken.

Er ligt een enorme druk op technologieleiders om “iets met AI te doen”. Besturen vragen ernaar. CEO's vragen ernaar. Werknemers gebruiken het al, of je nu een beleid hebt of niet. Elke leverancier heeft plotseling ontdekt dat hun product altijd al “door AI aangedreven” was.

Het is heel gemakkelijk om reactief te worden. Maar ik denk dat het de taak van de CTO is om midden in die ruis duidelijkheid te scheppen.

• Ten eerste: gebruik de technologie zelf. En ik bedoel: gebruik haar echt. Bouw je AI-strategie niet volledig op rapporten van analisten en demonstraties van leveranciers. Ik gebruik tools zoals ChatGPT, Claude en GitHub Copilot omdat ik uit eerste hand moet ervaren waarin ze buitengewoon goed zijn, waar ze falen en hoe snel die grenzen verschuiven. Je kunt een technologische transitie niet effectief leiden als je die alleen via PowerPoint ervaart.
• Ten tweede: begin met zakelijke beperkingen, niet met AI-mogelijkheden. Ik ben veel minder geïnteresseerd in de vraag “Waar kunnen we generatieve AI gebruiken?” dan in de vraag “Waar zijn we traag, duur, inconsistent of beperkt in capaciteit, of waar laten we klanten gefrustreerd achter?” Daarna kan ik bepalen of AI daadwerkelijk onderdeel van de oplossing moet zijn.
• Ten derde: leg je fundamenten op orde. AI zal slechte gegevens, zwakke API's, gebrekkige observeerbaarheid, ontbrekende documentatie of disfunctionele engineeringpraktijken niet redden. Het zal deze vaak juist versterken. AI werkt als een versterker van de onderliggende organisatie en het technische systeem.
• Ten vierde: ontwerp governance rond gevolgen, niet rond angst. Ik wil geen AI-beleid van 47 pagina's dat in feite zegt: “Doe alsjeblieft niets interessants.” Ik wil beheersmaatregelen die evenredig zijn aan het risico. Laat mensen volop experimenteren wanneer acties omkeerbaar zijn en weinig gevolgen hebben. Verhoog het menselijke toezicht zodra beslissingen gevolgen beginnen te hebben voor klantgegevens, geld, beveiliging, wettelijke verplichtingen of productiesystemen.
• Ten vijfde, en dit is misschien wel het belangrijkste, herontwerp het werk in plaats van simpelweg AI aan het werk toe te voegen. Als mijn ontwikkelproces twaalf stappen heeft en AI stap vier 70 procent sneller maakt, heb ik engineering niet getransformeerd. Ik heb stap vier versneld.
• En tot slot: bescherm menselijk beoordelingsvermogen terwijl je menselijke sleur agressief elimineert.

Ik denk dat CTO's momenteel een zeldzame kans hebben. Vraag niet alleen hoe AI je huidige organisatie efficiënter maakt. Vraag welke organisatie je zou bouwen als je vandaag zou beginnen. Dat is de ongemakkelijkere vraag. Het is ook de vraag die het verschil zal maken tussen bedrijven die AI simpelweg gebruiken en bedrijven die er daadwerkelijk door transformeren.

Volg hem

Je kunt het werk van Tyrone Grandison volgen op LinkedIn en op zijn persoonlijke website. Je kunt ook zijn boeken bekijken: De AI-revolutie en Cultuur die standhoudt.

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