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.
I den del af min omgangskreds, der beskæftiger sig med softwareudvikling, har en stor andel det lykketræf at deres hobby er deres arbejde og omvendt. De har i mange år lavet software i deres fritid, og nu kan man endda få løn for det. I det seneste år har en mulig skæbne dog åbenbaret sig i form af AI. Yngre softwareudviklere med en tendens til teknologioptimisme mister måske ikke deres job, men står overfor ikke længere at kunne bruge store dele af deres tid på selv at skrive kode, men i stedet skulle anvende AI-værktøjer til generering af kode, og i stedet bruge deres arbejdstid på at reviewe den genererede kode og forbedre værktøjerne til generering af kode. For mange udviklere, der har specialiseret sig i rå programmering, lyder det lidt for meget af management, og det giver noget besvær.
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.