Kode Debugging & Fejlfinding

Kode debugging med sprogmodeller dækker den situation, hvor koden allerede findes, men ikke opfører sig som forventet. Du beskriver symptomet, viser den relevante kode og beder modellen om at finde årsagen. Output er en hypotese om fejlen, en forklaring og typisk et forslag til rettelse.

Grænsen mod kodegenerering går ved udgangspunktet. Genererer du ny funktionalitet fra en specifikation, er det en anden use-case, selv om modellen og prompt-teknikken ligner hinanden. Debugging starter altid fra en observeret afvigelse mellem forventet og faktisk adfærd.

Grænsen mod code review går ved formålet. Review handler om kvalitet, stil og potentielle problemer i kode, der virker. Debugging handler om en konkret fejl, der allerede er indtruffet, og som du kan reproducere eller i det mindste beskrive.

Grundmekanikken er enkel. Du samler et fejlbillede bestående af error message, stack trace, det kodeuddrag traceen peger på, og en beskrivelse af hvad koden skulle gøre. Modellen matcher dette mod mønstre fra træningsdata og foreslår sandsynlige årsager.

Kvaliteten afgøres næsten udelukkende af, hvor meget relevant kontekst der er i dit context window. En stack trace uden den omkringliggende kode giver generiske svar. Den samme trace sammen med funktionen, dens kaldere og de datastrukturer den arbejder på, giver ofte en præcis diagnose.

I agentiske opsætninger udvides mekanikken. Modellen får værktøjsadgang til at læse filer, køre tests og se output, og kan dermed selv indsamle kontekst i flere runder. Det flytter arbejdet fra at gætte til at observere, men kræver at testene faktisk fanger fejlen.

RAG over kodebasen bruges når projektet er for stort til context window. Relevante filer hentes ud fra fejlbeskrivelsen og lægges i prompten. Præcisionen af den søgning bliver da en flaskehals for hele debuggingen.

Den hyppigste fejltype er det plausible forkerte svar. Modellen producerer en velformuleret forklaring med kodeeksempel, som ser rigtig ud og er forkert. Uden en test der fejler før og består efter, har du ingen måde at skelne på.

En beslægtet risiko er symptombehandling. Modellen ser kun det udsnit du viser, og foreslår derfor gerne et null-check eller et try-except, der skjuler fejlen frem for at fjerne årsagen. Det virker i øjeblikket og skaber en sværere fejl senere.

Modeller er også tilbøjelige til at give dig ret. Skriver du "jeg tror problemet er i cachen", vil svaret ofte tage det for givet. Formulér symptomet neutralt og lad modellen foreslå flere konkurrerende årsager, før du peger på en.

Endelig findes der fejlklasser, hvor tilgangen har lav værdi. Race conditions, memory corruption, fejl i tredjepartsbiblioteker og problemer der kun opstår under produktionslast kan ikke diagnosticeres ud fra kildekode alene. Her er profilering, logging og en debugger stadig det primære værktøj.

Til reel fejlsøgning i flere filer er en model med stærk reasoning og stort context window afgørende. GPT-5.6 Sol og Claude Sonnet 5 kan begge holde en større del af kaldekæden i hovedet på én gang og forfølge en hypotese gennem flere trin.

GPT-5 nano hører til de rutineopgaver, hvor svaret er kendt på forhånd: forklaring af en standard error message, en syntaksfejl eller en type-mismatch. Latenstiden er lav nok til, at den kan sidde direkte i editoren.

En praktisk arbejdsdeling er at lade den lille model tage første kig og eskalere til den store, når fejlen ikke er lokal. Det holder omkostningen nede uden at koste præcision på de svære sager.