Teknikchef säger att AI behöver en ny styrmodell

Tyrone Grandison har haft många roller på C-nivå under sin 35-åriga karriär inom teknik, och han är för närvarande CTO på Cornerstone Assurance Corporation. Han är också författare till AI-revolutionen och en kultur som består.

Vi pratade med Tyrone för att ta reda på hur AI förändrar styrningen i teknikorganisationer. Här är vad han berättade.

35 år inom teknik

Jag leder en slimmad teknikorganisation som stödjer ett växande företag inom försäkring och finansiella tjänster som heter Cornerstone Assurance Corporation. Det som gör rollen särskilt intressant är att vi bygger en modern teknikstack samtidigt som vi verkar i en bransch med omfattande regulatoriska krav, känsliga finansiella uppgifter, komplexa integrationer med försäkringsbolag och mycket liten tolerans för att göra fel.

Jag började min karriär som datavetare, långt innan AI blev ämnet för varje styrelserumssamtal och konferensens huvudanförande. Under årens lopp tog mitt arbete mig från att bygga teknik till att leda organisationer genom det som tekniken gjorde med dem. Jag har varit chef för artificiell intelligens, teknikchef, informationschef och biträdande dataansvarig. Jag har arbetat inom offentlig verksamhet, akademi, nystartade företag, konsultverksamhet, ideella organisationer och stora företag.

Efter 35 år inom teknik har jag haft förmånen att se flera saker introduceras som ”tekniken som kommer att förändra allt”. Och några av dem gjorde faktiskt det.

Varje större förändring tvingar ledare att fatta beslut innan de har perfekt information. Den utmanar affärsmodeller, verksamhetsmodeller, kultur, kompetens, styrning och ibland vår förståelse av vad våra egna jobb egentligen ska vara. AI gör allt detta på en gång.

Men det som gör den här stunden särskilt fascinerande för mig är att vi har gått längre än att AI bara hjälper oss att analysera information. Vi har nu system som kan generera, resonera, planera, skapa, skriva kod, använda verktyg och i allt högre grad vidta åtgärder. Det förändrar ledarskapsdiskussionen i grunden.

Frågan brukade vara: ”Vad kan AI göra?”

Jag tror att det snabbt håller på att bli den minst intressanta frågan. Till och med fel fråga.

De mycket viktigare frågorna är: Vad bör vi tillåta den att göra? Var förblir mänskligt omdöme avgörande? Hur utformar vi om organisationer när insikter i sig blir överflödande? Och hur tar vi till vara på den extraordinära potentialen i den här tekniken utan att skapa risker vi inte förstår eller system som vi inte kan styra?

Det är där mitt arbete finns i dag. Jag arbetar med chefer och organisationer för att hjälpa dem skilja signalen från den betydande mängden brus kring AI, förstå vad som faktiskt förändras och omsätta den förståelsen i strategi, styrning, produkter och mätbara affärsresultat.

Hur AI förändrar livscyklerna för programvaruutveckling

En av de största förändringarna jag genomförde på Cornerstone Assurance Corporation var att utforma om vår livscykel för programvaruutveckling utifrån antagandet att AI kommer att skriva en betydande andel av vår kod.

Före den förändringen följde vi ett ganska traditionellt arbetsflöde för utveckling. En utvecklare tog sig an ett krav, utformade lösningen, skrev koden, skapade tester, skickade in en kodändringsförfrågan och fick den granskad av en annan utvecklare. Vi använde naturligtvis automatisering, men människor utförde fortfarande det mesta av det kognitiva arbetet från krav till driftsättning.

AI förändrade ekonomin i den modellen fullständigt.

Därför införde vi en AI-assisterad utvecklingspipeline med GitHub Copilot för kodgenerering och refaktorering, ChatGPT och Claude för AI-styrd arkitektonisk utforskning, kravuppdelning, felsökning och generering av testfall, medan våra vanliga verktyg för CI/CD och säkerhet tillhandahåller de deterministiska kontrollerna kring det AI-genererade arbetet.

Varför AI-genererad kod kräver en ny styrningsmodell

Men den viktiga förändringen var inte: ”Hörni allihop, nu har ni Copilot.” Vi ändrade styrningsmodellen.

Godkännandesteg

Vi behandlar nu AI-genererad kod nästan som kod som skickats in av en mycket snabb junior utvecklare som aldrig sover, har läst en absurd mängd dokumentation och ibland säger något helt fel med enormt självförtroende.

Det innebär att AI kan generera kod, enhetstester, API-kontrakt, dokumentation, databasfrågor, infrastrukturdefinitioner och föreslagna korrigeringar, men den kan inte godkänna sitt eget arbete eller ha en okontrollerad väg till produktion.

Vi införde uttryckliga mänskliga godkännandesteg för säkerhetskänsliga ändringar, autentisering och auktorisering, hantering av kund- och finansiella uppgifter, externa integrationer och produktionsinfrastruktur.

Automatiserade tester

Vi utökade också de automatiserade testerna och kodgranskningen eftersom flaskhalsen förflyttades. När AI dramatiskt ökar hastigheten med vilken du kan producera kod upphör kodgenerering att vara ditt problem. Ditt problem blir att bevisa att koden förtjänar att köras.

Ett enkelt exempel är att skapa tester. Tidigare kunde en ingenjör implementera en funktion och sedan skriva de uppenbara enhetstesterna. Nu kan vi be AI att även generera adversariella testfall. Vad händer med felaktiga indata? Vad händer när ett API returnerar ett oväntat svar? Vad händer vid en behörighetsgräns? Vad händer när en kundpost innehåller ofullständiga uppgifter?

Det ger den mänskliga ingenjören en annan uppgift. I stället för att ägna all sin tid åt att producera artefakter ägnar hen mer tid åt att ifrågasätta antaganden och validera kodens beteende.

Styrning av AI

Vi ändrade också hur vi styr själva AI:n. Vi loggar AI-assisterad aktivitet där det är lämpligt, håller känslig kundinformation borta från AI-verktyg för konsumenter, kontrollerar vilka modeller och tjänster som kan få åtkomst till företagsdata och skiljer experiment från produktionsåtkomst. Inom försäkrings- och finanstjänster kommer ”modellen tyckte att det här var en bra idé” aldrig att utgöra en styrningsstrategi.

Hur AI förändrar teknikens flaskhals

Det största resultatet jag har sett av att integrera AI i våra tekniska arbetsflöden är snabbhet, men jag lägger alltid till en brasklapp till det svaret eftersom snabbhet i fel riktning inte är produktivitet.

AI har dramatiskt komprimerat vår utvecklingscykel. Vi ser arbete som tidigare tog en utvecklare flera dagar gå från krav till testbar implementation på några timmar. För prototyper specifikt skulle jag uppskatta att vi har minskat cykeltiden med ungefär 50 till 70 procent.

Och dokumentationen har förmodligen gett den minst glamorösa, men mest omedelbara effektivitetsvinsten. API-dokumentation, versionsanteckningar, testdokumentation, kodförklaringar och första utkast till tekniska specifikationer behöver inte längre börja med en blinkande markör. AI producerar de första 70 eller 80 procenten, och mitt team ägnar sin tid åt att korrigera och förbättra i stället för att skapa allt från grunden.

Men det finns en nackdel, och jag tycker att teknikledare behöver prata mer om den: AI gör det otroligt billigt att snabbt producera dålig kod.

Vi upptäckte att den begränsande faktorn förflyttas nedströms. Om jag kan generera fem gånger så mycket kod, men människor fortfarande måste förstå, granska, testa, säkra, distribuera, övervaka och underhålla den, har jag inte nödvändigtvis ökat systemets genomströmning. Jag kan helt enkelt ha skapat en trafikstockning vid kodgranskningen.

Det har förmodligen varit den mest värdefulla lärdomen för mig. Jag optimerar inte längre primärt min teknikorganisation för hur snabbt vi kan skriva programvara. AI gör snabbt den delen till en standardiserad handelsvara. Jag optimerar för hur snabbt vi kan bevisa att programvara förtjänar att köras i produktion. Det är en helt annan teknikorganisation.

Var AI får komma till tals kontra var AI får rösta

Jag har blivit ganska noggrann med att skilja på två saker: var AI får en röst och var AI får en röst i besluten. I vår organisation har AI nu en röst i nästan varje steg av vår tekniska livscykel. Det får inte vara med och fatta beslut i varje fråga.

Några exempel:

• Arkitektur: Vi använder ChatGPT och Claude som arkitektoniska diskussionspartners. Om vi utformar en ny tjänst kan jag ge modellen våra krav, begränsningar, befintliga gränssnitt, säkerhetsgränser, förväntad transaktionsvolym och felscenarier. Jag ber den föreslå flera arkitekturer, identifiera avvägningar, ifrågasätta våra antaganden och till och med argumentera mot sin egen rekommendation. Det jag inte gör är att fråga: ”Vilken arkitektur bör vi använda?” och sedan bygga vad som än kommer tillbaka. Det slutliga arkitekturbeslutet förblir mänskligt eftersom arkitektur omfattar ett sammanhang som sträcker sig långt bortom teknisk optimering. Jag måste ta hänsyn till vår affärsstrategi, våra regulatoriska skyldigheter, vår operativa mognad, vår riskaptit, våra kostnader, vår tekniska skuld och vad mitt team faktiskt kan stödja klockan 02.00 på natten.
• Kod: Där ger vi AI betydligt större handlingsutrymme. Vi använder GitHub Copilot för kodgenerering, refaktorering, dokumentation och skapande av enhetstester. Vi använder också ChatGPT och Claude för att felsöka defekter, utforska implementeringsmetoder och generera adversariella testfall. AI kan skriva en första implementation otroligt snabbt. En mänsklig ingenjör ansvarar fortfarande för pull-förfrågan och godkänner det som slutligen sammanfogas.
• Testning: Det här har förmodligen förskjutits längst i riktning mot AI. Jag tycker om att använda AI för att fråga: ”Hur skulle du få det här att gå sönder?” Vi kan hitta fall som en utvecklare, som precis har ägnat två dagar åt att bygga funktionen, omedvetet kanske förbiser. AI blir en mycket billig och extremt uthållig motståndare.
• Säkerhet: Här vänder jag medvetet på ekvationen. AI hjälper oss att identifiera sårbarheter, granska kodmönster, modellera hot och generera attackscenarier, men som jag sa behåller människor ansvaret för säkerhetsgodkännande, beslut om identitet och åtkomst, hantering av känsliga data och undantag. Promptinjektion och utlämnande av känslig information är fortfarande erkända risker i LLM-tillämpningar, så att ansluta AI till företagssystem kräver fler kontroller, inte färre.
• Incidenthantering: Det här befinner sig någonstans mitt emellan. AI kan läsa in loggar, korrelera händelser, sammanfatta tusentals rader telemetri, föreslå sannolika grundorsaker och rekommendera åtgärder. Det kan drastiskt korta ned de första 30 minuterna av en incident. Men om någon vill inaktivera en produktionstjänst, rulla tillbaka en kritisk driftsättning, ändra en säkerhetspolicy eller vidta en åtgärd som påverkar kunder, är det en människa som fattar beslutet.
• Prioritering av backloggen: Jag använder samma regel här. AI kan analysera supportärenden, teknisk arbetsinsats, beroenden, produktanvändning och affärsmål och säga: ”Så här skulle jag prioritera de här 40 sakerna, och här är varför.” Det är otroligt användbart. Men AI förstår inte vår strategi bättre än vi gör. Produkt- och teknikledare fattar det slutliga prioriteringsbeslutet.

Min regel är alltså ganska enkel: AI får större autonomi när åtgärden går att återställa, observera och testa och får begränsade konsekvenser. Mänsklig beslutanderätt ökar när en åtgärd blir svårare att återställa eller får större påverkan på kunder, ekonomi, säkerhet, regelverk eller anseende.

Ett verklighetsnära tekniskt arbetsflöde

Här är ett exempel på ett arbetsflöde från ”krav till produktion med AI i loopen”. Säg att vi behöver lägga till en ny funktion i ett agentarbetsflöde som hämtar kund- och policyinformation, tillämpar en uppsättning affärsregler och rekommenderar lämplig nästa åtgärd:

1. Det börjar med kravet. I stället för att en ingenjör tar emot en löst formulerad uppgift och omedelbart börjar koda använder vi ChatGPT eller Claude för att granska kravet. Vi ger det användarberättelsen, acceptanskriterierna, relevanta affärsregler, API-kontrakt och tekniska begränsningar. Sedan ber vi det identifiera oklarheter, saknade gränsfall, beroenden, säkerhetsproblem och frågor som vi bör besvara innan någon skriver kod. Det låter enkelt, men det fångar upp en överraskande mängd kostsam förvirring i ett tidigt skede.
2. Nästa steg är arkitektur och uppdelning av uppgiften. Vi använder Claude och ChatGPT för att utforska implementeringsalternativ och dela upp kraven i komponenter. Modellen kan identifiera en API-ändring, en ändring av datamodellen, ett integrationsberoende, auktoriseringskrav, telemetri och nödvändiga testfall. Vi ber den också argumentera mot den föreslagna arkitekturen. En mänsklig ingenjör fattar arkitekturbeslutet. AI tillhandahåller alternativ. Vi tar ansvar för konsekvenserna.
3. Därefter går vi över till implementation. Vi använder GitHub Copilot i utvecklingsmiljön för att generera standardkod, implementera väldefinierade funktioner, omstrukturera kod, skapa API-klienter, förklara obekanta delar av kodbasen och generera dokumentation. Ingenjören går från att skriva varje rad till att styra, granska och finslipa implementationen. Den skillnaden är viktig. Jag vill inte att utvecklare ska bli mycket dyra autokompletteringsoperatörer. Jag vill att de ska tänka på systemet.
4. Sedan ger vi ChatGPT eller Claude kravet och implementationen och säger i princip: “Bra. Bryt det nu.” AI hjälper till att generera antagonistiska scenarier, och Copilot hjälper till att omvandla dem till automatiserade enhets- och integrationstester.
5. Därefter tar den deterministiska maskineriet över. Pull-begäran går in i vår CI/CD-pipeline. Vi kör automatiserade tester, statisk analys, skanning efter beroenden och sårbarheter samt våra vanliga kvalitetsgrindar. En mänsklig ingenjör granskar pull-begäran.
6. Sedan distribuerar vi stegvis. Ändringen går genom utvecklings- och testmiljöer innan den når produktion. När det är lämpligt använder vi funktionsflaggor eller kontrollerade utrullningsmönster så att vi kan begränsa exponeringen, observera beteendet och snabbt rulla tillbaka.
7. Och AI:s uppgift är fortfarande inte avslutad. När funktionen körs blir AI en assistent för observerbarhet. Vi använder det för att sammanfatta loggar, koppla samman felmönster, analysera oväntat beteende och hjälpa ingenjörer att mycket snabbare gå från “något är fel” till en plausibel grundorsak.

Så förändrar du ingenjörers arbetssätt med AI

Jag önskar att jag tidigare hade förstått att det är enkelt att ge ingenjörer AI-verktyg. Den svåra delen är att förändra ingenjörernas arbetssätt.

När vi först började använda verktyg som GitHub Copilot, ChatGPT och Claude närmade jag mig utrullningen på det sätt som många teknikledare gör. Ge duktiga ingenjörer kraftfulla verktyg, inför några väl avvägda skyddsräcken och vänta på att produktiviteten ska öka.

Det gjorde den, men inte enhetligt och inte alltid på de sätt jag hade förväntat mig.

Det första jag lärde mig var att tillgång inte är detsamma som användning, och att användning inte är detsamma som färdighet.

Två ingenjörer kan ha exakt samma AI-verktyg och få helt olika resultat. Den ena behandlar AI som autokomplettering och sparar några tangenttryckningar. Den andra lär sig hur man tillhandahåller kontext, delar upp problem, ifrågasätter resultat, genererar tester, utforskar alternativ och använder modellen som en teknisk diskussionspartner. Produktivitetsskillnaden mellan dessa två personer kan bli enorm.

Jag skulle ha investerat i AI-kompetens och arbetsmetoder mycket tidigare. Inte “här är en två timmar lång kurs i promptteknik”, utan praktiska exempel baserade på vårt faktiska ingenjörsarbete.

Tyrones kommentarer

Jag skulle ha investerat i AI-kompetens och arbetsmetoder mycket tidigare. Inte “här är en två timmar lång kurs i promptteknik”, utan praktiska exempel baserade på vårt faktiska ingenjörsarbete.

Så förändrar AI teknikledarskapet

Vi ägnar mycket tid åt att fråga oss vad AI kommer att göra med utvecklare, arkitekter, analytiker och andra tekniska roller. Jag tycker att CTO:er behöver vända på frågan och rikta den mot oss själva.

Under större delen av min karriär har teknikledning belönat den som vet saker som andra inte vet. Erfarenhet gav förmågan att känna igen mönster. Teknisk expertis gav auktoritet. Man kunde gå in i ett rum och ge ett svar som kanske hade tagit någon annan flera dagar att hitta.

Nu kan jag ge alla tillgång till ett otroligt kraftfullt AI-system. Det förändrar ledarskapet.

Jag anser inte längre att mitt värde som CTO kommer från att ha svaren. Det kommer från att ställa bättre frågor, tillhandahålla sammanhang, göra avvägningar, utöva gott omdöme och skapa en miljö där människor och maskiner gör varandra bättre.

Det kräver ödmjukhet. AI kommer ibland att identifiera ett tillvägagångssätt som jag inte övervägde. En junior ingenjör med goda AI-kunskaper kan ifrågasätta ett antagande som någon med 25 års erfarenhet betraktar som självklart. Jag tycker att bra teknikledare behöver välkomna det.

CTO:n i AI-eran kan inte helt enkelt vara den smartaste tekniska personen i rummet. Vi måste bli de personer som utformar rummet. Vem får komma till tals? Vad får AI besluta? Var förblir mänskligt omdöme avgörande? Hur vet vi när vi har fel?

Det är den ledarskapsförändringen.

Varför CTO:er bör vara försiktiga med effektivitetsvinster

Mitt viktigaste råd till CTO:er just nu är detta: Förväxla inte att arbeta snabbt med att göra framsteg.

Det finns ett enormt tryck på teknikledare att ”göra något med AI”. Styrelser frågar om det. Vd:ar frågar om det. Medarbetare använder det redan, oavsett om ni har en policy eller inte. Alla leverantörer har plötsligt upptäckt att deras produkt har varit ”AI-drivna” hela tiden.

Det är mycket lätt att bli reaktiv. Men jag tycker att CTO:ns uppgift just nu är att skapa klarhet mitt i allt detta brus.

• För det första, använd tekniken själv. Och jag menar verkligen använd den. Bygg inte hela din AI-strategi utifrån analytikerrapporter och leverantörsdemonstrationer. Jag använder verktyg som ChatGPT, Claude och GitHub Copilot eftersom jag behöver förstahandserfarenhet av var de är enastående, var de misslyckas och hur snabbt de gränserna förändras. Du kan inte effektivt leda en teknisk omställning som du bara upplever genom PowerPoint.
• För det andra, börja med verksamhetens begränsningar, inte med AI:s möjligheter. Jag är mycket mindre intresserad av att fråga ”Var kan vi använda generativ AI?” än av att fråga ”Var är vi långsamma, dyra, inkonsekventa, kapacitetsbegränsade eller orsakar frustration hos kunderna?” Därefter kan jag avgöra om AI faktiskt hör hemma i lösningen.
• För det tredje, åtgärda era grundförutsättningar. AI kommer inte att rädda dåliga data, svaga API:er, bristande observerbarhet, obefintlig dokumentation eller dysfunktionella utvecklingsmetoder. Ofta kommer den att förstärka dem. AI fungerar som en förstärkare av den underliggande organisationen och det tekniska systemet.
• För det fjärde, utforma styrningen utifrån konsekvenser, inte rädsla. Jag vill inte ha en AI-policy på 47 sidor som i praktiken säger: ”Gör inget intressant, tack.” Jag vill ha kontroller som står i proportion till risken. Låt människor experimentera aggressivt där åtgärderna går att återställa och får små konsekvenser. Öka den mänskliga tillsynen när besluten börjar påverka kunddata, pengar, säkerhet, regulatoriska skyldigheter eller produktionssystem.
• För det femte, och detta kan vara det viktigaste, förändra arbetet i stället för att bara lägga till AI i arbetet. Om min utvecklingsprocess har tolv steg och AI gör steg fyra 70 procent snabbare har jag inte förändrat utvecklingsarbetet. Jag har snabbat upp steg fyra.
• Och slutligen, skydda det mänskliga omdömet samtidigt som ni aggressivt eliminerar människans slitsamma rutinarbete.

Jag tycker att CTO:er har en sällsynt möjlighet just nu. Fråga inte bara hur AI gör er nuvarande organisation effektivare. Fråga vilken organisation ni skulle bygga om ni började i dag. Det är den mer obekväma frågan. Det är också den som kommer att skilja företagen som helt enkelt använder AI från företagen som faktiskt omvandlas tack vare den.

Följ med

Du kan följa Tyrone Grandisons arbete på LinkedIn och hans personliga webbplats. Du kan också läsa hans böcker AI-revolutionen och En kultur som består.

Fler expertintervjuer kommer på CTO-klubben!