Ai för kodning: arbetsflöden som minskar risken

Ai kan föreslå, men ditt repo bestämmer

Det bästa sättet att använda ai för kodning är att göra den långsammare precis där det är farligt att gissa. Ai kan förklara okänd kod, omvandla fel till hypoteser, skriva testutkast, granska diffar och föreslå refaktoreringar. Den kan också hitta på api:er, missa dolda beroenden, överanpassa till det inklistrade utdraget eller producera en patch som ser ren ut men ändrar beteende du ville behålla.

Använd den här regeln: ai kan föreslå, men ditt repo bestämmer. Sanningen ligger i kodbasen, den fallerande reproduktionen, testsviten, körloggarna, produktkraven och mänsklig granskning. En bra ai-partner ska hjälpa dig resonera utifrån dessa underlag, inte ersätta dem.

Regel	Varför det spelar roll	Vad du ska fråga modellen
Reproducera först	Förhindrar slumpmässiga patchar	"Beskriv det fallerande beteendet och bevisen innan du föreslår kod."
Håll omfånget litet	Minskar risken för regressioner	"Föreslå den minsta säkra ändringen och lista vilka filer som berörs."
Bevara beteende	Skyddar användare och kontrakt	"Namnge invarianterna som denna ändring inte får bryta."
Kräv tester	Gör svaret verifierbart	"Skriv tester som misslyckas före fixen och lyckas efter."
Granska före merge	Fångar självsäkra misstag	"Granska den här diffen för korrekthet, säkerhet och saknade specialfall."

Det här spelar roll oavsett modell, och modellerna skiljer sig verkligen åt i kostnad och räckvidd. Enligt Whizis modellkostnadsindex (OpenRouters listpriser, hämtade 2026-08-20) kostar ett standardsvar på 1 000 indata- plus 500 utdatatoken cirka $0.0105 på Claude Sonnet 4.6, $0.008 på GPT-5.6 Terra och $0.00028 på DeepSeek V4 Flash, en skillnad på ungefär 37x mellan den första och den sista, och alla tre läser en kontext på 1M token. Den praktiska routningsregeln: skicka förklara-den-här-koden och loggtriagefrågor till en billig modell som DeepSeek V4 Flash eller Gemini 3.7 Flash, och spara Claude Sonnet 4.6 eller GPT-5.6 Terra till granskningssteget och refaktoreringsplanen för kod du inte har råd att förstöra. Kapacitetsdokument från OpenAI och Anthropic visar vad en modell kan försöka göra, de ersätter inte arbetsflödet ovan. Bedöm modeller som du skulle bedöma en kollega: frågar de efter saknad kontext, minskar de osäkerheten, respekterar de begränsningar och lämnar de ett spår du kan verifiera?

Felsök i fem steg: reproducera innan du patchar

Ett tillförlitligt ai-felsökningsflöde har fem steg: reproducera, isolera, hypotesbilda, patcha och verifiera. Börja inte med "fixa det här". Börja med bevisen. Ge modellen det fallerande kommandot, det exakta felet, förväntat beteende, observerat beteende, relevant kod, miljödetaljer och eventuella nyliga ändringar som kan ha orsakat problemet.

Steg 1: fånga reproduktionen. För backendkod, inkludera förfrågan, svaret, statuskoden, loggarna och det fallerande testet. För frontendkod, inkludera rutten, användarens handling, felmeddelandet i webbläsarkonsolen, nätverkssvaret, komponenttillståndet och en skärmdumpsbeskrivning om relevant. Vid byggfel, inkludera kommandot, pakethanteraren, Node-versionen och hela felet kring den första kraschen.

Steg 2: be om hypoteser innan kod. En noggrann modell bör rangordna troliga orsaker och säga vilka bevis som stödjer var och en. Om den inte kan skilja mellan orsakerna, be om det minsta diagnostiska steget. Det kan vara en logg, ett riktat test, en typkontroll eller att läsa ytterligare en fil.

Steg 3: begär den minsta patchen. Säg åt modellen att inte döpa om variabler, skriva om omgivande kod, införa beroenden eller ändra offentligt beteende om den inte kan motivera varför. Be den returnera grundorsak, patchöversikt, berörda filer, tester och risk.

Steg 4: kör tester lokalt. Ai-utdata är inte ett verifieringssteg. Verifieringssteget är kommandot eller användarflödet som bevisar beteendet. Om inget automatiserat test finns, be modellen skapa ett regressionstest först och sedan implementera fixen.

Felsökningsprompt:

Agera som en noggrann felsökningspartner. Skriv ingen kod ännu. Beskriv först reproduktionen, förväntat beteende, observerat beteende och de tre mest sannolika grundorsakerna. Rangordna varje orsak efter bevis. Föreslå sedan det minsta diagnostiska steget. Bugg: [beskriv]. Kommando eller användarhandling: [klistra in]. Fel/loggar: [klistra in]. Relevant kod: [klistra in]. Begränsningar: [stack, filer som inte ska röras, beteende som ska bevaras].

Fixprompt:

Utifrån den bekräftade grundorsaken, föreslå den minsta säkra fixen. Returnera: grundorsak, filer/funktioner att ändra, patchöversikt, tester som misslyckas före och lyckas efter, specialfall och rollback-risk. Refaktorera inte orelaterad kod. Kontext: [klistra in].

Ai granskar diffar bättre än den skriver dem

Ai är ofta bättre som granskare än som förstaförfattare. När du ber den granska en diff kan den leta efter missade specialfall, säkerhetsproblem, föråldrade antaganden, testluckor och beteendeändringar. Nyckeln är att göra granskningen specifik. Om du frågar "ser det här bra ut?" får du artigt godkännande. Om du frågar efter korrekthetsrisk är det mer sannolikt att du får användbara invändningar.

Ge modellen diffen, det avsedda beteendet, relaterade tester och eventuella begränsningar. Be den ignorera mindre stilfrågor om de inte påverkar underhållbarheten. Du vill att granskningen prioriterar buggar, inte skådespelsartade petitesser.

Granskningsområde	Frågor ai bör svara på
Korrekthet	Uppfyller diffen faktiskt kravet?
Regressionsrisk	Vilket befintligt beteende kan förändras av misstag?
Säkerhet	Hanteras indata, autentisering, hemligheter, behörigheter eller injektionsrisker?
Felhantering	Vad händer vid nullvärden, timeouts, återförsök, dåliga svar eller partiellt tillstånd?
Tester	Vilka beteendepåståenden täcks inte?
Underhållbarhet	Följer detta lokala mönster och håller ändringen begriplig?

Kodgranskningsprompt:

Granska den här diffen som en sträng men praktisk underhållare. Fokusera på korrekthet, regressionsrisk, säkerhet, specialfall och saknade tester. Ignorera mindre stilfrågor om de inte skapar verklig underhållsrisk. Returnera en tabell med problem, prioritet, bevis från diffen, föreslagen fix och testbehov. Avsett beteende: [klistra in]. Diff: [klistra in]. Befintliga tester: [klistra in].

För högriskändringar, använd ett jämför-modellfixar-arbetsflöde i Whizi. Kör samma granskningsprompt över två eller tre modeller. Om en modell hittar ett möjligt problem, acceptera det inte blint, kontrollera om problemet är verkligt i kodbasen. Poängen är att bredda granskningsytan innan du mergar, med varje invändning spårad tillbaka till koden snarare än räknad som en röst. Den bredare vanan, att avgöra vilken modell som ska få vilken sorts kod, finns i de bästa ai-verktygen för utvecklare.

Namnge invarianterna innan ai rör en refaktorering

Att refaktorera med ai är riskabelt eftersom många refaktoreringar bedöms utifrån vad som inte förändras. Modellen kan göra koden snyggare samtidigt som den subtilt ändrar beteende, felhantering, timing eller offentliga kontrakt. Ett säkrare refaktoreringsflöde börjar med att definiera invarianter innan implementationen rörs.

Steg 1: beskriv refaktoreringsmålet. Exempel: minska dubbelarbete, dela upp en stor komponent, isolera dataåtkomst, förenkla förgreningar, migrera en api-wrapper eller förbättra testbarheten. Ange sedan vad som måste förbli oförändrat: offentliga funktionssignaturer, ruttbeteende, händelsenamn, svarsformer, analys, behörigheter, tillgänglighetsbeteende och prestandaförväntningar.

Steg 2: be om en stegvis plan. En användbar ai-refaktoreringsplan bör vara reversibel. Varje steg bör beröra ett litet område, inkludera tester och ge ett fungerande mellantillstånd. Undvik omskrivningar i ett svep om inte koden är liten och väl täckt.

Steg 3: skriv karaktäriseringstester. Innan koden ändras, be ai identifiera nuvarande beteende och skriva testutkast som låser fast de viktiga fallen. Dessa tester är särskilt användbara för legacykod där avsikten är oklar. De bör omfatta normala indata, gränsvärden, felvägar och ett regressionsfall kopplat till anledningen till refaktoreringen.

Steg 4: implementera ett steg i taget. Efter varje steg, kör testerna och be om en riktad granskning. Om modellen föreslår en bred abstraktion, kräv att den bevisar att abstraktionen tar bort verkligt dubbelarbete eller risk. Håll annars koden tråkig och lokal.

Refaktoreringsplaneringsprompt:

Skapa en stegvis refaktoreringsplan. Mål: [mål]. Nuvarande kod: [klistra in]. Begränsningar: bevara offentligt beteende, minimera churn, följ befintliga mönster, undvik nya beroenden, håll varje steg testbart. Returnera: invarianter, beroendekarta, steg, berörda filer, tester per steg, rollback-risk och granskningschecklista.

Enhetstestprompt:

Skriv tester innan implementationsändringar. Använd den befintliga teststilen som visas här: [klistra in]. Beteende att bevara: [klistra in]. Kod som testas: [klistra in]. Returnera testnamn, förberedelse, indata, förväntat resultat och varför varje test är viktigt. Inkludera normalfall, gränsfall, felfall och regressionsfall.

Promptmallar som tar bort tvetydighet

Starka kodningsprompter är precis så långa att tvetydighet försvinner, inget mer. Modellen behöver roll, uppgift, kontext, begränsningar, utdataformat och verifieringskriterier. Spara prompterna som fungerar så att ai blir ett återanvändbart ingenjörsflöde istället för en engångskonversation. Tabellen nedan parar ihop varje kodningsuppgift med det första att fråga efter och kontrollen som bevisar svaret.

Kodningsuppgift	Vad du ska fråga efter först	Vad som bevisar svaret
Felsökning	Rangordnade grundorsaker med bevisen bakom var och en	Ett regressionstest som misslyckas före fixen och lyckas efter
Kodgranskning	Korrekthet, regressionsrisk, säkerhet, specialfall och testluckor	Varje problem spårat till en specifik rad i diffen
Refaktorering	Invarianter och en stegvis plan innan någon implementationsändring	Karaktäriseringstester lyckas fortfarande i slutet av varje steg
Skriva tester	Normalfall, gränsfall, felfall och regressionsfall	Varje test motsvarar ett beteendepåstående du kan namnge
Förklara kod	Syfte, indata, utdata, dataflöde, beroenden och felmönster	Fakta synliga i koden skiljs från antaganden

Kodförklaringsprompt:

Förklara den här koden för en utvecklare som ansluter till projektet. Täck syfte, indata, utdata, dataflöde, beroenden, felmönster och tester som skulle öka förtroendet. Skilj fakta synliga i koden från antaganden. Kod: [klistra in].

Säker kodningsprompt:

Granska den här koden för säkerhetsrisker. Fokusera på autentisering, behörigheter, injektion, hemligheter, validering, osäkra omdirigeringar, filhantering, beroenderisk och exponering av känsliga data. Returnera endast problem med bevis, konsekvens, föreslagen fix och test eller manuell kontroll. Kod/diff: [klistra in].

Jämför-modellfixar-prompt:

Jag jämför ai-modeller för en kodningsuppgift. Använd endast den angivna kontexten. Returnera grundorsak, minsta säkra fix, tester, risker, antaganden och frågor. Gradera förtroende från 1 till 5 och lista vilka bevis som skulle ändra ditt svar. Uppgift: [klistra in]. Kontext: [klistra in].

Kvalitetschecklista innan du accepterar ai-genererad kod:

• Modellen beskrev uppgiften korrekt.
• Patchen är mindre än problemet, inte större.
• Offentligt beteende och kontrakt är namngivna.
• Tester täcker buggen eller refaktoreringsmålet direkt.
• Specialfall och felvägar är listade.
• Säkerhetskänslig indata är granskad.
• Diffen följer befintliga projektmönster.
• Du körde det relevanta testet, linting, bygget eller den manuella reproduktionen.
• En människa granskade den slutliga diffen.

En ärlig begränsning: Whizi är ett chattarbetsområde, inte ett ide-tillägg. För inline-autokomplettering medan du skriver vinner en dedikerad ide-assistent. Whizi gör istället nytta vid kontrollpunkterna: klistra in samma felsöknings- eller granskningsprompt i Claude Sonnet 4.6, GPT-5.6 Terra och DeepSeek V4 Pro, och bedöm sedan resultaten efter bevis, omfång, tester och risk. Börja med chatgpt-alternativ för kodning om du vill ha en guide för modellval, jämför planer på priser, eller skapa ett konto för att köra arbetsflödet på din egen kod.