Review af AI-kollegaens kode (juli 2026)
NB: Emne i hastig udvikling. Hvis kalenderen siger 2027 eller senere, så er nedenstående helt sikkert håbløst uddateret.
Med det seneste års udvikling inden for AI, ser det ud til at den rå programmeringsdel af softwareudvikling bliver formindsket og tiden skal bruges på at generere kode med AI og at reviewe den genererede kode. For de fleste udviklere er det i forvejen en stor del af arbejdet at reviewe andre, typisk mindre erfarne, udvikleres kode, men der er nogle egenskaber ved de nuværende AI-værktøjer, der gør det besværligt og mindre effektivt at reviewe AI-genereret kode end menneskeskabt kode.
En af besværlighederne kommer af at der er forskel på hvordan AI-værktøjer og mennesker responderer på reviews. Ved review af menneskeskabt kode er der et læringsmæssigt element: Man regner med at ens kommentarer giver modtageren stof til eftertanke, og at de over tid ændrer deres arbejdsmåde, så der ikke er anledning til de samme kommentarer senere. AI-værktøjer bliver ikke automatisk bedre af kommentarer — kommentarerne skal eksplicit laves som ændringer til tests og verifikation, i hvert fald i nuværende udgave af værktøjerne.
Et andet besvær kommer af at AI-værktøjer excellerer i at få deres output til at virke så øjensynligt korrekt som muligt. Enhver der har læst en tekst, der er hastigt skabt ved brug af AI har set det: Teksten ser umiddelbart flot ud, men er kønsløs og kan have store logiske huller, der er skjult af lange bindestreger og vage formuleringer. Det samme gør sig gældende for kode, der er flot kommenteret og ser gennemarbejdet ud, men har forståelsesmæssige huller, man kan se, hvis man kigger godt efter.
En del af hullerne skal nok forsvinde med bedre AI-modeller. Allerede over det seneste år er det gået hurtigt fremad, men bliver det hele løst af modellerne? Problemet for mig er samarbejdsformen. Hvis jeg reviewer menneskeskabt kode, regner jeg med at der er en sammenhæng med hvor gennemarbejdet koden ser ud og hvor gennemarbejdet, den faktisk er. Med AI er den sammenhæng ofte ikke til stede, og så er det pludselig nødvendigt at gå til review fra en fjendtlig position, hvor man må mistænke hver eneste linje kode for at bære på grundlæggende misforståelser.
Hvis man er rigidt rationel, vil man måske argumentere for at det er fornuftigt at have den form for absolutte tilgang til review, men jeg finder det udmattende og unødvendigt. Hvad er det ved LLM’erne, der gør at de virker så skråsikre? Kan man gøre noge for at give mere sammenhæng mellem hvor gennemarbejdet outputtet ser ud og hvor gennemarbejdet det faktisk er?
Jeg må indrømme at jeg ved for lidt om LLM’er og de moderne værktøjer til at kunne svare på de spørgsmål, men jeg er reelt interesseret i at løse de her samarbejdsproblemer, for jeg tror at det er mere realistisk end at se sig sur på maskinen, og håbe at den går væk. Udviklingen er gået hurtigt over det seneste halvandet år, og der har været store forbedringer til værktøjerne. Mon ikke at vi ser nogle nødvendige forbedringer i værktøjerne, når der ikke længere er store landvindinger at få i modellerne selv? Gad vide om vi kommer til at lave kommentarer som var de til mennesker, som et LLM-værktøj vil omforme til eksplicitte regler, maskinen selv kan bruge til at sørge for, at der ikke bliver grund til kommentarer senere.
Tak til Pyjam.as-campen på BornHack for interessante og åbne samtaler om AI og indvirkningen på softwareudvikling. Deruover var Chris Krychos tekst om ændringer i tillid ved opskalering af teams en gnist til at skrive om dette emne.