Kodegenerering & Debugging

Kodegenerering og debugging dækker de opgaver hvor en sprogmodel skriver ny kode, ændrer eksisterende kode eller hjælper dig med at finde årsagen til en fejl. Det spænder fra en enkelt funktion i et chatvindue til en editor der foreslår ændringer på tværs af flere filer i et repository.

Grænsen mod nabo-use-cases går ved hvad modellen faktisk leverer. Er resultatet en forklaring af et koncept eller en gennemgang af et framework, er det læring og teknisk dokumentation. Kører modellen selv kommandoer, opretter branches og åbner pull requests uden at du godkender hvert skridt, er du i gang med agentiske workflows, som stiller andre krav til rettigheder, logning og rollback.

Også afgrænsningen nedad er værd at holde fast i. Autocompletion af en linje ad gangen og generering af en hel feature bruger samme teknologi, men adskiller sig markant i hvor meget kontekst der skal samles, og hvor dyrt et review bliver.

Mekanikken har tre led: kontekst, generation og verifikation. Konteksten samles fra åbne filer, imports, typedefinitioner, fejlbeskeder og stack traces. Værktøjer som Cursor bygger desuden et søgeindeks over repositoriet og henter relevante filer ind, altså RAG anvendt på en kodebase.

Derefter genererer modellen et forslag. Kvaliteten afhænger mindre af hvor meget kontekst du propper ind, og mere af hvor præcist det udvalgte materiale matcher opgaven. En model der får den faktiske interface-definition og to eksempler på husets konventioner, rammer bedre end en model der får hele mappen.

Sidste led er verifikation. Compiler, typechecker, linter og testsuite giver et signal som kan sendes tilbage til modellen, og netop den feedback-løkke afgør om resultatet konvergerer eller driver af. Claude Opus 5 og GPT-5.6 Sol bruges typisk til større refaktoreringer med mange filer, Claude Sonnet 5 til hurtige iterationer hvor svartid betyder noget, og Gemini 3.1 Pro hvor et stort context window skal rumme meget kode på én gang.

Hallucinerede API-kald opstår fordi modellen producerer det mest sandsynlige næste token, ikke det verificerbart eksisterende. Træningsdata blander flere versioner af samme bibliotek, og resultatet bliver et kald der ser idiomatisk ud. Nogle gange fejler det ved compile. Værre er de tilfælde hvor det oversættes til noget der kører, men gør noget andet end du tror.

Genereret kode er sværere at reviewe end kode du selv har skrevet. Du læser bekræftende i stedet for undersøgende, og review-tempoet følger ikke generationstempoet. Efter tredje store diff på en time falder opmærksomheden, og det er dér fejlene slipper igennem.

Ved debugging er begrænsningen mere grundlæggende. Modellen kan ikke observere runtime. Den ser den tekst du giver den, og gætter kvalificeret ud fra mønstre. Uden logs, faktiske værdier og en reproducerbar case retter den ofte symptomet i din stack trace frem for årsagen længere oppe.

Sikkerhedsproblemer følger samme logik. Modellen reproducerer udbredte mønstre, og udbredt er ikke det samme som forsvarligt. Strengsammensat SQL, manglende inputvalidering og for brede rettigheder dukker op, fordi der findes rigeligt af den slags kode i verden.

Udbyttet er højest når korrekthed kan verificeres billigt. Rene funktioner, datatransformationer, testopsætning og migrationsscripts har alle den egenskab, at du kan køre resultatet og se om det holder.

Udbyttet er lavest når kravene er implicitte. Domænelogik der bygger på beslutninger truffet i et møde for to år siden, findes ikke i koden og dermed heller ikke i modellens kontekst. Her bruger du mere tid på at forklare end på at skrive.

Ansvaret flytter sig ikke. Det er dit navn på committen, og det er dig der skal fejlsøge produktion klokken tre om natten. Små diffs, tydelige commit-beskeder og en testsuite du stoler på, er det der gør forskellen mellem hastighed og teknisk gæld.