CTO siger, at AI har brug for en ny styringsmodel

Tyrone Grandison har haft mange roller på C-niveau i løbet af sin 35-årige karriere inden for teknologi, og han er i øjeblikket CTO hos Cornerstone Assurance Corporation. Han er også forfatter til AI-revolutionen og en kultur, der varer ved.

Vi talte med Tyrone for at høre, hvordan AI ændrer styringen i teknologiorganisationer. Her er, hvad han fortalte os.

35 år inden for teknologi

Jeg leder en slank teknologiorganisation, der understøtter en voksende virksomhed inden for forsikring og finansielle tjenester kaldet Cornerstone Assurance Corporation. Det, der gør rollen særligt interessant, er, at vi opbygger en moderne teknologistak, samtidig med at vi opererer i en branche med betydelige lovgivningsmæssige krav, følsomme finansielle data, komplekse integrationer med forsikringsselskaber og meget lille tolerance for at begå fejl.

Jeg begyndte min karriere som datalog, længe før AI blev emnet for enhver bestyrelseslokalesamtale og hovedtale på konferencer. I årenes løb førte mit arbejde mig fra at bygge teknologi til at lede organisationer gennem det, teknologien gjorde ved dem. Jeg har fungeret som chef for kunstig intelligens, teknologichef, informationschef og vicechef for data. Jeg har arbejdet på tværs af den offentlige sektor, den akademiske verden, startups, rådgivning, nonprofitorganisationer og store virksomheder.

Efter 35 år inden for teknologi har jeg haft det privilegium at se adskillige ting blive introduceret som “teknologien, der vil ændre alt”. Og nogle af dem gjorde det faktisk.

Ethvert større skift tvinger ledere til at træffe beslutninger, før de har perfekte oplysninger. Det udfordrer forretningsmodeller, driftsmodeller, kultur, talenter, styring og nogle gange vores forståelse af, hvad vores egne job egentlig skal være. AI gør alt dette på én gang.

Men det, der gør dette øjeblik særligt fascinerende for mig, er, at vi er kommet videre end blot at bruge AI til at analysere oplysninger. Vi har nu systemer, der kan generere, ræsonnere, planlægge, skabe, skrive kode, bruge værktøjer og i stigende grad handle. Det ændrer grundlæggende ledelsessamtalen.

Spørgsmålet plejede at være: “Hvad kan AI gøre?”

Jeg tror hurtigt, at det er ved at blive det mindst interessante spørgsmål. Selv det forkerte spørgsmål.

De langt vigtigere spørgsmål er: Hvad bør vi tillade den at gøre? Hvor er menneskelig dømmekraft stadig afgørende? Hvordan redesigner vi organisationer, når indsigt i sig selv bliver rigelig? Og hvordan udnytter vi denne teknologis ekstraordinære potentiale uden at skabe risici, vi ikke forstår, eller systemer, vi ikke kan styre?

Det er her, mit arbejde ligger i dag. Jeg arbejder med ledere og organisationer for at hjælpe dem med at skelne signalet fra den betydelige mængde støj omkring AI, forstå, hvad der faktisk ændrer sig, og omsætte denne forståelse til strategi, styring, produkter og målbare forretningsresultater.

Hvordan AI forandrer softwareudviklingens livscyklusser

En af de største ændringer, jeg gennemførte hos Cornerstone Assurance Corporation, var at redesigne vores livscyklus for softwareudvikling ud fra den antagelse, at AI vil skrive en betydelig procentdel af vores kode.

Før denne ændring fulgte vi en forholdsvis traditionel arbejdsgang inden for softwareudvikling. En udvikler tog et krav op, designede løsningen, skrev koden, oprettede tests, indsendte en pull request, og en anden udvikler gennemgik den. Vi brugte naturligvis automatisering, men mennesker udførte stadig det meste af det kognitive arbejde fra krav til implementering.

AI ændrede fuldstændigt økonomien i denne model.

Derfor indførte vi en AI-understøttet udviklingspipeline, der bruger GitHub Copilot til kodegenerering og refaktorering, ChatGPT og Claude til AI-ledet arkitektonisk udforskning, dekomponering af krav, fejlfinding og generering af testtilfælde, mens vores almindelige CI/CD- og sikkerhedsværktøjer leverer de deterministiske kontroller omkring det AI-genererede arbejde.

Hvorfor AI-genereret kode kræver en ny styringsmodel

Men den vigtige ændring var ikke: “Hej alle sammen, nu har I Copilot.” Vi ændrede styringsmodellen.

Godkendelsesporte

Vi behandler nu AI-genereret kode næsten som kode indsendt af en meget hurtig juniorudvikler, der aldrig sover, har læst en absurd mængde dokumentation og af og til siger noget, der er helt forkert, med enorm selvsikkerhed.

Det betyder, at AI kan generere kode, enhedstests, API-kontrakter, dokumentation, databaseforespørgsler, infrastrukturdefinitioner og foreslåede rettelser, men den kan ikke godkende sit eget arbejde eller have en ukontrolleret vej til produktion.

Vi indførte eksplicitte menneskelige godkendelsesporte for sikkerhedsfølsomme ændringer, autentificering og autorisation, håndtering af kunde- og finansielle data, eksterne integrationer og produktionsinfrastruktur.

Automatiseret test

Vi udvidede også automatiserede tests og kodegennemgang, fordi flaskehalsen flyttede sig. Når AI dramatisk øger hastigheden, hvormed du kan producere kode, holder dit problem op med at være kodegenerering. Dit problem bliver at bevise, at koden fortjener at køre.

Et enkelt eksempel er oprettelse af tests. Tidligere kunne en udvikler implementere en funktion og derefter skrive de oplagte enhedstests. Nu kan vi også bede AI om at generere kontradiktoriske testtilfælde. Hvad sker der med ugyldigt input? Hvad sker der, når en API returnerer et uventet svar? Hvad sker der ved en tilladelsesgrænse? Hvad sker der, når en kundepost indeholder ufuldstændige data?

Det giver den menneskelige udvikler en anden opgave. I stedet for at bruge al sin tid på at producere artefakter bruger vedkommende mere tid på at udfordre antagelser og validere kodens adfærd.

Styring af AI

Vi ændrede også den måde, vi styrer selve AI på. Vi logger AI-assisteret aktivitet, hvor det er relevant, holder følsomme kundeoplysninger ude af forbrugerrettede AI-værktøjer, kontrollerer, hvilke modeller og tjenester der kan tilgå virksomhedsdata, og adskiller eksperimentering fra produktionsadgang. Inden for forsikring og finansielle tjenester vil “modellen mente, at dette var en god idé” aldrig udgøre en styringsstrategi.

Hvordan AI flytter flaskehalsen i udviklingen

Det største resultat, jeg har set ved at integrere AI i vores udviklingsarbejdsgange, er hastighed, men jeg tilføjer altid en stjerne til det svar, fordi hastighed i den forkerte retning ikke er produktivitet.

AI har dramatisk forkortet vores udviklingscyklus. Vi ser arbejde, der tidligere tog en udvikler flere dage, bevæge sig fra krav til testbar implementering på få timer. Specifikt for prototyper vil jeg anslå, at vi har reduceret cyklustiden med cirka 50 til 70 procent.

Og dokumentation har sandsynligvis givet den mindst glamourøse, men mest umiddelbare effektivitetsgevinst. API-dokumentation, versionsnoter, testdokumentation, kodeforklaringer og de første udkast til tekniske specifikationer behøver ikke længere begynde med en blinkende markør. AI producerer de første 70 eller 80 procent, og mit team bruger tiden på at rette og forbedre i stedet for at skabe alt fra bunden.

Men der er en bagside, og jeg synes, at teknologiledere skal tale mere om dette: AI gør det utroligt billigt hurtigt at producere dårlig kode.

Vi opdagede, at den begrænsende faktor flytter sig længere ned i processen. Hvis jeg kan generere fem gange så meget kode, men mennesker stadig skal forstå, gennemgå, teste, sikre, implementere, overvåge og vedligeholde den, har jeg ikke nødvendigvis øget systemets gennemløb. Jeg har måske bare skabt en trafikprop ved kodegennemgangen.

Det har sandsynligvis været den mest værdifulde lektie for mig. Jeg optimerer ikke længere primært min udviklingsorganisation efter, hvor hurtigt vi kan skrive software. AI gør hurtigt denne del til en standardiseret vare. Jeg optimerer efter, hvor hurtigt vi kan bevise, at software fortjener at køre i produktion. Det er en helt anden udviklingsorganisation.

Hvor AI får en stemme, kontra hvor den får en stemmeberettigelse

Jeg er blevet ret bevidst om at adskille to ting: hvor AI får en stemme, og hvor AI får en afgørende stemme. I vores organisation har AI nu en stemme i næsten alle faser af vores teknologiske livscyklus. Den får ikke en afgørende stemme i alle beslutninger.

Nogle eksempler:

• Arkitektur: Vi bruger ChatGPT og Claude som arkitektoniske sparringspartnere. Hvis vi designer en ny tjeneste, kan jeg give modellen vores krav, begrænsninger, eksisterende grænseflader, sikkerhedsgrænser, forventede transaktionsmængder og fejlscenarier. Jeg beder den foreslå flere arkitekturer, identificere afvejninger, udfordre vores antagelser og endda argumentere imod sin egen anbefaling. Det, jeg ikke vil gøre, er at spørge: “Hvilken arkitektur bør vi bruge?” og derefter bygge det, der kommer tilbage. Den endelige arkitekturbeslutning forbliver menneskelig, fordi arkitektur omfatter en kontekst, der rækker langt ud over teknisk optimering. Jeg skal tage højde for vores forretningsstrategi, lovgivningsmæssige forpligtelser, operationelle modenhed, risikotolerance, omkostninger, teknisk gæld og hvad mit team faktisk kan understøtte klokken 2:00 om natten.
• Kode: Her giver vi AI betydeligt større spillerum. Vi bruger GitHub Copilot til kodegenerering, refaktorering, dokumentation og oprettelse af enhedstests. Vi bruger også ChatGPT og Claude til fejlfinding, undersøgelse af implementeringstilgange og generering af adversarielle testtilfælde. AI kan skrive en første implementering utroligt hurtigt. En menneskelig udvikler har stadig ansvaret for ændringsanmodningen og godkender det, der i sidste ende bliver flettet ind.
• Test: Dette har sandsynligvis bevæget sig længst i retning af AI. Jeg elsker at bruge AI til at spørge: “Hvordan ville du ødelægge dette?” Vi kan finde tilfælde, som en udvikler, der netop har brugt to dage på at bygge funktionen, ubevidst kan overse. AI bliver en meget billig og ekstremt vedholdende modstander.
• Sikkerhed: Det er her, jeg bevidst vender ligningen om. AI hjælper os med at identificere sårbarheder, undersøge kodemønstre, modellere trusler og generere angrebsscenarier, men som sagt beholder mennesker myndigheden over sikkerhedsgodkendelse, beslutninger om identitet og adgang, håndtering af følsomme data og undtagelser. Promptinjektion og videregivelse af følsomme oplysninger er fortsat anerkendte risici i LLM-applikationer, så det kræver flere, ikke færre, kontroller at forbinde AI med virksomhedssystemer.
• Hændelseshåndtering: Dette befinder sig et sted midt imellem. AI kan indlæse logfiler, sammenkæde hændelser, opsummere tusindvis af linjer telemetri, foreslå sandsynlige grundårsager og anbefale afhjælpningstrin. Det kan forkorte de første 30 minutter af en hændelse markant. Men hvis nogen ønsker at deaktivere en produktionstjeneste, rulle en kritisk implementering tilbage, ændre en sikkerhedspolitik eller foretage en handling, der påvirker kunder, er det et menneske, der træffer beslutningen.
• Prioritering af opgaveefterslæb: Jeg bruger den samme regel her. AI kan analysere supportproblemer, udviklingsindsats, afhængigheder, produktbrug og forretningsmål og sige: “Sådan ville jeg prioritere disse 40 ting, og her er hvorfor.” Det er utroligt nyttigt. Men AI forstår ikke vores strategi bedre, end vi gør. Produkt- og teknologiledere træffer den endelige prioriteringsbeslutning.

Så min regel er ret enkel: AI får mere autonomi, når handlingen kan rulles tilbage, kan observeres og testes og har begrænsede konsekvenser. Den menneskelige myndighed øges, efterhånden som en handling bliver sværere at rulle tilbage eller medfører større konsekvenser for kunder, økonomi, sikkerhed, lovgivning eller omdømme.

En teknisk arbejdsgang fra den virkelige verden

Her er et eksempel på en arbejdsgang fra “krav til produktion med AI i loopet”. Lad os sige, at vi skal tilføje en ny funktion til en agentarbejdsgang, der henter kunde- og politikoplysninger, anvender et sæt forretningsregler og anbefaler den relevante næste handling:

1. Det begynder med kravet. I stedet for at en ingeniør modtager en løst formuleret opgave og straks begynder at kode, bruger vi ChatGPT eller Claude til at gennemgå kravet grundigt. Vi giver den brugerhistorien, acceptkriterierne, relevante forretningsregler, API-kontrakter og tekniske begrænsninger. Derefter beder vi den om at identificere uklarheder, manglende grænsetilfælde, afhængigheder, sikkerhedsproblemer og spørgsmål, som vi bør besvare, før nogen skriver kode. Det lyder enkelt, men det fanger overraskende meget dyr forvirring tidligt.
2. Derefter kommer arkitektur og opdeling af opgaver. Vi bruger Claude og ChatGPT til at undersøge implementeringsmuligheder og opdele kravene i komponenter. Modellen kan identificere en API-ændring, en ændring af datamodellen, en integrationsafhængighed, krav til autorisation, telemetri og de nødvendige testtilfælde. Vi beder den også om at argumentere imod den foreslåede arkitektur. En menneskelig ingeniør træffer den arkitekturmæssige beslutning. AI leverer mulighederne. Vi tager ansvar for konsekvenserne.
3. Derefter går vi i gang med implementeringen. Vi bruger GitHub Copilot i udviklingsmiljøet til at generere standardkode, implementere veldefinerede funktioner, refaktorere kode, oprette API-klienter, forklare ukendte dele af kodebasen og generere dokumentation. Ingeniøren går fra at skrive hver eneste linje til at styre, gennemgå og finpudse implementeringen. Den forskel er vigtig. Jeg ønsker ikke, at udviklere bliver meget dyre autofuldførelsesoperatører. Jeg ønsker, at de tænker på systemet.
4. Derefter giver vi ChatGPT eller Claude kravet og implementeringen og siger grundlæggende: “Fantastisk. Bryd det nu.” AI hjælper med at generere kontradiktoriske scenarier, og Copilot hjælper med at omsætte dem til automatiserede enheds- og integrationstests.
5. Derefter tager de deterministiske mekanismer over. Anmodningen om kodeændring går ind i vores CI/CD-pipeline. Vi kører automatiserede tests, statisk analyse, scanning efter afhængigheder og sårbarheder samt vores normale kvalitetskontroller. En menneskelig ingeniør gennemgår anmodningen om kodeændring.
6. Derefter implementerer vi trinvist. Ændringen bevæger sig gennem udvikling og testmiljø, før den kommer i produktion. Hvor det er relevant, bruger vi funktionsflag eller kontrollerede udrulningsmønstre, så vi kan begrænse eksponeringen, observere adfærden og hurtigt rulle tilbage.
7. Og AI's opgave er stadig ikke færdig. Når funktionen kører, bliver AI en assistent til observerbarhed. Vi bruger den til at opsummere logfiler, sammenholde fejlmønstre, analysere uventet adfærd og hjælpe ingeniører med at gå fra “der er noget galt” til en sandsynlig grundårsag langt hurtigere.

Sådan ændrer du ingeniøradfærd med AI

Jeg ville ønske, at jeg tidligere havde forstået, at det er nemt at give ingeniører AI-værktøjer. Det svære er at ændre ingeniørernes arbejdsadfærd.

Da vi først begyndte at bruge værktøjer som GitHub Copilot, ChatGPT og Claude, greb jeg udrulningen an på samme måde, som mange teknologiledere gør. Giv talentfulde ingeniører stærke værktøjer, etabler nogle fornuftige sikkerhedsforanstaltninger, og vent på, at produktiviteten stiger.

Det gjorde den, men ikke ensartet og ikke altid på de måder, jeg forventede.

Det første, jeg lærte, var, at adgang ikke er det samme som anvendelse, og at anvendelse ikke er det samme som fortrolighed.

To ingeniører kan have præcis det samme AI-værktøj og få vidt forskellige resultater. Den ene behandler AI som autofuldførelse og sparer nogle få tastetryk. Den anden lærer hvordan man giver kontekst, opdeler problemer, udfordrer output, genererer tests, undersøger alternativer og bruger modellen som en teknisk sparringspartner. Produktivitetsforskellen mellem de to personer kan blive enorm.

Jeg ville have investeret i AI-kompetencer og arbejdsmønstre langt tidligere. Ikke “her er et to-timers kursus i promptudvikling”, men praktiske eksempler baseret på vores faktiske ingeniørarbejde.

Tyrone-kommentarer

Jeg ville have investeret i AI-kompetencer og arbejdsmønstre langt tidligere. Ikke “her er et to-timers kursus i promptudvikling”, men praktiske eksempler baseret på vores faktiske ingeniørarbejde.

Sådan forvandler AI teknologiledelse

Vi bruger meget tid på at spørge, hvad AI vil gøre ved udviklere, arkitekter, analytikere og andre tekniske roller. Jeg mener, at CTO'er skal vende spørgsmålet om og rette det mod os selv.

I størstedelen af min karriere har teknologisk ledelse belønnet det at vide ting, som andre ikke vidste. Erfaring gav evnen til at genkende mønstre. Teknisk ekspertise gav autoritet. Man kunne træde ind i et rum og give et svar, som det kunne have taget en anden flere dage at finde.

Nu kan jeg give alle adgang til et utroligt kompetent AI-system. Det ændrer ledelse.

Jeg mener ikke længere, at min værdi som CTO kommer af at have svarene. Den kommer af at stille bedre spørgsmål, skabe kontekst, foretage afvejninger, udøve dømmekraft og skabe et miljø, hvor mennesker og maskiner gør hinanden bedre.

Det kræver ydmyghed. AI vil nogle gange identificere en tilgang, jeg ikke havde overvejet. En junioringeniør med gode AI-kompetencer kan udfordre en antagelse, som en person med 25 års erfaring opfatter som indlysende. Jeg mener, at gode teknologiledere skal byde det velkommen.

CTO'en i AI-æraen kan ikke blot være den teknisk dygtigste person i rummet. Vi skal blive de mennesker, der designer rummet. Hvem får en stemme? Hvad får AI lov til at beslutte? Hvor er menneskelig dømmekraft stadig afgørende? Hvordan ved vi, hvornår vi tager fejl?

Det er den ledelsesmæssige transformation.

Hvorfor CTO'er bør være forsigtige med effektivitetsgevinster

Mit vigtigste råd til CTO'er lige nu er dette: Forveksl ikke det at bevæge sig hurtigt med at skabe fremskridt.

Der er et enormt pres på teknologiledere for at “gøre noget med AI”. Bestyrelser spørger til det. Direktører spørger til det. Medarbejderne bruger det allerede, uanset om I har en politik eller ej. Alle leverandører har pludselig opdaget, at deres produkt har været “AI-drevet” hele tiden.

Det er meget let at blive reaktiv. Men jeg mener, at CTO'ens opgave lige nu er at skabe klarhed midt i al den støj.

• For det første, brug selv teknologien. Og jeg mener virkelig brug den. Byg ikke hele din AI-strategi på analyserapporter og leverandørdemonstrationer. Jeg bruger værktøjer som ChatGPT, Claude og GitHub Copilot, fordi jeg har brug for førstehåndserfaring med, hvor fremragende de er, hvor de fejler, og hvor hurtigt de grænser flytter sig. Du kan ikke lede en teknologisk overgang effektivt, hvis du kun oplever den gennem PowerPoint.
• For det andet, tag udgangspunkt i forretningsmæssige begrænsninger, ikke i AI-funktioner. Jeg er langt mindre interesseret i at spørge: “Hvor kan vi bruge generativ AI?” end i at spørge: “Hvor er vi langsomme, dyre, inkonsekvente, kapacitetsbegrænsede eller årsag til frustration hos kunderne?” Derefter kan jeg afgøre, om AI faktisk hører hjemme i løsningen.
• For det tredje, få styr på fundamentet. AI redder ikke dårlige data, svage API'er, mangelfuld overvågningsmulighed, ikkeeksisterende dokumentation eller dysfunktionelle udviklingspraksisser. Den vil ofte forstærke dem. AI fungerer som en forstærker af den underliggende organisation og det tekniske system.
• For det fjerde, design styringen ud fra konsekvenser, ikke frygt. Jeg ønsker ikke en AI-politik på 47 sider, der reelt siger: “Lad venligst være med at gøre noget interessant.” Jeg ønsker kontroller, der står mål med risikoen. Lad folk eksperimentere ambitiøst, hvor handlinger kan omgøres og har få konsekvenser. Øg det menneskelige tilsyn, når beslutninger begynder at påvirke kundedata, penge, sikkerhed, lovgivningsmæssige forpligtelser eller produktionssystemer.
• For det femte, og dette er måske det vigtigste, skal I gentænke arbejdet i stedet for blot at føje AI til arbejdet. Hvis min udviklingsproces har tolv trin, og AI gør trin fire 70 procent hurtigere, har jeg ikke transformeret udviklingen. Jeg har fremskyndet trin fire.
• Og endelig, beskyt menneskelig dømmekraft, samtidig med at I aggressivt eliminerer menneskeligt rutinearbejde.

Jeg mener, at CTO'er har en sjælden mulighed lige nu. Spørg ikke blot, hvordan AI gør jeres nuværende organisation mere effektiv. Spørg, hvilken organisation I ville bygge, hvis I startede i dag. Det er det mere ubehagelige spørgsmål. Det er også det spørgsmål, der vil adskille de virksomheder, som blot bruger AI, fra de virksomheder, der faktisk transformerer sig på grund af den.

Følg med

Du kan følge Tyrone Grandisons arbejde på LinkedIn og hans personlige hjemmeside. Du kan også se hans bøger, AI-revolutionen og Kultur, der varer ved.

Der kommer flere ekspertinterviews på CTO-klubben!