Ai koding: arbeidsflyter som reduserer risiko

AI kan foreslå, men repoet ditt bestemmer

Den beste måten å bruke ai til koding er å gjøre den tregere akkurat i øyeblikkene der gjetting er farlig. AI kan forklare ukjent kode, gjøre feilmeldinger om til hypoteser, utkaste tester, gjennomgå differ og foreslå refaktoreringer. Den kan også finne opp APIer, overse skjulte avhengigheter, overtilpasse seg det innlimte utdraget, eller lage en rettelse som ser ren ut mens den endrer atferd du egentlig ville beholde.

Bruk denne regelen: AI kan foreslå, men repoet ditt bestemmer. Sannheten ligger i kodebasen, den feilende reproduksjonen, testpakken, kjøretidsloggene, produktkravene og menneskelig gjennomgang. En god ai-parprogrammerer skal hjelpe deg resonnere ut fra disse artefaktene i stedet for å erstatte dem.

Regel	Hvorfor det er viktig	Hva du bør spørre modellen om
Reproduser først	Forhindrer tilfeldige rettelser	"Gjengi den feilende atferden og bevisene før du foreslår kode."
Hold omfanget lite	Reduserer risiko for regresjon	"Foreslå den minste trygge endringen og list opp berørte filer."
Bevar atferd	Beskytter brukere og kontrakter	"Navngi invariantene denne endringen ikke må bryte."
Krev tester	Gjør svaret verifiserbart	"Skriv tester som feiler før rettelsen og består etterpå."
Gjennomgå før fusjon	Fanger selvsikre feil	"Gjennomgå denne diffen for korrekthet, sikkerhet og manglende edge cases."

Dette gjelder på tvers av modeller, og modellene skiller seg genuint i kostnad og rekkevidde. På Whizis modellkostnadsindeks (OpenRouters listepriser, hentet 2026-08-20) koster et standardsvar på 1000 input pluss 500 output-tokens omtrent $0.0105 på Claude Sonnet 4.6, $0.008 på GPT-5.6 Terra og $0.00028 på DeepSeek V4 Flash, et gap på rundt 37x mellom det første og det siste, og alle tre leser en kontekst på 1M tokens. Den praktiske ruteregelen: send forklar-denne-koden og loggtriage-spørsmål til en billig modell som DeepSeek V4 Flash eller Gemini 3.7 Flash, og reserver Claude Sonnet 4.6 eller GPT-5.6 Terra til gjennomgangen og refaktoreringsplanen på kode du ikke har råd til å ødelegge. Kapabilitetsdokumenter fra OpenAI og Anthropic forteller deg hva en modell kan forsøke, de erstatter ikke arbeidsflyten over. Vurder modeller slik du ville vurdert en kollega: ber de om manglende kontekst, reduserer de usikkerhet, respekterer de begrensninger, og etterlater de et spor du kan verifisere?

Feilsøk i fem trinn: reproduser før du retter

En pålitelig ai-feilsøkingsflyt har fem trinn: reproduser, isoler, hypotese, rett, og verifiser. Ikke start med «fiks dette». Start med bevisene. Gi modellen den feilende kommandoen, nøyaktig feilmelding, forventet atferd, observert atferd, relevant kode, miljødetaljer og eventuelle nylige endringer som kan ha forårsaket problemet.

Trinn 1: fang opp reproduksjonen. For backend-kode, ta med forespørselen, svaret, statuskoden, loggene og den feilende testen. For frontend-kode, ta med ruten, brukerhandlingen, feilmeldingen i nettleserkonsollen, nettverksresponsen, komponenttilstanden og en beskrivelse av skjermbildet hvis relevant. For byggeproblemer, ta med kommandoen, pakkebehandleren, Node-versjonen og hele feilteksten rundt den første feilen.

Trinn 2: be om hypoteser før kode. En grundig modell bør rangere sannsynlige årsaker og si hvilke bevis som støtter hver av dem. Hvis den ikke klarer å skille mellom årsakene, be om det minste diagnostiske steget. Det kan være en logg, en fokusert test, en typekontroll, eller å lese én fil til.

Trinn 3: be om den minste rettelsen. Fortell modellen at den ikke skal gi nytt navn til variabler, skrive om omkringliggende kode, innføre avhengigheter, eller endre offentlig atferd med mindre den kan begrunne hvorfor. Be den returnere rotårsak, skisse til rettelse, berørte filer, tester og risiko.

Trinn 4: kjør tester lokalt. AI-output er ikke et verifiseringssteg. Verifiseringssteget er kommandoen eller brukerstien som beviser atferden. Hvis det ikke finnes noen automatisert test, be modellen først lage en regresjonstest, og deretter implementere rettelsen.

Feilsøkingsprompt:

Opptre som en grundig feilsøkingspartner. Ikke skriv kode ennå. Gjengi først reproduksjonen, forventet atferd, observert atferd, og de tre mest sannsynlige rotårsakene. Ranger hver årsak etter bevis. Foreslå deretter det minste diagnostiske steget. Feil: [beskriv]. Kommando eller brukerhandling: [lim inn]. Feil/logger: [lim inn]. Relevant kode: [lim inn]. Begrensninger: [stack, filer som ikke skal røres, atferd som skal bevares].

Rettelsesprompt:

Bruk den bekreftede rotårsaken og foreslå den minste trygge rettelsen. Returner: rotårsak, filer/funksjoner som skal endres, skisse til rettelse, tester som feiler før og består etter, edge cases, og risiko ved tilbakerulling. Ikke refaktorer urelatert kode. Kontekst: [lim inn].

AI gjennomgår differ bedre enn den skriver dem

AI er ofte bedre som gjennomgår enn som førsteforfatter. Når du ber den gjennomgå en diff, kan den se etter oversette edge cases, sikkerhetsproblemer, utdaterte antakelser, testhull og atferdsendringer. Nøkkelen er å gjøre gjennomgangen spesifikk. Hvis du spør «ser dette bra ut?», får du høflig godkjenning. Hvis du spør om korrekthetsrisiko, er det mer sannsynlig at du får nyttige innvendinger.

Gi modellen diffen, den tiltenkte atferden, relaterte tester og eventuelle begrensninger. Be den se bort fra mindre stilspørsmål med mindre de påvirker vedlikeholdbarheten. Du vil at gjennomgangen skal prioritere feil, ikke overflatiske detaljer.

Gjennomgangsområde	Spørsmål ai bør besvare
Korrekthet	Oppfyller diffen faktisk kravet?
Regresjonsrisiko	Hvilken eksisterende atferd kan endre seg utilsiktet?
Sikkerhet	Blir input, autentisering, hemmeligheter, tillatelser eller injeksjonsrisiko håndtert?
Feilhåndtering	Hva skjer ved null-verdier, tidsavbrudd, gjenforsøk, dårlige svar eller delvis tilstand?
Tester	Hvilke atferdspåstander er ikke dekket?
Vedlikeholdbarhet	Følger dette lokale mønstre og holder endringen forståelig?

Kodegjennomgangsprompt:

Gjennomgå denne diffen som en streng, men praktisk vedlikeholder. Fokuser på korrekthet, regresjonsrisiko, sikkerhet, edge cases og manglende tester. Se bort fra mindre stilspørsmål med mindre de skaper reell vedlikeholdsrisiko. Returner en tabell med problem, prioritet, bevis fra diffen, foreslått rettelse, og test som trengs. Tiltenkt atferd: [lim inn]. Diff: [lim inn]. Eksisterende tester: [lim inn].

For høyrisikoendringer, bruk en sammenlign-modellrettelser-arbeidsflyt i Whizi. Kjør samme gjennomgangsprompt på tvers av to eller tre modeller. Hvis én modell finner et mulig problem, ikke godta det blindt, sjekk om problemet faktisk er reelt i kodebasen. Poenget er å utvide gjennomgangsflaten før du fusjonerer inn, med hver innvending sporet tilbake til koden i stedet for talt som en stemme. Den bredere versjonen av den vanen, å avgjøre hvilken modell du skal sende hvilken type kode til, finner du i de beste ai-verktøyene for utviklere.

Navngi invariantene før ai rører en refaktorering

Refaktorering med ai er risikabelt fordi mange refaktoreringer bedømmes ut fra hva som ikke endres. Modellen kan gjøre koden penere mens den subtilt endrer atferd, feilhåndtering, timing eller offentlige kontrakter. En tryggere refaktoreringsflyt starter med å definere invarianter før implementasjonen røres.

Steg 1: beskriv målet med refaktoreringen. Eksempler: redusere duplisering, dele opp en stor komponent, isolere datatilgang, forenkle forgreining, migrere en API-wrapper, eller forbedre testbarheten. Angi deretter hva som må forbli det samme: offentlige funksjonssignaturer, ruteatferd, hendelsesnavn, responsformer, analyse, tillatelser, tilgjengelighetsatferd og ytelsesforventninger.

Steg 2: be om en trinnvis plan. En nyttig ai-refaktoreringsplan bør være reversibel. Hvert trinn bør berøre et lite område, inkludere tester, og gi en fungerende mellomtilstand. Unngå omskrivinger i ett steg med mindre koden er liten og godt dekket.

Steg 3: skriv karakteriseringstester. Før du endrer kode, be ai om å identifisere gjeldende atferd og utkaste tester som låser de viktige tilfellene. Disse testene er spesielt nyttige for gammel kode der hensikten er uklar. De bør inkludere normale input, grenseverdier, feilbaner og ett regresjonstilfelle knyttet til grunnen til refaktoreringen.

Steg 4: implementer ett trinn om gangen. Etter hvert trinn, kjør testene og be om en fokusert gjennomgang. Hvis modellen foreslår en bred abstraksjon, få den til å bevise at abstraksjonen fjerner reell duplisering eller risiko. Ellers, hold koden kjedelig og lokal.

Prompt for refaktoreringsplan:

Lag en trinnvis refaktoreringsplan. Mål: [mål]. Nåværende kode: [lim inn]. Begrensninger: bevar offentlig atferd, minimer endringsomfang, følg eksisterende mønstre, unngå nye avhengigheter, hold hvert trinn testbart. Returner: invarianter, avhengighetskart, trinn, berørte filer, tester per trinn, risiko ved tilbakerulling, og sjekkliste for gjennomgang.

Prompt for enhetstester:

Skriv tester før implementasjonsendringer. Bruk den eksisterende teststilen vist her: [lim inn]. Atferd som skal bevares: [lim inn]. Kode som testes: [lim inn]. Returner testnavn, oppsett, input, forventet resultat, og hvorfor hver test er viktig. Inkluder normal bane, grensetilfelle, feiltilfelle, og regresjonstilfelle.

Promptmaler som fjerner tvetydighet

Sterke kodingsprompter er akkurat lange nok til å fjerne tvetydighet, ikke mer. Modellen trenger rolle, oppgave, kontekst, begrensninger, utdataformat, og verifiseringskriterier. Ta vare på prompter som fungerer, slik at ai blir en gjentakbar ingeniørarbeidsflyt i stedet for en engangssamtale. Tabellen under kobler hver kodingsoppgave med det første du bør spørre om og sjekken som beviser svaret.

Kodingsoppgave	Hva du bør spørre om først	Hva som beviser svaret
Feilsøking	Rangerte rotårsaker med bevisene bak hver av dem	En regresjonstest som feiler før rettelsen og består etter
Kodegjennomgang	Korrekthet, regresjonsrisiko, sikkerhet, edge cases, og testhull	Hvert problem sporet til en spesifikk linje i diffen
Refaktorering	Invarianter og en trinnvis plan før noen implementasjonsendring	Karakteriseringstester består fortsatt på slutten av hvert trinn
Skrive tester	Normal bane, grense, feil, og regresjonstilfeller	Hver test knyttes til en atferdspåstand du kan navngi
Forklare kode	Formål, input, output, dataflyt, avhengigheter, og feilmodus	Fakta synlig i koden skilles fra antakelser

Prompt for kodeforklaring:

Forklar denne koden for en utvikler som blir med i prosjektet. Dekk formål, input, output, dataflyt, avhengigheter, feilmodus, og tester som ville øke tilliten. Skill fakta synlig i koden fra antakelser. Kode: [lim inn].

Prompt for sikker koding:

Gjennomgå denne koden for sikkerhetsrisiko. Fokuser på autentisering, tillatelser, injeksjon, hemmeligheter, validering, usikre omdirigeringer, filhåndtering, avhengighetsrisiko, og eksponering av sensitive data. Returner kun problemer med bevis, konsekvens, foreslått rettelse, og test eller manuell sjekk. Kode/diff: [lim inn].

Prompt for sammenlign-modellrettelser:

Jeg sammenligner ai-modeller for en kodingsoppgave. Bruk kun konteksten som er gitt. Returner rotårsak, minste trygge rettelse, tester, risikoer, antakelser, og spørsmål. Gi en tillitsgrad fra 1-5 og list opp hvilke bevis som ville endre svaret ditt. Oppgave: [lim inn]. Kontekst: [lim inn].

Kvalitetssjekkliste før du godtar ai-generert kode:

• Modellen gjengav oppgaven korrekt.
• Rettelsen er mindre enn problemet, ikke større.
• Offentlig atferd og kontrakter er navngitt.
• Tester dekker feilen eller refaktoreringsmålet direkte.
• Edge cases og feilbaner er listet opp.
• Sikkerhetssensitive input er gjennomgått.
• Diffen følger eksisterende prosjektmønstre.
• Du kjørte den relevante testen, linting, bygging, eller manuell reproduksjon.
• Et menneske gjennomgikk den endelige diffen.

En ærlig begrensning: Whizi er et samtale-arbeidsområde, ikke et IDE-tillegg. For innebygd autofullføring mens du skriver, vinner en dedikert IDE-assistent. Whizi gjør nytten sin ved kontrollpunktene i stedet: lim inn samme feilsøkings- eller gjennomgangsprompt i Claude Sonnet 4.6, GPT-5.6 Terra, og DeepSeek V4 Pro, og gi deretter poeng til svarene basert på bevis, omfang, tester, og risiko. Start med chatgpt-alternativer for koding hvis du vil ha en guide til modellvalg, sammenlign planer på priser, eller opprett en konto for å kjøre arbeidsflyten på din egen kode.