Ai kodning: sådan bruger du AI uden at øge risikoen

Brug ai kodning ved at lade den arbejde ud fra beviser. Start enhver fejl med en reproduktion, bed om rangerede grundårsager før noget kode, kræv den mindste sikre rettelse og de filer den rører ved, kræv tests der fejler før rettelsen og består efter, og gennemgå diffen inden du merger.

AI kodning: Sikrere workflows i 2026 guiden

AI kan foreslå, men dit repo bestemmer

Den bedste måde at bruge ai til kodning på er at gøre den langsommere netop dér, hvor gætteri er farligt. AI kan forklare ukendt kode, gøre fejl til hypoteser, udkaste tests, gennemgå diffs og foreslå refaktoreringer. Den kan også opfinde API'er, overse skjulte afhængigheder, overtilpasse sig til det indsatte kodestykke eller lave en rettelse der ser ren ud, mens den ændrer adfærd du egentlig ville bevare.

Brug denne regel: AI kan foreslå, men dit repo bestemmer. Sandheden ligger i kodebasen, den fejlende reproduktion, testsuiten, runtime-logs, produktkrav og menneskelig gennemgang. En god AI-programmeringspartner bør hjælpe dig med at ræsonnere ud fra disse artefakter i stedet for at erstatte dem.

Regel	Hvorfor det betyder noget	Hvad du skal spørge modellen om
Reproducer først	Forhindrer tilfældige rettelser	"Gentag den fejlende adfærd og beviserne, før du foreslår kode."
Hold omfanget lille	Reducerer risikoen for regression	"Foreslå den mindste sikre ændring og list de berørte filer."
Bevar adfærd	Beskytter brugere og kontrakter	"Navngiv de invarianter denne ændring ikke må bryde."
Kræv tests	Gør svaret verificerbart	"Skriv tests der fejler før rettelsen og består efter."
Gennemgå før merge	Fanger selvsikre fejl	"Gennemgå denne diff for korrekthed, sikkerhed og manglende edge cases."

Det gælder på tværs af modeller, og modellerne adskiller sig reelt i pris og rækkevidde. På Whizis model cost index (OpenRouter-listepriser, hentet 2026-08-20) koster et standardsvar på 1.000 input plus 500 output tokens omkring $0.0105 på Claude Sonnet 4.6, $0.008 på GPT-5.6 Terra og $0.00028 på DeepSeek V4 Flash, en forskel på cirka 37x mellem den dyreste og den billigste, og alle tre læser en 1M-token kontekst. Den praktiske routingregel: send forklar-denne-kode og log-triage-spørgsmål til en billig model som DeepSeek V4 Flash eller Gemini 3.7 Flash, og gem Claude Sonnet 4.6 eller GPT-5.6 Terra til gennemgangen og refaktoreringsplanen på kode du ikke har råd til at ødelægge. Kapacitetsdokumentation fra OpenAI og Anthropic fortæller dig hvad en model kan forsøge sig med, den erstatter ikke ovenstående workflow. Bedøm modeller som du ville bedømme en kollega: beder de om manglende kontekst, reducerer de usikkerhed, respekterer de begrænsninger, og efterlader de et spor du kan verificere?

Debug i fem trin: reproducer før du retter

Et pålideligt AI debugging-workflow har fem trin: reproducer, isoler, hypotesetest, ret og verificer. Start ikke med "ret det her". Start med beviserne. Giv modellen den fejlende kommando, den præcise fejl, forventet adfærd, observeret adfærd, relevant kode, miljødetaljer og enhver nylig ændring der kan have forårsaget problemet.

Trin 1: fang reproduktionen. For backend-kode inkludér forespørgslen, svaret, statuskoden, logs og den fejlende test. For frontend-kode inkludér ruten, brugerhandlingen, browserens konsolfejl, netværkssvaret, komponenttilstanden og en skærmbilledebeskrivelse hvis relevant. For byggeproblemer inkludér kommandoen, pakkehåndteringen, Node-versionen og hele fejlen omkring det første nedbrud.

Trin 2: bed om hypoteser før kode. En omhyggelig model bør rangere sandsynlige årsager og sige hvilke beviser der understøtter hver enkelt. Hvis den ikke kan skelne mellem årsager, bed om det mindste diagnostiske trin. Det kunne være en log, en fokuseret test, et typetjek eller læsning af en fil mere.

Trin 3: bed om den mindste rettelse. Fortæl modellen at den ikke skal omdøbe variabler, omskrive omkringliggende kode, introducere afhængigheder eller ændre offentlig adfærd medmindre den kan begrunde hvorfor. Bed den om at returnere grundårsagen, en skitse af rettelsen, de berørte filer, tests og risiko.

Trin 4: kør tests lokalt. AI-output er ikke et verifikationstrin. Verifikationstrinnet er kommandoen eller brugerforløbet der beviser adfærden. Hvis der ikke findes en automatiseret test, bed modellen om først at lave en regressionstest og derefter implementere rettelsen.

Debugging-prompt:

Optræd som en omhyggelig debugging-partner. Skriv ikke kode endnu. Gentag først reproduktionen, forventet adfærd, observeret adfærd og de tre mest sandsynlige grundårsager. Ranger hver årsag efter beviser. Foreslå derefter det mindste diagnostiske trin. Fejl: [beskriv]. Kommando eller brugerhandling: [indsæt]. Fejl/logs: [indsæt]. Relevant kode: [indsæt]. Begrænsninger: [stack, filer der ikke må røres, adfærd der skal bevares].

Rettelses-prompt:

Ud fra den bekræftede grundårsag, foreslå den mindste sikre rettelse. Returner: grundårsag, filer/funktioner der skal ændres, skitse af rettelsen, tests der fejler før og består efter, edge cases og rollback-risiko. Refaktorer ikke urelateret kode. Kontekst: [indsæt].

AI gennemgår diffs bedre end den skriver dem

AI er ofte bedre som anmelder end som den første forfatter. Når du beder den om at gennemgå en diff, kan den kigge efter overset edge cases, sikkerhedsproblemer, forældede antagelser, testhuller og adfærdsændringer. Nøglen er at gøre gennemgangen specifik. Hvis du spørger "ser det her godt ud?", får du høflig godkendelse. Hvis du spørger efter korrekthedsrisiko, får du med større sandsynlighed brugbare indvendinger.

Giv modellen diffen, den tilsigtede adfærd, relaterede tests og eventuelle begrænsninger. Bed den om at ignorere mindre stilspørgsmål medmindre de påvirker vedligeholdelsen. Du vil have at gennemgangen prioriterer fejl, ikke overfladiske finpudsninger.

Gennemgangsområde	Spørgsmål AI bør besvare
Korrekthed	Opfylder diffen faktisk kravet?
Regressionsrisiko	Hvilken eksisterende adfærd kan ændres ved et uheld?
Sikkerhed	Er input, autentificering, hemmeligheder, tilladelser eller injektionsrisici håndteret?
Fejlhåndtering	Hvad sker der ved nulls, timeouts, retries, dårlige svar eller delvis tilstand?
Tests	Hvilke adfærdspåstande er ikke dækket?
Vedligeholdelse	Følger dette lokale mønstre og holder ændringen forståelig?

Kodegennemgangs-prompt:

Gennemgå denne diff som en streng, men praktisk vedligeholder. Fokusér på korrekthed, regressionsrisiko, sikkerhed, edge cases og manglende tests. Ignorer mindre stilspørgsmål medmindre de udgør en reel vedligeholdelsesrisiko. Returner en tabel med problem, prioritet, bevis fra diffen, foreslået rettelse og nødvendig test. Tilsigtet adfærd: [indsæt]. Diff: [indsæt]. Eksisterende tests: [indsæt].

Til højrisikoændringer, brug et compare-model-fixes-workflow i Whizi. Kør den samme gennemgangsprompt på tværs af to eller tre modeller. Hvis en model finder et muligt problem, accepter det ikke blindt, tjek om problemet er reelt i kodebasen. Pointen er at udvide gennemgangsfladen før du merger, hvor hver indvending spores tilbage til koden i stedet for at blive talt som en stemme. Den bredere version af denne vane, at afgøre hvilken model du sender hvilken slags kode til, findes i de bedste AI-værktøjer til udviklere.

Navngiv invarianterne før AI rører en refaktorering

Refaktorering med AI er risikabelt, fordi mange refaktoreringer bedømmes på hvad der ikke ændrer sig. Modellen kan gøre koden pænere, mens den subtilt ændrer adfærd, fejlhåndtering, timing eller offentlige kontrakter. Et sikrere refaktoreringsworkflow starter med at definere invarianter, før implementeringen røres.

Trin 1: beskriv målet med refaktoreringen. Eksempler: reducer duplikering, opdel en stor komponent, isoler dataadgang, forenkl forgrening, migrer en API-wrapper eller forbedr testbarheden. Angiv derefter hvad der skal forblive det samme: offentlige funktionssignaturer, ruteadfærd, hændelsesnavne, svarformer, analytics, tilladelser, tilgængelighedsadfærd og performanceforventninger.

Trin 2: bed om en trinvis plan. En brugbar AI-refaktoreringsplan bør kunne rulles tilbage. Hvert trin bør røre et lille område, inkludere tests og producere en fungerende mellemtilstand. Undgå et-skuds omskrivninger medmindre koden er lille og godt dækket.

Trin 3: skriv karakteriseringstests. Før du ændrer kode, bed AI om at identificere den nuværende adfærd og udkaste tests der låser de vigtige tilfælde fast. Disse tests er særligt nyttige for legacy-kode, hvor hensigten er uklar. De bør inkludere normale input, grænseinput, fejlveje og et regressionstilfælde knyttet til grunden til refaktoreringen.

Trin 4: implementer et trin ad gangen. Efter hvert trin, kør testene og bed om en fokuseret gennemgang. Hvis modellen foreslår en bred abstraktion, få den til at bevise at abstraktionen fjerner reel duplikering eller risiko. Ellers hold koden kedelig og lokal.

Refaktoreringsplan-prompt:

Lav en trinvis refaktoreringsplan. Mål: [mål]. Nuværende kode: [indsæt]. Begrænsninger: bevar offentlig adfærd, minimér forstyrrelser, følg eksisterende mønstre, undgå nye afhængigheder, hold hvert trin testbart. Returner: invarianter, afhængighedskort, trin, berørte filer, tests per trin, rollback-risiko og gennemgangstjekliste.

Unit test-prompt:

Skriv tests før implementeringsændringer. Brug den eksisterende teststil vist her: [indsæt]. Adfærd der skal bevares: [indsæt]. Kode under test: [indsæt]. Returner testnavne, opsætning, input, forventet resultat og hvorfor hver test betyder noget. Inkludér normal vej, grænsetilfælde, fejltilfælde og regressionstilfælde.

Promptskabeloner der fjerner tvetydighed

Stærke kodningsprompts er præcis lange nok til at fjerne tvetydighed, ikke mere. Modellen har brug for rolle, opgave, kontekst, begrænsninger, outputformat og verifikationskriterier. Gem de prompts der virker, så AI bliver et gentageligt teknisk workflow i stedet for en enkeltstående samtale. Tabellen nedenfor parrer hver kodningsopgave med det første du skal bede om, og tjekket der beviser svaret.

Kodningsopgave	Hvad du skal bede om først	Hvad der beviser svaret
Debugging	Rangerede grundårsager med beviserne bag hver	En regressionstest der fejler før rettelsen og består efter
Kodegennemgang	Korrekthed, regressionsrisiko, sikkerhed, edge cases og testhuller	Hvert problem sporet til en specifik linje i diffen
Refaktorering	Invarianter og en trinvis plan før nogen implementeringsændring	Karakteriseringstests består stadig ved slutningen af hvert trin
Skrive tests	Normal vej, grænsetilfælde, fejl- og regressionstilfælde	Hver test svarer til en adfærdspåstand du kan navngive
Forklare kode	Formål, input, output, dataflow, afhængigheder og fejltilstande	Fakta synlige i koden adskilt fra antagelser

Kodeforklarings-prompt:

Forklar denne kode for en udvikler der kommer ind i projektet. Dæk formål, input, output, dataflow, afhængigheder, fejltilstande og tests der ville øge tilliden. Adskil fakta synlige i koden fra antagelser. Kode: [indsæt].

Sikker kodning-prompt:

Gennemgå denne kode for sikkerhedsrisici. Fokusér på autentificering, tilladelser, injektion, hemmeligheder, validering, usikre omdirigeringer, filhåndtering, afhængighedsrisiko og eksponering af følsomme data. Returner kun problemer med bevis, konsekvens, foreslået rettelse og test eller manuelt tjek. Kode/diff: [indsæt].

Compare-model-fixes-prompt:

Jeg sammenligner AI-modeller til en kodningsopgave. Brug kun den givne kontekst. Returner grundårsag, mindste sikre rettelse, tests, risici, antagelser og spørgsmål. Vurder tillid fra 1-5 og list hvilke beviser der ville ændre dit svar. Opgave: [indsæt]. Kontekst: [indsæt].

QA-tjekliste før du accepterer AI-genereret kode:

Modellen gengav opgaven korrekt.
Rettelsen er mindre end problemet, ikke større.
Offentlig adfærd og kontrakter er navngivet.
Tests dækker direkte fejlen eller refaktoreringsmålet.
Edge cases og fejlveje er listet.
Sikkerhedsfølsomme input er gennemgået.
Diffen følger eksisterende projektmønstre.
Du har kørt den relevante test, lint, build eller manuelle reproduktion.
Et menneske har gennemgået den endelige diff.

En ærlig begrænsning: Whizi er et chatworkspace, ikke et IDE-plugin. Til inline autocomplete mens du skriver, vinder en dedikeret IDE-assistent. Whizi indtjener sin plads ved kontrolpunkterne i stedet: indsæt den samme debugging- eller gennemgangsprompt i Claude Sonnet 4.6, GPT-5.6 Terra og DeepSeek V4 Pro, og bedøm derefter outputtene efter beviser, omfang, tests og risiko. Start med ChatGPT-alternativer til kodning hvis du vil have en guide til modelvalg, sammenlign planer på pricing, eller opret en konto for at køre workflowet på din egen kode.

Tjekliste

Start med en reel reproduktion, ikke en vag fejlbeskrivelse.
Bed om hypoteser og beviser før du beder om kode.
Bed om den mindste sikre rettelse og navngiv de berørte filer.
Definér adfærd der ikke må ændres, før du refaktorerer.
Skriv eller opdater tests før du stoler på rettelsen.
Gennemgå AI-genererede diffs for korrekthed, sikkerhed og edge cases.
Kør den samme risikable prompt på tværs af modeller og sammenlign rettelserne i Whizi.
Brug menneskelig gennemgang før du merger AI-assisteret kode.

Ofte stillede spørgsmål

Hvordan bruger jeg AI til kodning sikkert?

Brug AI som en programmeringspartner der foreslår muligheder, tests og gennemgange. Start med en reproduktion, kræv en lille rettelse, kør tests og gennemgå diffen inden du merger. Betragt ikke genereret kode som automatisk korrekt.

Kan AI hjælpe med at debugge kode?

Ja. AI er nyttig til at omdanne fejl, logs og kode til sandsynlige grundårsager. Den sikreste debugging-metode er at bede om hypoteser først, derefter et diagnostisk trin, og til sidst den mindste rettelse og regressionstests.

Kan AI skrive unit tests?

AI kan udkaste unit tests, men du bør kræve klar dækning af adfærd. Bed om normal vej, grænsetilfælde, fejl- og regressionstilfælde, og tjek derefter at testene ville fejle før rettelsen og bestå efter.

Hvad er den bedste AI-model til kodning?

Fordel efter risiko. En billig model som DeepSeek V4 Flash klarer kodeforklaring og log-triage til omkring 37x lavere pris per svar end Claude Sonnet 4.6 på listepriser, så gem Claude Sonnet 4.6 eller GPT-5.6 Terra til gennemgange og refaktoreringsplaner på kode der betyder noget. Bevis valget ved at køre den samme prompt på tværs af modeller og beholde svaret med de klareste beviser og de stærkeste tests.