CTO sier at AI trenger en ny styringsmodell

Tyrone Grandison har hatt mange roller på C-nivå i løpet av sin 35 år lange karriere innen teknologi, og er for tiden teknologidirektør i Cornerstone Assurance Corporation. Han er også forfatteren av AI-revolusjonen og Kultur som varer.

Vi snakket med Tyrone for å lære hvordan kunstig intelligens endrer styringen i teknologiorganisasjoner. Her er det han fortalte oss.

35 år innen teknologi

Jeg leder en slank teknologiavdeling som støtter en voksende virksomhet innen forsikring og finansielle tjenester, kalt Cornerstone Assurance Corporation. Det som gjør rollen spesielt interessant, er at vi bygger en moderne teknologistakk samtidig som vi opererer i en bransje med omfattende regulatoriske krav, sensitive finansielle data, komplekse integrasjoner med forsikringsgivere og svært liten toleranse for å gjøre feil.

Jeg startet karrieren som informatiker, lenge før kunstig intelligens ble temaet i alle styreromssamtaler og hovedinnlegg på konferanser. Gjennom årene førte arbeidet mitt meg fra å bygge teknologi til å lede organisasjoner gjennom det teknologien gjorde med dem. Jeg har vært sjef for kunstig intelligens, teknologidirektør, informasjonssjef og stedfortredende datasjef. Jeg har jobbet i offentlig sektor, akademia, oppstartsbedrifter, konsulentvirksomhet, ideelle organisasjoner og store konserner.

Etter 35 år innen teknologi har jeg hatt privilegiet av å se flere ting bli introdusert som «teknologien som vil endre alt». Og noen av dem gjorde faktisk det.

Ethvert stort skifte tvinger ledere til å ta beslutninger før de har fullstendig informasjon. Det utfordrer forretningsmodeller, driftsmodeller, kultur, talenter, styring og noen ganger vår forståelse av hva våre egne jobber egentlig skal innebære. Kunstig intelligens gjør alt dette på én gang.

Men det som gjør dette øyeblikket spesielt fascinerende for meg, er at vi har beveget oss forbi kunstig intelligens som noe som bare hjelper oss med å analysere informasjon. Nå har vi systemer som kan generere, resonnere, planlegge, skape, skrive kode, bruke verktøy og i stadig større grad handle. Det endrer lederskapssamtalen fundamentalt.

Spørsmålet pleide å være: «Hva kan kunstig intelligens gjøre?»

Jeg tror raskt dette er i ferd med å bli det minst interessante spørsmålet. Til og med det feilaktige spørsmålet.

De langt viktigere spørsmålene er: Hva bør vi tillate at den gjør? Hvor er menneskelig dømmekraft fortsatt avgjørende? Hvordan redesigner vi organisasjoner når innsikt i seg selv blir rikelig tilgjengelig? Og hvordan utnytter vi det enorme potensialet i denne teknologien uten å skape risikoer vi ikke forstår, eller systemer vi ikke kan styre?

Det er her arbeidet mitt ligger i dag. Jeg samarbeider med ledere og organisasjoner for å hjelpe dem med å skille signalet fra den betydelige mengden støy rundt kunstig intelligens, forstå hva som faktisk endrer seg, og omsette denne forståelsen til strategi, styring, produkter og målbare forretningsresultater.

Hvordan kunstig intelligens endrer livssykluser for programvareutvikling

En av de største endringene jeg gjorde i Cornerstone Assurance Corporation, var å redesigne livssyklusen for programvareutvikling basert på antakelsen om at kunstig intelligens vil skrive en betydelig andel av koden vår.

Før denne endringen fulgte vi en ganske tradisjonell arbeidsflyt for utvikling. En utvikler tok ansvar for et krav, utformet løsningen, skrev koden, opprettet tester, sendte inn en forespørsel om sammenslåing, og en annen utvikler gjennomgikk den. Vi brukte selvsagt automatisering, men mennesker utførte fortsatt det meste av det kognitive arbeidet fra krav til distribusjon.

Kunstig intelligens endret økonomien i denne modellen fullstendig.

Derfor innførte vi en AI-assistert utviklingspipeline med GitHub Copilot til kodegenerering og refaktorering, ChatGPT og Claude til AI-ledet arkitektonisk utforskning, nedbryting av krav, feilsøking og generering av testtilfeller, mens våre vanlige CI/CD- og sikkerhetsverktøy sørget for de deterministiske kontrollene rundt det AI-genererte arbeidet.

Hvorfor AI-generert kode krever en ny styringsmodell

Men den viktige endringen var ikke: «Hei alle sammen, nå har dere Copilot.» Vi endret styringsmodellen.

Godkjenningsporter

Vi behandler nå AI-generert kode nesten som kode sendt inn av en svært rask juniorutvikler som aldri sover, har lest en absurd mengde dokumentasjon, og av og til sier noe som er fullstendig feil med enorm selvsikkerhet.

Det betyr at KI kan generere kode, enhetstester, API-kontrakter, dokumentasjon, databasespørringer, infrastrukturdefinisjoner og foreslåtte løsninger, men den kan ikke godkjenne sitt eget arbeid eller ha en ukontrollert vei til produksjon.

Vi innførte eksplisitte godkjenningsporter for mennesker for sikkerhetsfølsomme endringer, autentisering og autorisasjon, håndtering av kunde- og finansielle data, eksterne integrasjoner og produksjonsinfrastruktur.

Automatisert testing

Vi utvidet også automatisert testing og kodegjennomgang fordi flaskehalsen flyttet seg. Når KI dramatisk øker hvor raskt du kan produsere kode, slutter problemet ditt å være kodegenerering. Problemet blir å bevise at koden fortjener å kjøres.

Et enkelt eksempel er opprettelse av tester. Tidligere kunne en utvikler implementere en funksjon og deretter skrive de åpenbare enhetstestene. Nå kan vi også be KI om å generere kontradiktoriske testtilfeller. Hva skjer med ugyldige inndata? Hva skjer når et API returnerer et uventet svar? Hva skjer ved en tilgangsgrense? Hva skjer når en kundeoppføring inneholder ufullstendige data?

Det gir den menneskelige utvikleren en annen jobb. I stedet for å bruke all tiden sin på å produsere artefakter bruker de mer tid på å utfordre antakelser og validere kodeatferd.

Styring av KI

Vi endret også hvordan vi styrer selve KI-en. Vi logger KI-assistert aktivitet der det er hensiktsmessig, holder sensitiv kundeinformasjon borte fra kommersielle KI-verktøy, kontrollerer hvilke modeller og tjenester som kan få tilgang til virksomhetsdata, og skiller eksperimentering fra produksjonstilgang. I forsikring og finansielle tjenester vil «modellen mente at dette var en god idé» aldri utgjøre en styringsstrategi.

Hvordan KI flytter flaskehalsen i utviklingen

Det største resultatet jeg har sett av å integrere KI i utviklingsarbeidsflytene våre, er hastighet, men jeg føyer alltid til en fotnote til det svaret fordi hastighet i feil retning ikke er produktivitet.

KI har dramatisk komprimert utviklingssyklusen vår. Vi ser arbeid som tidligere tok en utvikler flere dager, gå fra krav til testbar implementasjon på timer. For prototyping spesifikt vil jeg anslå at vi har redusert syklustiden med omtrent 50 til 70 prosent.

Og dokumentasjon har sannsynligvis gitt den minst glamorøse, men mest umiddelbare effektivitetsgevinsten. API-dokumentasjon, versjonsnotater, testdokumentasjon, kodeforklaringer og førsteutkast til tekniske spesifikasjoner trenger ikke lenger begynne med en blinkende markør. KI produserer de første 70 eller 80 prosentene, og teamet mitt bruker tiden på å korrigere og forbedre i stedet for å skape alt fra grunnen av.

Men det finnes en ulempe, og jeg mener teknologiledere må snakke mer om dette: KI gjør det utrolig billig å produsere dårlig kode raskt.

Vi oppdaget at den begrensende faktoren flytter seg nedstrøms. Hvis jeg kan generere fem ganger så mye kode, men mennesker fortsatt må forstå, gjennomgå, teste, sikre, distribuere, overvåke og vedlikeholde den, har jeg ikke nødvendigvis økt systemgjennomstrømningen. Jeg kan ganske enkelt ha skapt en trafikkork i kodegjennomgangen.

Det har sannsynligvis vært den mest verdifulle lærdommen for meg. Jeg optimaliserer ikke lenger utviklingsorganisasjonen min primært for hvor raskt vi kan skrive programvare. KI gjør raskt denne delen til en standardvare. Jeg optimaliserer for hvor raskt vi kan bevise at programvaren fortjener å kjøres i produksjon. Det er en helt annen utviklingsorganisasjon.

Hvor KI får uttale seg, kontra hvor den får stemme

Jeg har blitt ganske bevisst på å skille mellom to ting: hvor AI får en stemme, og hvor AI får en stemmeberettiget avgjørelse. I organisasjonen vår har AI nå en stemme i nesten alle faser av teknologiens livssyklus. Den får ikke avgjøre alle beslutninger.

Noen eksempler:

• Arkitektur: Vi bruker ChatGPT og Claude som arkitektoniske sparringspartnere. Hvis vi designer en ny tjeneste, kan jeg gi modellen kravene våre, begrensningene, eksisterende grensesnitt, sikkerhetsgrenser, forventet transaksjonsvolum og feilsituasjoner. Jeg ber den foreslå flere arkitekturer, identifisere avveininger, utfordre antakelsene våre og til og med argumentere mot sin egen anbefaling. Det jeg ikke gjør, er å spørre: «Hvilken arkitektur bør vi bruke?» og deretter bygge det som kommer tilbake. Den endelige arkitekturbeslutningen forblir menneskelig, fordi arkitektur innebærer kontekst som går langt utover teknisk optimalisering. Jeg må ta hensyn til forretningsstrategien vår, regulatoriske forpliktelser, operasjonell modenhet, risikotoleranse, kostnader, teknisk gjeld og hva teamet mitt faktisk kan støtte klokken 02.00 om natten.
• Kode: Her gir vi AI betydelig større spillerom. Vi bruker GitHub Copilot til kodegenerering, refaktorering, dokumentasjon og oppretting av enhetstester. Vi bruker også ChatGPT og Claude til å feilsøke, utforske implementeringstilnærminger og generere motstandskraftige testtilfeller. AI kan skrive en første implementasjon utrolig raskt. En menneskelig utvikler har fortsatt ansvaret for pull-forespørselen og godkjenner det som til slutt flettes inn.
• Testing: Dette har sannsynligvis beveget seg lengst i retning av AI. Jeg liker å bruke AI til å spørre: «Hvordan ville du ødelagt dette?» Vi kan finne tilfeller som en utvikler som nettopp har brukt to dager på å bygge funksjonen, ubevisst kan ha oversett. AI blir en svært rimelig og ekstremt utholdende motstander.
• Sikkerhet: Det er her jeg bevisst snur på forholdet. AI hjelper oss med å identifisere sårbarheter, undersøke kodemønstre, modellere trusler og generere angrepsscenarioer, men som nevnt beholder mennesker myndigheten over sikkerhetsgodkjenning, beslutninger om identitet og tilgang, håndtering av sensitive data og unntak. Prompt-injeksjon og avsløring av sensitiv informasjon er fortsatt anerkjente risikoer i LLM-applikasjoner, så det å koble AI til virksomhetssystemer krever flere kontroller, ikke færre.
• Hendelseshåndtering: Dette befinner seg et sted imellom. AI kan ta inn logger, sammenstille hendelser, oppsummere tusenvis av linjer med telemetri, foreslå sannsynlige grunnårsaker og anbefale tiltak. Det kan komprimere de første 30 minuttene av en hendelse dramatisk. Men hvis noen ønsker å deaktivere en produksjonstjeneste, rulle tilbake en kritisk utrulling, endre en sikkerhetspolicy eller gjennomføre et tiltak som påvirker kundene, er det et menneske som tar beslutningen.
• Prioritering av oppgaver: Jeg bruker samme regel her. AI kan analysere supportsaker, utviklingsinnsats, avhengigheter, produktbruk og forretningsmål og si: «Slik ville jeg prioritert disse 40 tingene, og her er hvorfor.» Det er utrolig nyttig. Men AI forstår ikke strategien vår bedre enn vi gjør. Produkt- og teknologiledere tar den endelige prioriteringsbeslutningen.

Regelen min er derfor ganske enkel: AI får mer selvstendighet når handlingen kan reverseres, observeres og testes, og har små konsekvenser. Menneskelig myndighet øker når en handling blir vanskeligere å reversere eller innebærer større konsekvenser for kunder, økonomi, sikkerhet, regelverk eller omdømme.

En realistisk arbeidsflyt for utvikling

Her er et eksempel på en arbeidsflyt fra «krav til produksjon med AI i loopen». La oss si at vi må legge til en ny funksjon i en agentarbeidsflyt som henter kunde- og policyinformasjon, bruker et sett med forretningsregler og anbefaler det riktige neste tiltaket:

1. Det begynner med kravet. I stedet for at en utvikler mottar en vagt formulert oppgave og begynner å kode med en gang, bruker vi ChatGPT eller Claude til å granske kravet. Vi gir det brukerhistorien, akseptansekriteriene, relevante forretningsregler, API-kontrakter og tekniske begrensninger. Deretter ber vi det identifisere uklarheter, manglende grenseverdier, avhengigheter, sikkerhetsproblemer og spørsmål vi bør besvare før noen skriver kode. Det høres enkelt ut, men det avdekker overraskende mye kostbar forvirring tidlig.
2. Deretter kommer arkitektur og oppdeling av oppgaver. Vi bruker Claude og ChatGPT til å utforske implementeringsalternativer og dele kravene opp i komponenter. Modellen kan identifisere en API-endring, en endring i datamodellen, en integrasjonsavhengighet, autorisasjonskrav, telemetri og nødvendige testtilfeller. Vi ber den også argumentere mot den foreslåtte arkitekturen. En menneskelig utvikler tar arkitekturbeslutningen. AI gir alternativer. Vi tar ansvar for konsekvensene.
3. Deretter går vi over til implementeringen. Vi bruker GitHub Copilot i utviklingsmiljøet til å generere standardkode, implementere veldefinerte funksjoner, refaktorere kode, opprette API-klienter, forklare ukjente deler av kodebasen og generere dokumentasjon. Utvikleren går fra å skrive hver linje til å styre, gjennomgå og forbedre implementeringen. Dette skillet er viktig. Jeg vil ikke at utviklere skal bli svært dyre autoutfyllingsoperatører. Jeg vil at de skal tenke på systemet.
4. Deretter gir vi ChatGPT eller Claude kravet og implementeringen og sier i praksis: «Flott. Nå skal du ødelegge den.» AI hjelper med å generere motstandsdyktige scenarier, og Copilot hjelper med å gjøre dem om til automatiserte enhets- og integrasjonstester.
5. Deretter tar de deterministiske mekanismene over. Pull-forespørselen går inn i CI/CD-pipelinen vår. Vi kjører automatiserte tester, statisk analyse, skanning av avhengigheter og sårbarheter samt våre vanlige kvalitetskontroller. En menneskelig utvikler gjennomgår pull-forespørselen.
6. Deretter distribuerer vi trinnvis. Endringen går gjennom utvikling og staging før produksjon. Når det er hensiktsmessig, bruker vi funksjonsbrytere eller kontrollerte utrullingsmønstre slik at vi kan begrense eksponeringen, observere atferden og rulle raskt tilbake.
7. Og AI er fortsatt ikke ferdig med jobben. Når funksjonen kjører, blir AI en assistent for overvåking. Vi bruker den til å oppsummere logger, knytte sammen feilmønstre, analysere uventet atferd og hjelpe utviklere med å gå fra «noe er galt» til en sannsynlig rotårsak mye raskere.

Slik endrer du utvikleratferd med AI

Jeg skulle ønske jeg tidligere hadde forstått at det er enkelt å gi utviklere AI-verktøy. Det vanskelige er å endre utvikleratferden.

Da vi først begynte å bruke verktøy som GitHub Copilot, ChatGPT og Claude, gikk jeg frem på samme måte som mange teknologiledere gjør. Gi dyktige utviklere kraftige verktøy, etabler noen fornuftige retningslinjer, og vent på at produktiviteten skal øke.

Det gjorde den, men ikke jevnt og ikke alltid på de måtene jeg forventet.

Det første jeg lærte, var at tilgang ikke er det samme som bruk, og at bruk ikke er det samme som ferdighet.

To utviklere kan ha nøyaktig det samme AI-verktøyet og få svært ulike resultater. Den ene behandler AI som autoutfylling og sparer noen få tastetrykk. Den andre lærer hvordan man gir kontekst, deler opp problemer, utfordrer resultater, genererer tester, utforsker alternativer og bruker modellen som en teknisk diskusjonspartner. Produktivitetsforskjellen mellom disse to personene kan bli enorm.

Jeg ville ha investert i AI-kompetanse og arbeidsmetoder mye tidligere. Ikke «her er et to timers kurs i instruksjonsutforming», men praktiske eksempler basert på det faktiske utviklingsarbeidet vårt.

Tyrone kommenterer

Jeg ville ha investert i AI-kompetanse og arbeidsmetoder mye tidligere. Ikke «her er et to timers kurs i instruksjonsutforming», men praktiske eksempler basert på det faktiske utviklingsarbeidet vårt.

Slik forvandler AI teknologiledelse

Vi bruker mye tid på å spørre hva kunstig intelligens vil gjøre med utviklere, arkitekter, analytikere og andre tekniske roller. Jeg mener CTO-er må snu på spørsmålet og rette det mot oss selv.

Gjennom det meste av karrieren min har teknologiledelse belønnet det å kunne ting andre ikke kunne. Erfaring ga deg evnen til å gjenkjenne mønstre. Teknisk ekspertise ga deg autoritet. Du kunne gå inn i et rom og gi et svar som det kunne ha tatt noen andre flere dager å finne.

Nå kan jeg gi alle tilgang til et utrolig kapabelt kunstig intelligens-system. Det endrer ledelse.

Jeg tror ikke lenger at verdien min som CTO kommer av å ha svarene. Den kommer av å stille bedre spørsmål, gi kontekst, foreta avveininger, utøve dømmekraft og skape et miljø der mennesker og maskiner gjør hverandre bedre.

Det krever ydmykhet. Kunstig intelligens vil noen ganger identifisere en tilnærming jeg ikke hadde vurdert. En juniorutvikler med gode ferdigheter innen kunstig intelligens kan utfordre en antakelse som noen med 25 års erfaring anser som opplagt. Jeg mener gode teknologiledere må ønske dette velkommen.

CTO-en i kunstig intelligens-æraen kan ikke ganske enkelt være den smarteste tekniske personen i rommet. Vi må bli menneskene som utformer rommet. Hvem får en stemme? Hva skal kunstig intelligens få bestemme? Hvor er menneskelig dømmekraft fortsatt avgjørende? Hvordan vet vi når vi tar feil?

Dette er lederskapets transformasjon.

Hvorfor CTO-er bør være forsiktige med effektivitetsgevinster

Mitt viktigste råd til CTO-er akkurat nå er dette: Ikke forveksle det å bevege seg raskt med å gjøre fremskritt.

Det er et enormt press på teknologiledere om å «gjøre noe med kunstig intelligens». Styrene spør om det. Administrerende direktører spør om det. De ansatte bruker det allerede, enten dere har en policy eller ikke. Alle leverandører har plutselig oppdaget at produktet deres har vært «drevet av kunstig intelligens» hele tiden.

Det er svært lett å bli reaktiv. Men jeg mener CTO-ens oppgave akkurat nå er å skape klarhet midt i all denne støyen.

• For det første: Bruk teknologien selv. Og jeg mener virkelig bruk den. Ikke bygg AI-strategien din utelukkende på analyserapporter og leverandørdemonstrasjoner. Jeg bruker verktøy som ChatGPT, Claude og GitHub Copilot fordi jeg trenger førstehåndserfaring med hvor enestående de er, hvor de svikter, og hvor raskt disse grensene flytter seg. Du kan ikke lede en teknologisk overgang effektivt når du bare opplever den gjennom PowerPoint.
• For det andre: Ta utgangspunkt i virksomhetens begrensninger, ikke i mulighetene til kunstig intelligens. Jeg er langt mindre interessert i å spørre «Hvor kan vi bruke generativ kunstig intelligens?» enn i å spørre «Hvor er vi trege, dyre, inkonsekvente, kapasitetsbegrensede eller skaper frustrasjon hos kundene?» Deretter kan jeg avgjøre om kunstig intelligens faktisk hører hjemme i løsningen.
• For det tredje: Fiks grunnlaget ditt. Kunstig intelligens vil ikke redde dårlige data, svake API-er, mangelfull overvåkbarhet, fraværende dokumentasjon eller dysfunksjonell utviklingspraksis. Den vil ofte forsterke dem. Kunstig intelligens fungerer som en forsterker av den underliggende organisasjonen og det tekniske systemet.
• For det fjerde: Utform styring basert på konsekvenser, ikke frykt. Jeg vil ikke ha en AI-policy på 47 sider som i praksis sier «Vennligst ikke gjør noe interessant». Jeg vil ha kontroller som står i forhold til risikoen. La folk eksperimentere offensivt der handlingene kan reverseres og konsekvensene er små. Øk menneskelig tilsyn når beslutninger begynner å påvirke kundedata, penger, sikkerhet, regulatoriske forpliktelser eller produksjonssystemer.
• For det femte, og dette kan være det viktigste, må du redesigne arbeidet i stedet for bare å legge kunstig intelligens til arbeidet. Hvis utviklingsprosessen min har tolv trinn og kunstig intelligens gjør trinn fire 70 prosent raskere, har jeg ikke transformert utviklingen. Jeg har fremskyndet trinn fire.
• Og til slutt: Beskytt menneskelig dømmekraft samtidig som du aggressivt eliminerer menneskelig rutinearbeid.

Jeg mener CTO-er har en sjelden mulighet akkurat nå. Ikke bare spør hvordan kunstig intelligens gjør den nåværende organisasjonen din mer effektiv. Spør hvilken organisasjon du ville ha bygget hvis du startet i dag. Det er det mer ubehagelige spørsmålet. Det er også det som vil skille selskapene som bare bruker kunstig intelligens, fra selskapene som faktisk forvandler seg på grunn av den.

Følg med

Du kan følge Tyrone Grandisons arbeid på LinkedIn og på hans personlige nettsted. Du kan også se nærmere på bøkene hans, AI-revolusjonen og Kultur som varer.

Flere ekspertintervjuer kommer i CTO-klubben!