5 vanliga mönster som orsakar AI-misslyckanden

Adam Horner har byggt ingenjörsteam inom fintech och företagsprogramvara. Nu är han grundare av The CTO Playbook, där han utbildar och arbetar som deltids-CTO.

Vi satte oss ner med honom för att ta reda på vilka mönster han ser bakom framgångarna och misslyckandena med AI-integration. Här är vad han berättade.

Någon variant av samma utmaning

Jag heter Adam Horner och är CTO-coach samt deltids-CTO på The CTO Playbook. Under den tidigare delen av min karriär arbetade jag som ingenjör och medgrundande CTO, där jag byggde och ledde ingenjörsteam inom fintech och företagsprogramvara, bland annat flera år på Palantir som en av deras första anställda i Storbritannien.

Övergången till coachning började med en enkel observation: Att bli en effektiv teknikchef är verkligen svårt, och de flesta tar sig igenom det utan en färdplan eller någon vid sin sida som har gått igenom samma sak. Det är det jag arbetar med nu – att hjälpa CTO:er att ta sig över det jag kallar CTO-klyftan.

AI-perspektivet är inte en separat tråd för mig. Det löper genom nästan varje coachningssamtal jag har, eftersom alla CTO:er jag arbetar med navigerar någon variant av samma utmaning: Hur leder man en organisation genom en transformation av den här omfattningen, på den specifika nivå där man befinner sig, med det specifika team man har, och kommer ut på andra sidan som ett starkare företag?

Den röriga mitten av tillväxtkurvan

Min egen organisation är liten och medvetet slimmad, ett grundarteam på fyra personer som bygger helt AI-först. Vi använder den erfarenheten för att hålla oss nära verkligheten i produktutveckling i tidiga skeden. Jag arbetar också som deltids-CTO åt en fintech-startup före ackreditering, där jag hanterar de särskilda påfrestningarna med att få ut en reglerad produkt på marknaden med hjälp av ett externt utvecklingsteam.

Men den bredare bilden, och där den verkliga bredden av organisatorisk exponering kommer ifrån, är de CTO:er jag coachar. Det sträcker sig från grundarteam och tidiga bootstrappade startups via snabbväxande, riskkapital- och private equity-finansierade scaleups till medelstora företag som hanterar verklig organisatorisk komplexitet, och vidare till företag med flera avdelningar som verkar i stor skala.

Den röriga mitten av tillväxtkurvan är där jag tillbringar det mesta av min tid, och det är där ledarskapsutmaningarna brukar vara som störst.

Hur AI låter ingenjörer se den större bilden

För mig har den viktigaste förändringen inte varit ett verktyg eller en process, utan en förväntan. Som ledare, när du ger teamet tillåtelse – och ännu viktigare, skyldigheten – att ompröva hela leveranslivscykeln från grunden, spelar omfattningen av den omprövningen roll. Det handlar inte bara om hur kod skrivs eller distribueras, utan om allt som leveransprocessen berör: kundsupport, användarvärde och den affärsavsikt som ligger bakom varje enskilt arbete.

När kostnaden för att skriva och underhålla kod var hög, var det på ett visst sätt logiskt att hålla ingenjörerna strikt fokuserade på det tekniska problemet. Men den kostnaden har rasat. Den begränsande faktorn är inte längre hur snabbt du kan bygga, utan hur tydligt alla inblandade förstår vad som faktiskt är värt att bygga och varför.

Ingenjörer som förstår produkten, kunden och affärsmålen bakom en förändring kan fatta beslut och agera på sätt som helt enkelt inte var möjliga tidigare. Det som förbättrades var inte ett mått. Det var kvaliteten på de frågor som teamet började ställa innan de skrev en enda rad.

Adams tankar

Den begränsande faktorn är inte längre hur snabbt du kan bygga, utan hur tydligt alla inblandade förstår vad som faktiskt är värt att bygga och varför.

Hur triage- och korrigeringscykler kan kortas ner med AI

Ett exempel handlade om att tänka om kring hur kundsupport och ingenjörsteam samarbetade kring bekräftade buggar. Tidigare tog triage- och korrigeringscykler dagar eller veckor, medan supportteamen hanterade frustrerade kunder under tiden och ingenjörerna fick bära kostnaden för distraktionen från aktiva problem parallellt med sitt övriga arbete. När leveranslivscykeln omprövades med AI-assisterad utveckling i bilden kortades korrigeringscyklerna dramatiskt, och stora delar av processen automatiserades.

Det innebar mer arbete för supportfunktionen i början, genom att fånga upp och kategorisera problemen tydligt, men vinsten var att problemen löstes på timmar i stället för dagar. Ingenjörerna kunde behålla fokus. Kunderna fick svar snabbare. Gränssnittet mellan två funktioner som alltid hade accepterats som långsamma visade sig vara helt möjligt att omförhandla.

Varför organisationer inte bör kasta AI på allt

När det gäller vad som bör vara en mänsklig uppgift respektive en AI-uppgift ser det olika ut för varje organisation. Den rätta utgångspunkten är inte en lista över aktiviteter, utan en tydlig förståelse av var ert värde finns och var era risker är koncentrerade.

De delar av processen som är kärnan i det verksamheten gör — logiken, det som särskiljer verksamheten och de områden där ett misslyckande blir synligt eller kostsamt — förtjänar mänskligt skapande och mänsklig tillsyn. Allt annat befinner sig på en skala.

Ett cybersäkerhetsföretag kommer att lägga betydande mänsklig uppmärksamhet på säkerhetsegenskaperna i sin kod, eftersom det är själva verksamheten. Ett företag inom arbetsflödesautomatisering kan lägga samma noggrannhet på beslutslogiken i ett kritiskt arbetsflöde, samtidigt som det betraktar säkerhetsverktyg som något AI kan hantera tillräckligt bra.

Det som är fel är att tillämpa en generell policy åt något av hållen. Frågan att ställa är inte "Kan AI göra detta?" utan "Vad kostar det om detta går fel?"

Och här är en annan sak: En överraskande stor del av den komplexitet som människor vill automatisera är egentligen olösta processproblem. Lös det först. Det kommer att göra det renare och billigare att införa AI senare.

Adam delar med sig

Den rätta utgångspunkten är inte en lista över aktiviteter, utan en tydlig förståelse av var ert värde finns och var era risker är koncentrerade.

Varför CTO:er måste börja med att automatisera leveransen, inte koden

Det är verkligen svårt att jämföra AI-resultat mellan organisationer eftersom de flesta ledare, både inom teknik och i verksamheten i stort, fortfarande har svårt att tydligt mäta effekten av och avkastningen på sina AI-investeringar. Utan det är det svårt att veta hur ett bra resultat faktiskt ser ut, och ännu svårare att argumentera för att göra mer av det.

Men överlag är spannet av AI-resultat stort. I ena änden har jag arbetat med organisationer som i praktiken har eliminerat sin ärendebalans och nu arbetar direkt utifrån kundvärde och verksamhetens mål, vilket innebär en grundläggande förändring av hur utvecklingen förhåller sig till resten av verksamheten.

Jag lade märke till ett gemensamt mönster hos de organisationer som uppnådde detta: Ingen av dem började på vänster sida av programvaruutvecklingens livscykel. De började inte med kodgenerering. De började till höger: CI/CD-pipelines, trygghet i driftsättningen och automatiserad kodgranskning. Det var skapandet av en robust och tillförlitlig leveransdel av processen som först skapade förutsättningarna för allt annat. Därefter skiftade fokus till tester, begränsningar och kontroller före genereringen, samt till struktur framför hastighet.

De team som gjorde störst framsteg var de som arbetade mest självständigt, inte för att de hade tagit bort mänskliga bedömningar, utan för att de hade byggt in tillräckligt mycket av dem i sin process för att med tillförsikt kunna ta sig an betydligt större arbetsdelar. Ärendebalansen försvann inte för att de skrev kod snabbare. Den försvann för att hela relationen mellan avsikt och leverans blev entydig.

I den andra änden har jag sett verklig personalavgång drivas av det växande gapet mellan dem som rör sig snabbt med AI och dem som inte gör det. När AI-användningen börjar finns det nästan alltid en liten grupp som rör sig snabbt och en större grupp som inte gör det, och den naturliga impulsen är att låta de snabba gå före. Det som detta i tysthet och snabbt skapar är friktion, misstro och misstänksamhet mellan team, vilket urholkar vinsterna snabbare än de tidiga framstegen hinner byggas upp. Det råd jag nu ger i början av varje uppdrag är detsamma: lämna ingen efter. Takten i införandet bör avgöras av hur snabbt ni kan få med er hela organisationen, inte av hur snabbt era mest entusiastiska ingenjörer kan röra sig individuellt.

En organisation i två hastigheter känns som framsteg från fronten. Från baksidan känns det som att bli lämnad efter, och den känslan får konsekvenser.

Varför en organisations kunskapsbas måste omformas för AI

Den tydligaste bristen jag har sett i AI:s förmågor gäller beslutsfattande under osäkerhet.

AI är i grunden en förutsägelsemotor, och förutsägelse är inte samma sak som omdöme. AI har inget personligt intresse i spelet, ingen känsla för konsekvenser och inget ansvar för resultatet. Att förvänta sig att AI ska fatta beslut åt dig kommer aldrig att bli bättre än dess förmåga att förutsäga, vilket är begränsat i genuint osäkra eller nya situationer. De organisationer som har blivit mest besvikna på AI är vanligtvis de som förlitade sig på det just i sådana ögonblick.

Det andra området där effekten inte når upp till förväntningarna, mer i det tysta men lika betydelsefullt, är där konsekvenserna av kontextfönster är dåligt förstådda. Mata in ofullständig eller dåligt strukturerad kontext i ett AI-system, så kommer det ändå att ge dig ett självsäkert svar. Att känna skillnaden mellan ett välinformerat resultat och ett som bara låter trovärdigt kräver mänskligt omdöme, något som ännu inte har utvecklats hos tillräckligt många team.

Därför är en organisations kunskapsbas avgörande. Med det menar jag all den kontext som för närvarande finns i människors huvuden: hur saker alltid har gjorts, standardmetoderna och de oskrivna reglerna för hur organisationen faktiskt fungerar. AI kan inte arbeta med institutionell kunskap som aldrig har gjorts extern, och de flesta organisationer sitter på enorma mängder av den.

Den goda nyheten är att det inte krävs en perfekt struktur för att få ut kunskapen. Multimodala AI-system innebär att en videogenomgång, ett grovt diagram och ett oredigerat dokument alla utgör meningsfulla indata. Prioriteten är att först göra kunskapen extern och därefter strukturera den.

Det jag konsekvent ser är att själva arbetet med att få ut den här kontexten ur människors huvuden och in i någon form av dokumentation är värdefullt i sig, innan AI ens kommer in i bilden. Det synliggör avvikelser, blottlägger bristfälliga antaganden och avslöjar trasiga arbetsflöden som ingen hade lagt märke till eftersom de var alltför insyltade i dem.

Den grunden mångdubblar sedan allt AI kan göra därefter. Det är en av de investeringar där en CTO kan få störst hävstång just nu, och samtidigt en av de saker som konsekvent förbises, trots att försäljare inom automatisering av affärsprocesser har berättat detta för oss i åratal!

Så förhindrar du att skeptiska utvecklare bromsar en organisation

Ett vanligt problem jag ser är egentligen inte ett misslyckande med AI. Det är ett misslyckande med införandet, och det brukar följa ett igenkännbart mönster.

En skeptisk utvecklare – och det finns förvånansvärt många av dem – gör ett halvhjärtat försök med minimal kontext, får ett dåligt resultat och presenterar resultatet som bevis på att AI inte klarar uppgiften. Slutsatsen uttrycks med självsäkerhet. Metoden granskas sällan. Det som gör detta till mer än bara individuell frustration är följdeffekten.

Att integrera AI i ett team eller i en utvecklingslivscykel är ett lagarbete, och några få ingenjörer som är motiverade att visa att det inte fungerar kan bromsa hela organisationen, inte bara sin egen produktion.

Den lärdom jag drar av detta handlar inte om AI:s begränsningar. Det handlar om att införandet är lika mycket en ledarskapsutmaning som en teknisk sådan. Kvaliteten på det AI producerar är oupplösligt förknippad med kvaliteten på den kontext och avsikt du tillför, och att bygga upp den förståelsen i ett team kräver samma medvetna insats som alla andra betydande förändringar av hur människor arbetar. Det är så vi förändrar uppfattningen från bristfällig ”magi” till användbar ”avancerad teknik”.

Adam delar med sig

En skeptisk utvecklare gör ett halvhjärtat försök med minimalt sammanhang, får ett dåligt resultat och presenterar sedan resultatet som bevis på att AI inte kan utföra jobbet. Slutsatsen framförs med säkerhet. Metoden granskas sällan.

Varför små team är en fördel med AI

Antagandet att ett fungerande och produktivt utvecklingsteam behövde ett visst antal personer för att kunna bära tillräckligt mycket sammanhang och hålla ett meningsfullt tempo har inte överlevt mötet med hur AI-assisterad utveckling faktiskt fungerar.

Den begränsande faktorn i alla team har alltid varit kognitiv: hur mycket sammanhang varje person kan hålla i huvudet, hur tydligt de kan kommunicera det till människorna omkring sig och hur mycket energi den kommunikationen förbrukar. Det som har förändrats är att den enhet som utför arbetet inte längre bara är en person. Varje person i teamet kör flera agenter, och dessa agenter bär och tillämpar sammanhang på sätt som förändrar hela beräkningen. Amazons tvåpizzaregel var en rimlig tumregel i en värld före AI.

Här är ett exempel.

En organisation jag arbetar med hade alltid velat ha ett internt administrationsgränssnitt för sin plattform, men kunde aldrig motivera investeringen. Tidigare hade de beräknat det som ett arbete för hela teamet under flera månader. I stället satte de två personer på uppgiften: båda med djup kunskap om verksamheten och den befintliga plattformen, hög självständighet och en tydlig uppsättning begränsningar att arbeta inom. Sex veckor senare hade de en fungerande första version.

Dessa två personers verksamhetskunskap visade sig vara lika viktig som AI-verktygen. Färre frågor, mindre omkostnader, snabbare beslut. Men det mest värdefulla resultatet var inte själva verktyget. Det var vad organisationen lärde sig om hur man arbetar på det här sättet.

De team jag ser arbeta mest effektivt nu består av mellan två och tre personer, där varje person kör flera agenter, och det är inte en begränsning. För rätt typ av arbete är det en fördel.

Varför frekvent kommunikation är avgörande i AI-drivna arbetsflöden

Samarbete kan bli svårt med AI.

Det behövs mycket frekventare kommunikation eftersom allt går snabbare. Det är en av anledningarna till att mindre team fungerar bättre just nu.

Det verkar helt enkelt vara för utmattande att upprätthålla tillstånd och konsekvens i ett stort team med flera parallella agentbaserade kodningsprocesser per person. Vissa team jag arbetar med har gått över till två dagliga ståmöten för att upprätthålla konsekvens.

Varför CTO:er måste se upp med skugg-AI

Skugg-AI är det tidigare observerade problemet med skugg-IT, fast med en ny budget och ett nytt namn.

Okontrollerad och obegränsad användning av AI-verktyg i hela företaget kan lätt öka riskerna för förlust av data och immateriella rättigheter — ”exfiltrering”, som CISO:n kallar det — ofta helt oavsiktligt från användarnas sida.

De flesta organisationer rör sig snabbt bort från steg 1 i CMM (experimentfasen i ”vilda västern”) för att införa policyer och tekniska begränsningar som minskar riskerna.

Varför CTO:er måste fokusera på sin egen utveckling

Adams tankar

De ledare som kommer starkast ur den här perioden är inte nödvändigtvis de som har de bästa verktygen eller de största teamen. Det är de som bygger upp omdömet, inflytandet och klarheten i tänkandet för att kunna leda väl när ingen har en tydlig karta.

Det finns just nu mycket oro i branschen över vad AI innebär för utvecklingsteam, för antalet anställda och för själva rollen.

Huruvida den oron är befogad är nästan en bisak. Det viktiga är att vi befinner oss i en period av betydande och snabba förändringar, och att navigera väl genom den kräver ledare som aktivt utvecklar sin egen förmåga, inte bara hanterar förändringen omkring sig.

Det som fortfarande överraskar mig, med tanke på allt som händer, är hur många CTO:er och seniora teknikledare som arbetar utan någon riktad investering i sin egen utveckling. Ingen coach, ingen strukturerad utveckling, ingen samtalspartner för reflektion. Jag gjorde det misstaget en gång tidigare, och misstagen jag gjorde och tiden jag förlorade var inte oundvikliga.

De ledare som kommer starkast ur den här perioden är inte nödvändigtvis de som har de bästa verktygen eller de största teamen. Det är de som bygger upp omdömet, inflytandet och klarheten i tänkandet för att kunna leda väl när ingen har en tydlig karta.

Följ med

Du kan följa Adam Horners arbete på LinkedIn. För individuell coachning, gruppkurser och podden, gå till The CTO Playbook. Och för en kostnadsfri e-postkurs på fem dagar för CTO:er i ett tidigt skede, gå till Early CTO Map.

Fler expertintervjuer kommer på The CTO Club!