Når hastighed ikke længere giver et forspring · Del 1: Hypotesen

AI gør de gode bedre. Og de dårlige dårligere.

· Ændret · 8 min. læsning · AI · Ledelse · Softwareudvikling

Da ChatGPT blev allemandseje i slutningen af 2022, kunne den højst foreslå enkelte code snippets, men det var tydeligt, at det kun var begyndelsen, og teknologien havde et enormt potentiale. I dag arbejder agenter i hele kodebaser, mennesker uden så meget som en linje kode bag sig vibe coder sig frem til apps, og opgaver, der før bandt vores dygtigste udviklere i dagevis, løses på en eftermiddag.

Det er fristende at læse som en historie om hastighed, men det interessante er ikke nødvendigvis kun, at koden bliver skrevet hurtigere. Det er også, hvad der sker, når det, der altid har sat tempoet i softwareudvikling, pludselig ikke gør det længere.

Den tanke er ikke ny. Den er minimalt yngre end undertegnede, for allerede i 1987 skrev Fred Brooks i No Silver Bullet, at softwareudviklingens egentlige udfordring aldrig var at skrive koden, men at gennemtænke og præcisere det, koden skulle udtrykke. Koden var aldrig den sværeste del, men den var længe dyr nok til, at dyr og svær nemt kunne forveksles. Det er den forveksling, AI nu gør synlig: AI reducerer omkostningerne ved eksekvering, herunder implementering, test, deployment og drift, men den skaber ikke forståelsen af, hvad der skal bygges, og hvorfor.

AI demokratiserer eksekvering. Ikke forståelse.

Det er arbejdshypotesen i denne serie, og hvis den holder, følger en ubekvem konsekvens: Når eksekvering bliver billig, bliver forståelse, beslutninger og domænekendskab tilsvarende vigtigere - og dyrere at mangle.

Flaskehalsen flytter sig Før og nu vist som to strømme af tråde gennem kæden forståelse, beslutninger, implementering og værdi. Før: strømmen er bred hele vejen, men klemmes hårdt sammen ved implementering. Nu: strømmen er klemt allerede ved forståelse og løber bredt resten af vejen. Flaskehalsen er flyttet fra implementering til forståelse. Forståelse Beslutninger Implementering Værdi Før Forståelse Beslutninger Implementering Værdi Nu Flaskehalsen flytter sig Før og nu vist som to lodrette strømme af tråde gennem kæden forståelse, beslutninger, implementering og værdi. Før: strømmen er bred hele vejen, men klemmes hårdt sammen ved implementering. Nu: strømmen er klemt allerede ved forståelse og løber bredt resten af vejen. Flaskehalsen er flyttet fra implementering til forståelse. Før Nu Forståelse Beslutninger Implementering Værdi Forståelse Beslutninger Implementering Værdi
Figur 1 Flaskehalsen er flyttet fra implementering til forståelse.

Man kan indføre nok så mange metoder og processer. Hvis den fælles forståelse mangler, sættes der bare struktur på forvirringen. Dette blogindlæg handler om det lag, de metoder og processer hviler på.

Samme værktøj, men med det modsatte udfald

De seneste par år har AI i stadig højere grad været diskuteret som et værktøj. Debatten har primært kredset om redskabet: Hvilken model koder bedst? Hvilken agent er hurtigst? Hvad kan vi automatisere væk?

Det er alle sammen relevante spørgsmål, men de fleste overser det, der efter min opfattelse er en mere interessant observation.

Nogle udviklingsafdelinger har med AI opnået markante løft i produktiviteten. Andre oplever, at AI hjælper dem til at producere mere kode, men ikke nødvendigvis bedre software. Nogle ser højere hastighed og kvalitet i deres leverancer, mens andre ser flere fejl, større teknisk gæld og løsninger, der passer dårligere til forretningen.

Hvis AI i sig selv var løsningen, så burde forskellen mellem de grupper være betydeligt mindre. Den er større. DORA, Googles forskningsprogram der årligt undersøger hvorfor nogle softwareorganisationer leverer bedre end andre, når til samme konklusion i State of AI-assisted Software Development fra 2025: AI skaber ikke gode organisationer. Den forstærker det organisationen allerede gør - de gode bliver bedre, og de dårlige bliver dårligere. Og det gælder ikke kun implementeringen. Når prototyper, tests og eksperimenter bliver billigere, bliver det også muligt at lære hurtigere. AI accelererer derfor både eksekveringen og arbejdet med at opbygge forståelse. Hvor meget værdi det skaber, afhænger af afdelingens evne til at omsætte denne læring til bedre beslutninger og dermed bedre løsninger.

Det skyldes, at AI ikke skaber en fælles forståelse af sig selv. Den eksekverer på den forståelse, der allerede findes, og denne forståelse opstår fortsat gennem mennesker. Gennem domænekendskab, dialog med forretningen, arkitektoniske beslutninger og en fælles forståelse af det problem, der skal løses, eller den værdi, der skal skabes.

I en organisation med en stærk fælles forståelse accelererer AI derfor det rigtige: god domæneforståelse, der bliver til klare krav, der bliver til god software, hurtigere. I en organisation med en svag fælles forståelse accelererer den det forkerte: Antagelser, der aldrig blev udfordret, bliver til kode, der aldrig skulle have været skrevet. Samme værktøj. Modsatte udfald.

Samme værktøj. Modsatte udfald. Konceptfigur: Et bundt af mange tynde tråde løber ind mod en lodret stiplet markering mærket AI. Efter markeringen samles halvdelen af trådene i et ordnet, stigende bånd mærket stærk fælles forståelse, mens resten spredes nedad, falmer og trævler op, mærket svag fælles forståelse. Mellemrummet mellem de to strømme vokser mod højre og er mærket "Forskellen øges". AI Stærk fælles forståelse Svag fælles forståelse Forskellen øges
Figur 2 Samme værktøj, modsatte udfald: AI forstærker den fælles forståelse, eller manglen på samme.

AI reducerer dermed ikke forskellen mellem stærke og svage softwareorganisationer. Den øger den.

Det kan lyde som et paradoks, for på individniveau er billedet noget broget: Nogle studier finder, at AI løfter de mindst erfarne udviklere mest, og andre finder at erfarne udviklere sågar bliver langsommere, mens de samtidig selv oplever det modsatte. Men en organisation er ikke summen af individer, og derfor er det heller ikke hos den enkelte udvikler, svaret skal findes. En organisation med en svag fælles forståelse accelererer ikke kun produktion af kode, men accelererer også produktion af misforståelser, fejlbeslutninger og teknisk gæld. Derfor er "dårligere" ikke kun ment relativt. Teknisk gæld og fejlbeslutninger forrentes: En organisation der producerer dem hurtigere, står om et år med en kodebase, der er målbart sværere at ændre i, end før de fik AI i hænderne. De dårlige bliver ikke bare overhalet. De bliver dårligere.

Hvordan skaber vi en fælles forståelse, og hvordan gør vi den eksekverbar?

I dette blogindlæg er der flere gange brugt ordet forståelse. Det er bevidst. Ordet skal ikke bruges som en blød eller filosofisk størrelse, men bruges som en samlet betegnelse for den viden og de beslutninger, der gør det muligt at omsætte et behov til en løsning, der skaber værdi. Det kan f.eks. være forståelsen af forretningsregler, domænets begreber, de krav løsningen skal opfylde, hvordan de testes og de arkitektoniske beslutninger, den bygger på.

Den forståelse findes ikke ét sted. Efter min opfattelse består den af to forskellige, men tæt forbundne mentale modeller.

  • Shared Mental Model - Hvad? Hvorfor?
    Beskriver den fælles forståelse af problemet: Hvad skal bygges? Hvilken værdi skal skabes? Hvilke regler og behov skal løsningen opfylde?
  • Executable Mental Model - Hvordan?
    Beskriver hvordan den fælles forståelse omsættes til en model der kan eksekveres af enten mennesker eller agenter.

Der findes allerede udgaver af begge modeller i enhver udviklingsafdeling. Spørgsmålet er kun, hvor eksplicitte de er. Den fælles forståelse lever typisk i kravbeskrivelser, på whiteboards og i hovederne på de mest erfarne, og forsvinder med dem, når de skifter job eller pensioneres. Den eksekverbare model kender de fleste i andre mindre dele: en automatiseret test, der udtrykker en forretningsregel, er et lille stykke forståelse, som både et menneske og en agent kan eksekvere og verificere. Forestil dig så hele domænet beskrevet på denne måde.

De to mentale modeller Overskriften Den fælles forståelse spænder over to felter, der står over hinanden. Øverst Shared Mental Model med underteksten Hvad? Hvorfor? og stikordene problem, værdi samt regler og behov. Nederst Executable Mental Model med underteksten Hvordan? og stikordene eksekverbar af mennesker og eksekverbar af agenter. En pil mærket "omsættes til" peger fra det øverste felt mod det nederste, og en retur-pil mærket "læring" peger tilbage fra det nederste felt mod det øverste. Den fælles forståelse Shared Mental Model Hvad? Hvorfor? Problem · Værdi · Regler & behov omsættes til læring Executable Mental Model Hvordan? Eksekverbar af mennesker Eksekverbar af agenter
Figur 3 Den fælles forståelse omsættes til en eksekverbar model, og læringen løber tilbage igen.

Idéen om at gøre ens forståelse eksekverbar er heller ikke ny. Automatiserede tests, der beskriver forretningsregler, har eksisteret i årevis under forskellige navne. Det nye er, hvem der handler på dem. Før var modtageren enten et menneske eller en build pipeline. I dag kan modtageren også være en agent, der selv skriver koden, og den agent har kun det der står som kontekst. Det der før levede i hoveder, og blev samlet op henover frokosten, skal skrives ned, hvis agenten skal handle korrekt på det. Derfor bør der i dag stilles helt andre krav til, hvor præcis og dækkende denne model er.

Men en eksekverbar model er kun den halve løsning. Den vil aldrig blive bedre end den fælles forståelse som den bygger på. En præcis model af det forkerte problem hjælper ingen. Og pilen går begge veje: Hver gang den eksekverbare model møder virkeligheden, opstår der læring, som skal tilbage til den fælles forståelse. Tilsammen danner de to modeller rammen for at forstå, hvor arbejdet flytter hen, når det at skrive koden ikke længere er den primære begrænsning.

Hvor skabes den næste konkurrencefordel?

Efter min opfattelse er det netop i forståelsen. Forståelse for forretningen, domænet og hvor værdien skabes. Som Brooks pegede på for snart 40 år siden, har den altid været en vigtig del af udviklingen af software. Det nye er, at den ikke længere kan gemme sig bag selve eksekveringen. Så længe den var dyr, druknede forskellen mellem stærk og svag forståelse i omkostningerne. Når eksekvering er billigt, både tidsmæssigt og økonomisk, skalerer omkostningen ved misforståelser: En organisation, der eksekverer hurtigt på en forkert forståelse, bygger ikke bedre software. Den bygger det forkerte hurtigere, og betaler for det med teknisk gæld, tilbageløb på leverancerne, tabt time-to-value og forpassede muligheder.

AI kan dog sagtens være en stærk sparringspartner i arbejdet med at opbygge denne forståelse. Den kan hjælpe med at analysere information, udfordre antagelser, identificere mønstre og gøre viden mere tilgængelig. Den gør det samtidig billigere at eksperimentere og lære af resultaterne. Derfor ligger den egentlige konkurrencefordel ikke nødvendigvis i at have den bedste forståelse fra starten, men i evnen til kontinuerligt at opbygge, dele og forbedre den - hurtigere end konkurrenterne.

Det er netop derfor, de to ovenstående modeller bliver centrale. De er ikke dokumentation for dokumentationens skyld, men de er mekanismer til at opbygge og vedligeholde en fælles forståelse, som gør udviklingsteams i stand til at få markant mere værdi ud af AI.

I de kommende blogindlæg folder jeg de to modeller ud: først hvordan man kan bygge en fælles forståelse, der kan deles på tværs af fagligheder, og derefter hvordan man gør den eksekverbar for både mennesker og agenter. For flaskehalsen er flyttet, og intet tyder på, at den flytter sig tilbage.

Hvis du vil teste, hvor din egen organisation eller afdeling står, kan du starte i morgen: Tag en feature I har leveret for nylig. Spørg, hver for sig, en udvikler, en produktejer og en fra forretningen, hvilket problem den løser, og hvordan deres forståelse af den er. Får du tre svar, der ligner hinanden, står jeres fælles forståelse stærkt. Får du tre grundlæggende forskellige, har du fundet jeres reelle flaskehals. Og AI fjerner den ikke - den gør den bare dyrere.

Kilder og videre læsning

Skrevet af mig

Artiklerne her er skrevet af mig. Ikke af AI.

Jeg bruger AI som sparringspartner til at udfordre argumenterne, og til at bygge denne blog og de figurer, du ser undervejs. Holdningerne, fejlene og de endelige beslutninger er mine egne.

Læs mere om det her