AI-understøttet udvikling uden at gå på kompromis med kvaliteten

AI-værktøjer som Claude Code, Cursor og Copilot har ændret, hvor hurtigt man kan komme fra idé til fungerende kode. En agent kan læse et repository, foreslå en løsning, skrive koden og køre testene på få minutter. "Vibe coding", hvor man beskriver, hvad man vil have, og lader værktøjet skrive det meste, er blevet en reel arbejdsform.

Hastigheden er ikke problemet. Problemet er, at kode, der ser rigtig ud, ikke nødvendigvis er rigtig, og at den kommer hurtigere, end man når at forstå den. Dette indlæg handler om, hvordan man får gevinsten uden at betale med kvalitet, sikkerhed og vedligeholdbarhed. Erfaringerne kommer fra rigtige projekter.

Hvad kodeagenten er god til

• Rutinearbejde med klare rammer: boilerplate, mapping mellem formater, testdata, migreringer af kode fra én API-version til en anden.
• At komme i gang: et første udkast til en komponent, et script eller en test, som man derefter retter til.
• At læse og forklare kode: "hvor bliver denne værdi sat?" i en ukendt kodebase.
• Mekaniske ændringer på tværs af mange filer, når mønsteret er entydigt og testene dækker.

Hvor kodeagenten fejler

• Domæneviden og implicitte krav. Værktøjet kender ikke de forretningsregler, der kun står i hovedet på folk eller i en mail fra sidste år.
• Plausible, men forkerte detaljer: en parameter, der ikke findes i netop den version af et bibliotek, eller en fejlhåndtering, der ser ordentlig ud, men sluger fejlen.
• Sikkerhed: input, der ikke valideres, hemmeligheder, der havner i kode eller logs, og afhængigheder, der tilføjes uden at nogen har set på dem.
• Arkitektur over tid: hver ændring kan være fornuftig for sig, mens helheden glider. Det mærkes først, når systemet skal ændres igen.

Hvor vi mennesker fejler

Kodeagenten er ikke det eneste led, der kan fejle. Jo bedre værktøjet bliver, jo lettere bliver det for os at slappe af:

• Tilliden vokser hurtigere end grundlaget for den. Efter en lang række gode forslag læser man det næste mindre grundigt. Det er netop dér, fejlen sniger sig ind.
• Gennemgang bliver til skimning. Diffen ser pæn ud, forklaringen lyder overbevisende, og man godkender uden at have forstået, hvad koden gør.
• Grønne tests som sovepude. Testene består, men har agenten skrevet både testen og koden, og har ingen læst testen, beviser den kun, at koden gør det, agenten troede, den skulle.
• Ansvaret glider. "Det var agenten, der skrev det" bliver en stille undskyldning for ikke selv at have tjekket det.

Ansvaret kan ikke uddelegeres til et værktøj. Når der opstår et datalæk, eller en fejl rammer kunderne, er det ikke kodeagenten, der skal stå til regnskab over for kunden, ledelsen eller Datatilsynet. Det er virksomheden og de mennesker, der godkendte og udgav koden. Derfor fortjener agentens arbejde den samme kritiske gennemgang som alt andet, også og især når det plejer at gå godt.

Værn om kvaliteten

Det, der virker, er ikke at bruge værktøjerne mindre, men at give dem faste rammer. Fire rammer gør den største forskel.

1. Tests først. Når testen er skrevet, før koden findes, har man en præcis beskrivelse af, hvad der skal ske, og et objektivt mål for, om det skete. Det gælder dobbelt for genereret kode. Lad agenten skrive testen, læs den grundigt, se den fejle af den rigtige grund, og lad først derefter agenten skrive koden. En test, man ikke har set fejle, beviser ingenting.

2. Små ændringer. En ændring på en håndfuld kodelinjer kan man følge linje for linje. En ændring, der fylder skærm efter skærm, bliver godkendt, fordi den ser rimelig ud. Bed om ét skridt ad gangen, og commit hvert skridt for sig, så historikken viser, hvad der skete, og så et dårligt skridt kan rulles tilbage alene.

3. Et menneske gennemgår koden. Agentens arbejde gennemgås som enhver anden pull request, med samme krav. Det er ikke mistillid; det er den samme proces, som gør menneskeskrevet kode bedre. Spørg især: forstår jeg, hvorfor koden ser sådan ud? Hvis svaret er nej, er den ikke færdig. Det er den, der godkender, ikke agenten, der står til ansvar for koden.

4. Klare instruktioner til agenten. De fleste værktøjer læser en fil med projektregler, f.eks. CLAUDE.md for Claude Code. Den er stedet til det, man ellers ville sige igen og igen: hvordan projektet er bygget op, hvilke kommandoer der kører testene, hvilke biblioteker der er valgt, og hvad agenten aldrig må gøre. Et uddrag kunne se sådan ud:

• kør npm run test:unit før hver commit, og vis testen fejle, før koden skrives;
• unit-tests må ikke kræve en database eller netværk; brug stubs;
• tilføj ikke nye afhængigheder uden at spørge;
• skemaændringer kun som tilføjelser; omdøbninger kræver en migration;
• hemmeligheder kommer fra miljøvariabler og må aldrig stå i koden;
• opdatér systemdokumentationen (arkitektur, systemdesign og API-dokumentation) i samme commit som den kode, der ændrer den.

Reglerne er ikke en garanti, men de flytter standarden fra "hvad agenten gætter på" til "hvad teamet har besluttet".

Sikkerhed

Tre områder kræver særlig opmærksomhed, når en agent skriver og kører kode:

• Hemmeligheder. Lad aldrig agenten se produktionsnøgler. Brug miljøvariabler, en .env.example uden rigtige værdier, og tokens med så få rettigheder og så kort levetid som muligt. Tjek ændringer for nøgler, før de committes; det kan automatiseres.
• Afhængigheder. En agent løser gerne et problem ved at installere en pakke. Hver ny afhængighed er kode fra en fremmed, som kører i dit system. Kræv, at nye pakker godkendes, lås versionerne, og kør en sårbarhedsscanning som en del af bygget.
• Isolering. Agenten kører kommandoer. Kører den direkte på udviklerens maskine, har den adgang til alt, udvikleren har adgang til. En Dev Container begrænser, hvad den kan nå. Vi har beskrevet opsætningen og dens begrænsninger i Isolér din AI-kodeagent.

Hvor står mennesket så?

Værktøjerne flytter arbejdet, de fjerner det ikke. Mindre tid går med at skrive kode, mere tid går med at formulere, hvad der skal bygges, at gennemgå forslag og at holde arkitekturen samlet. Det er ikke mindre krævende; det er en anden slags krævende. Erfarne udviklere får mest ud af værktøjerne, netop fordi de hurtigt kan se, når et forslag er forkert. Og ansvaret flytter ikke med over i værktøjet: det ligger stadig hos dem, der godkender og udgiver koden. Det gælder også vedligeholdelsen: kode, som ingen på teamet forstår, bliver dyr at ændre, uanset hvor hurtigt den blev skrevet.

For et team, der vil i gang, er et godt første skridt at vælge et afgrænset område med god testdækning, skrive projektreglerne ned og måle på de samme ting som før: fejl i produktion, tid fra idé til udgivelse og hvor let koden er at ændre bagefter. Bliver de tal bedre, er værktøjerne en gevinst. Bliver de dårligere, er det rammerne, der skal strammes, ikke farten, der skal sættes op.