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

Da ChatGPT blev allemandseje i sidste halvdel af 2022, blev det tydeligt, at softwareudvikling stod over for et markant skifte. Opgaver, der før bandt vores dygtigste udviklere i dagevis, kunne pludselig løses på en eftermiddag. For første gang begyndte selve implementeringen at holde op med at være softwareudviklingens dominerende omkostning.

Det afgørende er ikke, at koden bliver skrevet hurtigere. Det er, hvad der sker, når det, der historisk var det dyreste led i softwareudvikling, pludselig ikke længere er det. Når næsten alle kan bygge software hurtigere end nogensinde, flytter værdien sig uundgåeligt.

Det rejser et interessant spørgsmål: Hvor skabes værdien, når implementeringen ikke længere er den primære begrænsning? Min arbejdshypotese er enkel: AI ændrer ikke fundamentalt på, hvad softwareudvikling er. Allerede i 80'erne blev det formuleret, at softwareudviklingens egentlige problem ikke ligger i at skrive selve koden, men i at gennemtænke og præcisere det, som koden skal udtrykke. AI ændrer ikke på det. Den ændrer omkostningerne ved eksekvering: kodning, test, deployment og drift. Og når eksekvering bliver billigere, bliver forståelse, beslutninger og kendskab til domænet tilsvarende vigtigere og dyrere at mangle.

Man kan indføre nok så mange metoder og processer. Hvis den fælles forståelse mangler, sættes der bare struktur på forvirringen. Denne artikel 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 den mest interessante 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, og forklaringen er enkel: AI forstærker det et udviklingsteam allerede gør. 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 bedre software.

Det skyldes, at AI ikke skaber 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, før nogen når at stille spørgsmålet. Samme værktøj. Modsatte udfald.

Hvis dette holder, så følger der en interessant konsekvens. AI reducerer ikke forskellen mellem stærke og svage softwareorganisationer. Den øger den.

Det kan lyde som et paradoks, for på individniveau peger flere undersøgelser på, at AI ofte løfter de mindst erfarne udviklere mest, men en organisation er ikke summen af individer. En organisation med en svag fælles forståelse accelererer ikke kun produktion af kode - den accelererer også produktion af misforståelser, fejlbeslutninger og teknisk gæld. Det handler om, at når støvet lægger sig i driften, skalerer AI din forretningsforståelse. Eller manglen på samme.

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

I denne artikel 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 og hvordan de testes eller 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.

Begge modeller findes allerede 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.

Disse to modeller danner tilsammen rammen for at forstå, hvordan AI ændrer softwareudvikling, når implementeringen ikke længere er den primære begrænsning.

Hvor skabes den næste konkurrencefordel?

Efter min opfattelse er svaret forståelse. Forståelse for forretningen, domænet og hvor værdien skabes. Det er ikke ny indsigt. Forståelse har altid været kernen i softwareudvikling. Det nye er, at den ikke længere kan gemme sig bag selve implementeringen. Så længe eksekvering var dyr, druknede forskellen mellem stærk og svag forståelse i omkostningerne forbundet med eksekveringen. Den undskyldning er væk nu. Når eksekvering er billig, 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 og tabt time-to-market.

AI kan 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 i at have den bedste forståelse fra starten, men i evnen til kontinuerligt at opbygge, dele og forbedre den - hurtigere end andre.

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 artikler folder jeg de to modeller ud: først hvordan man bygger 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 den flytter sig ikke tilbage.