5 almindelige mønstre, der forårsager AI-fejl

Adam Horner har opbygget ingeniørteams inden for fintech og virksomhedssoftware. Nu er han grundlægger af The CTO Playbook, hvor han underviser og arbejder som ekstern CTO.

Vi satte os ned med ham for at høre, hvilke mønstre han ser bag succeserne og fiaskoerne med AI-integration. Her er, hvad han fortalte os.

En eller anden version af den samme udfordring

Jeg er Adam Horner, CTO-coach og ekstern CTO hos The CTO Playbook. Jeg tilbragte den første del af min karriere som ingeniør og medstiftende CTO, hvor jeg opbyggede og ledede ingeniørteams inden for fintech og virksomhedssoftware, herunder flere år hos Palantir som en af deres første medarbejdere i Storbritannien.

Overgangen til coaching udsprang af en enkel observation: Det er oprigtigt svært at blive en effektiv teknologileder, og de fleste navigerer i det uden en køreplan eller nogen på deres side, der har været igennem det før. Det er det, jeg arbejder med nu, hvor jeg hjælper CTO'er med at krydse det, jeg kalder CTO-kløften.

AI-vinklen er for mig ikke en separat tråd. Den går gennem næsten alle de coachingsamtaler, jeg har, fordi alle de CTO'er, jeg arbejder med, navigerer i en eller anden version af den samme udfordring: Hvordan leder man en organisation gennem en transformation af denne størrelse på det specifikke stadie, med det specifikke team, og kommer ud på den anden side som en stærkere virksomhed?

Den rodede midte af vækstkurven

Min egen organisation er lille og bevidst slank, et stifterteam på fire, der udelukkende bygger AI-baserede løsninger, hvor vi bruger den erfaring til at holde os tæt på realiteterne i produktudvikling på et tidligt stadie. Jeg arbejder også som ekstern CTO for en fintech-startup, der endnu ikke er akkrediteret, og navigerer i det særlige pres, der følger med at bringe et reguleret produkt på markedet med et eksternt udviklingsteam.

Men det bredere billede, og dér hvor den virkelige dybde i den organisatoriske eksponering kommer fra, er de CTO'er, jeg coacher. Det spænder fra stifterteams og tidlige bootstrap-startups til højvækstvirksomheder understøttet af venturekapital og private equity, videre til mellemstore virksomheder, der håndterer reel organisatorisk kompleksitet, og op til virksomheder med flere afdelinger, der opererer i stor skala.

Den rodede midte af vækstkurven er dér, jeg bruger det meste af min tid, og det er dér, ledelsesudfordringerne typisk er skarpest.

Hvordan AI giver ingeniører mulighed for at se det større billede

For mig har den mest betydningsfulde ændring ikke været et værktøj eller en proces; det har været en forventning. Som leder, når du giver teamet tilladelse — og endnu vigtigere, forpligtelsen — til at revurdere hele leverancens livscyklus fra bunden, har omfanget af denne revurdering betydning. Ikke kun hvordan kode skrives eller implementeres, men alt det, leveranceprocessen berører: kundesupport, brugerværdi og den forretningsmæssige intention bag et givent stykke arbejde.

Da omkostningerne ved at skrive og vedligeholde kode var høje, gav det en vis mening at holde ingeniørerne tæt fokuseret på det tekniske problem. Men den omkostning er kollapset. Den begrænsende faktor er ikke længere, hvor hurtigt man kan bygge; det er, hvor tydeligt alle involverede forstår, hvad der faktisk er værd at bygge, og hvorfor.

Ingeniører, der forstår produktet, kunden og forretningsmålene bag en ændring, kan træffe beslutninger og bevæge sig på måder, der ganske enkelt ikke var mulige før. Det, der blev forbedret, var ikke en måling. Det var kvaliteten af de spørgsmål, teamet begyndte at stille, før de skrev en eneste linje.

Adams tanker

Den begrænsende faktor er ikke længere, hvor hurtigt man kan bygge; det er, hvor tydeligt alle involverede forstår, hvad der faktisk er værd at bygge, og hvorfor.

Hvordan sorterings- og fejlretningscyklusser kan forkortes med AI

Et eksempel involverede en nytænkning af, hvordan kundesupport og udvikling interagerede omkring bekræftede fejl. Tidligere blev sorterings- og fejlretningscyklusser målt i dage eller uger, mens supportteams håndterede frustrerede kunder undervejs, og ingeniørerne bar omkostningen ved forstyrrelser fra aktive problemer sideløbende med deres øvrige arbejde. Da leverancens livscyklus blev revurderet med AI-understøttet udvikling i billedet, blev fejlretningscyklusserne forkortet markant, og en stor del af processen blev automatiseret.

Det lagde mere arbejde på supportfunktionen i begyndelsen, hvor problemer skulle registreres og kategoriseres tydeligt, men gevinsten var løsninger inden for få timer i stedet for dage. Ingeniørerne kunne bevare fokus. Kunderne fik hurtigere svar. Grænsefladen mellem to funktioner, som altid bare var blevet accepteret som langsom, viste sig at kunne genforhandles fuldstændigt.

Hvorfor organisationer ikke bør kaste AI efter alting

Hvad angår, hvad der bør være en menneskelig opgave kontra en AI-opgave, er det forskelligt for hver organisation. Det rigtige udgangspunkt er ikke en liste over aktiviteter, men en klar forståelse af, hvor jeres værdi ligger, og hvor jeres risiko er koncentreret.

De dele af processen, der er centrale for det, virksomheden laver — logikken, differentieringen og de områder, hvor fejl er synlige eller dyre — berettiger menneskelig skabelse og menneskeligt tilsyn. Alt andet befinder sig på et spektrum.

En cybersikkerhedsvirksomhed vil bruge betydelig menneskelig opmærksomhed på sikkerhedsegenskaberne i sin kode, fordi det er selve forretningen. En virksomhed inden for automatisering af arbejdsgange vil måske rette den samme grundighed mod beslutningslogikken i en kritisk arbejdsgang, mens den behandler sikkerhedsværktøjer som noget, AI kan håndtere tilstrækkeligt.

Det forkerte er at anvende en generel politik i den ene eller den anden retning. Spørgsmålet, man bør stille, er ikke "Kan AI gøre dette?" Det er "Hvad er omkostningen, hvis det går galt?"

Og her er en anden ting: En overraskende stor del af den kompleksitet, som folk ønsker at automatisere, er faktisk uafklaret procesgæld. Få styr på det først. Det vil gøre implementeringen af AI lettere og billigere senere.

Adam deler

Det rigtige udgangspunkt er ikke en liste over aktiviteter, men en klar forståelse af, hvor jeres værdi ligger, og hvor jeres risiko er koncentreret.

Hvorfor CTO'er skal begynde med at automatisere levering, ikke kode

Det er oprigtigt svært at sammenligne AI-resultater på tværs af organisationer, fordi de fleste ledere, både inden for teknologi og i den bredere virksomhed, stadig kæmper med tydeligt at måle effekten og ROI'en af deres AI-investeringer. Uden det er det svært at vide, hvordan et godt resultat faktisk ser ud, og endnu sværere at argumentere for at gøre mere af det.

Men overordnet set spænder AI-resultaterne vidt. I den ene ende har jeg arbejdet med organisationer, der reelt har elimineret deres efterslæb og nu arbejder direkte ud fra kundeværdi og forretningsmæssige mål, hvilket repræsenterer en grundlæggende ændring i den måde, udvikling forholder sig til resten af virksomheden på.

Jeg bemærkede et fælles mønster i de organisationer, der opnåede dette: Ingen af dem begyndte i venstre side af softwareudviklingens livscyklus. De begyndte ikke med kodegenerering. De startede til højre: CI/CD-pipelines, sikkerhed i forbindelse med implementering og automatiseret kodegennemgang. Det var det, der skabte forudsætningerne for alt andet, at gøre leveringsdelen af processen robust og pålidelig først. Derfra flyttede fokus sig til test, begrænsninger og kontroller før generering samt til struktur frem for hastighed.

De hold, der gjorde de største fremskridt, var dem, der arbejdede mest autonomt, ikke fordi de havde fjernet menneskelig dømmekraft, men fordi de havde indarbejdet tilstrækkeligt af den i deres proces til, at de trygt kunne påtage sig væsentligt større arbejdsopgaver. Efterslæbet forsvandt ikke, fordi de skrev kode hurtigere. Det forsvandt, fordi hele forholdet mellem intention og levering blev entydigt.

I den anden ende har jeg set reel medarbejderafgang drevet af den voksende kløft mellem dem, der bevæger sig hurtigt med AI, og dem, der ikke gør. Når AI-implementeringen begynder, er der næsten altid en lille gruppe, der bevæger sig hurtigt, og en større gruppe, der ikke gør, og det naturlige instinkt er at lade dem, der bevæger sig hurtigt, fortsætte. Det, det stille og hurtigt skaber, er gnidninger, mistillid og mistænksomhed mellem hold, hvilket nedbryder gevinsterne hurtigere, end de tidlige fremskridt kan opbygge dem. Det råd, jeg nu giver i begyndelsen af hvert samarbejde, er det samme: Lad ingen i stikken. Tempoet for implementeringen bør bestemmes af, hvor hurtigt I kan få hele organisationen med jer, ikke af hvor hurtigt jeres mest entusiastiske udviklere individuelt kan bevæge sig.

En organisation med to hastigheder føles som fremskridt set forfra. Set bagfra føles det som at blive efterladt, og den følelse har konsekvenser.

Hvorfor en organisations vidensbase skal redesignes til AI

Det tydeligste hul, jeg har set i AI's evner, er inden for beslutningstagning under usikkerhed.

AI er grundlæggende en forudsigelsesmotor, og forudsigelse er ikke det samme som dømmekraft. Den har ikke noget på spil, ingen fornemmelse for konsekvenser og intet ejerskab over resultatet. At forvente, at den træffer beslutninger på dine vegne, vil kun være så godt som dens evne til at forudsige, hvilket i reelt usikre eller nye situationer er begrænset. De organisationer, der er blevet mest skuffede over AI, er som regel dem, der netop har støttet sig til den i sådanne øjeblikke.

Det andet område, hvor effekten ikke slår til, mere stille, men lige så betydningsfuldt, er dér, hvor konsekvenserne af kontekstvinduer er dårligt forstået. Giv en AI ufuldstændig eller dårligt struktureret kontekst, og den vil stadig give dig et selvsikkert svar. At kende forskel på et velinformeret resultat og et, der blot lyder plausibelt, kræver menneskelig dømmekraft, som endnu ikke er udviklet hos tilstrækkeligt mange teams.

Derfor er en organisations vidensbase afgørende. Med det mener jeg al den kontekst, der i øjeblikket findes i folks hoveder: måden tingene altid er blevet gjort på, standardtilgangene og de uskrevne regler for, hvordan organisationen faktisk fungerer. AI kan ikke arbejde med institutionel viden, der aldrig er blevet gjort ekstern, og de fleste organisationer rummer enorme mængder af den.

Den gode nyhed er, at det ikke kræver, at den er perfekt struktureret, at få den ud. Multimodal AI betyder, at en videogennemgang, et groft diagram og et uredigeret dokument alle er meningsfulde input. Prioriteten er eksternalisering først, struktur bagefter.

Det, jeg konsekvent finder, er, at selve handlingen med at få denne kontekst ud af folks hoveder og ind i en eller anden form for dokumentation er værdifuld i sig selv, før AI overhovedet berører den. Den synliggør uoverensstemmelser, afslører dårlige antagelser og afdækker ødelagte arbejdsgange, som ingen havde bemærket, fordi de var for indlejrede i dem.

Dette fundament mangedobler derefter alt det, AI kan gøre. Det er en af de investeringer, der giver størst løft for en CTO at bruge tid på lige nu, og en af de ting, der konsekvent overses mest, til trods for at sælgere af automatisering af forretningsprocesser har fortalt os det i årevis!

Sådan forhindrer du skeptiske udviklere i at bremse en organisation

Et almindeligt problem, jeg ser, er ikke rigtig en fejl ved AI. Det er en fejl i implementeringen, og den følger ofte et genkendeligt mønster.

En skeptisk udvikler — og der er overraskende mange af dem — gør et halvhjertet forsøg med minimal kontekst, får et dårligt resultat og præsenterer dette resultat som bevis på, at AI ikke kan udføre opgaven. Konklusionen fremsættes med selvsikkerhed. Metoden bliver sjældent undersøgt. Det, der gør dette til mere end blot en individuel frustration, er den afledte effekt.

AI-integration i et team eller en udviklingslivscyklus er en holdsport, og nogle få ingeniører, der er motiverede for at demonstrere, at det ikke virker, kan bremse hele organisationen, ikke kun deres eget resultat.

Den lære, jeg drager af dette, handler ikke om AI's begrænsninger. Den handler om, at implementering i lige så høj grad er en ledelsesudfordring som en teknisk udfordring. Kvaliteten af det, AI producerer, kan ikke adskilles fra kvaliteten af den kontekst og intention, du tilfører, og det kræver den samme bevidste indsats som enhver anden væsentlig ændring af den måde, mennesker arbejder på, at opbygge denne forståelse i et team. Det er sådan, vi ændrer opfattelsen fra fejlfri "magi" til anvendelig "avanceret teknologi".

Adam deler

En skeptisk udvikler gør et halvhjertet forsøg med minimal kontekst, får et dårligt resultat og præsenterer dette resultat som bevis på, at AI ikke kan udføre opgaven. Konklusionen fremsættes med sikkerhed. Metoden bliver sjældent undersøgt.

Hvorfor små teams er en fordel med AI

Antagelsen om, at et velfungerende og produktivt udviklingsteam skulle have et bestemt antal medlemmer for at kunne rumme tilstrækkelig kontekst og bevæge sig fremad i et meningsfuldt tempo, har ikke overlevet mødet med den måde, AI-assisteret udvikling faktisk fungerer på.

Den begrænsende faktor i ethvert team har altid været kognitiv: hvor meget kontekst hver person kan rumme, hvor klart de kan kommunikere den til menneskerne omkring sig, og hvor meget energi denne kommunikation kræver. Det, der har ændret sig, er, at den enhed, der udfører arbejdet, ikke længere kun er et menneske. Hver person på teamet kører flere agenter, og disse agenter bærer og anvender kontekst på måder, der ændrer regnestykket fuldstændigt. Amazons to-pizza-regel var en rimelig tommelfingerregel i en verden før AI.

Her er et eksempel.

En organisation, jeg arbejder med, havde altid ønsket sig en intern administrationsgrænseflade til deres platform, men kunne aldrig retfærdiggøre investeringen. Tidligere havde de beregnet den som en indsats for hele teamet over flere måneder. I stedet satte de to personer på opgaven: Begge havde dyb viden om forretningen og den eksisterende platform, høj grad af selvstændighed og et klart sæt begrænsninger at arbejde inden for. Seks uger senere havde de en fungerende første version.

De to personers kendskab til forretningen viste sig at være lige så vigtigt som AI-værktøjerne. Færre spørgsmål, mindre overhead, hurtigere beslutninger. Men det mest værdifulde resultat var ikke selve værktøjet. Det var det, organisationen lærte om, hvordan man arbejder på denne måde.

De teams, jeg nu ser fungere mest effektivt, består af mellem to og tre personer, som hver kører flere agenter, og det er ikke en begrænsning. Til den rigtige type arbejde er det en fordel.

Hvorfor hyppig kommunikation er afgørende i AI-drevne arbejdsgange

Samarbejde kan blive vanskeligt med AI.

Der er behov for langt hyppigere kommunikation, fordi alting bevæger sig hurtigere. Det er en af grundene til, at mindre teams fungerer bedre, som situationen er lige nu.

Det virker ganske enkelt for udmattende at opretholde status og konsistens i et stort team med flere parallelle agentbaserede kodningsprocesser pr. person. Nogle teams, jeg arbejder med, er gået over til to daglige standupmøder for at bevare konsistensen.

Hvorfor CTO'er skal holde øje med skygge-AI

Skygge-AI er det tidligere observerede problem med skygge-IT, blot med et nyt budget og et nyt navn.

Ukontrolleret og ubegrænset brug af AI-værktøjer på tværs af virksomheden kan let øge risikoen for tab af data og intellektuel ejendom — "eksfiltration", som CISO'en kalder det — ofte helt utilsigtet fra brugernes side.

De fleste organisationer bevæger sig hurtigt ud af trin 1 i CMM (eksperimenteringsfasen i det "vilde vesten") for at indføre politikker og tekniske begrænsninger, der reducerer risiciene.

Hvorfor CTO'er skal fokusere på deres egen udvikling

Adams tanker

De ledere, der kommer stærkest ud af denne periode, er ikke nødvendigvis dem med de bedste værktøjer eller de største teams. Det er dem, der opbygger dømmekraften, indflydelsen og klarheden i tænkningen til at lede godt, når ingen har et tydeligt kort.

Der er stor bekymring i branchen lige nu over, hvad AI betyder for udviklingsteams, for antallet af medarbejdere og for selve rollen.

Om denne bekymring er berettiget, er næsten underordnet. Det vigtige er, at vi befinder os i en periode med betydelige og hurtige forandringer, og at det kræver ledere, som aktivt udvikler deres egne evner, ikke blot administrerer forandringerne omkring dem, hvis de skal navigere godt i den.

Det, der stadig overrasker mig, når man tager alt det, der sker, i betragtning, er, hvor mange CTO'er og teknologiledere på højt niveau der arbejder uden nogen målrettet investering i deres egen udvikling. Ingen coach, ingen struktureret udvikling, ingen sparringspartner. Jeg begik selv den fejl én gang før, og de fejl, jeg begik, samt den tid, jeg spildte, var ikke uundgåelige.

De ledere, der kommer stærkest ud af denne periode, er ikke nødvendigvis dem med de bedste værktøjer eller de største teams. Det er dem, der opbygger dømmekraften, indflydelsen og klarheden i tænkningen til at lede godt, når ingen har et tydeligt kort.

Følg med

Du kan følge Adam Horners arbejde på LinkedIn. For 1:1-coaching, kurser i holdformat og podcasten kan du gå til The CTO Playbook. Og hvis du vil have et gratis 5-dages e-mailkursus for CTO'er i den tidlige fase, kan du gå til Early CTO Map.

Flere ekspertinterviews kommer på The CTO Club!