Att använda AI för att programmera utan buggig kod

Du öppnar ett ärende, klistrar in beskrivningen i ett chattfönster och får tillbaka 200 rader kod som ser rimliga ut. Det kompilerar. Två dagar senare frågar en granskare varför koden ignorerar din retry-wrapper, och ingen i teamet kan förklara varför. Det är det vanliga misslyckandet när man lär sig att använda AI för att programmera. Genereringen går bra, men allt runt omkring gör det inte.

Här är arbetsflödet jag ger nya ingenjörer. Det behandlar modellen som en snabb och självsäker juniorutvecklare som aldrig har sett ert repo. Det bygger på granskningstid, inte skrivtid.

Gör AI dig faster på riktigt?

Ibland, och svaret beror på uppgiften. Stack Overflow Developer Survey 2025 visar att 84% av de svarande använder eller planerar att använda AI-verktyg, men bara 33% litar på resultatet i någon utsträckning. Den vanligaste klagomålet, med 66%, är kod som är ”nästan rätt, men inte riktigt”. Ytterligare 45.2% säger att felsökning av AI-genererad kod tar längre tid än väntat.

Mätningarna är mindre smickrande. I en studie från 2025 av METR fick 16 erfarna open source-utvecklare arbeta igenom 246 verkliga ärenden i repon de kände väl. Med AI tillåtet blev de cirka 19% långsammare, men de trodde själva att de varit cirka 20% snabbare. METR har sedan dess publicerat nyare data, så betrakta siffran som en ögonblicksbild av verktygen från början av 2025, inte som en dom.

Slutsatsen är inte att AI är långsamt. Det är att känslan av hastighet är ett dåligt mätinstrument. Mät i minuter från ärende till sammanfogad PR, inte i hur snabbt första utkastet dök upp. Det är den mätningen som säger något om din vardag.

Vad bör du skriva ner innan du ställer en fråga till AI?

En plan, med egna ord, på under tio rader. Hoppar du över det fyller modellen i luckorna med egna gissningar, och de är generiska per definition.

Min mall är kort:

1. Beteendeförändringen, i en mening.

2. Filerna du väntar dig att ändra, även om du är osäker.

3. Den befintliga funktionen eller mönstret som den nya koden måste återanvända.

4. En sak den inte får göra, till exempel inget nytt beroende eller ingen schemaändring.

5. Hur du vet att det fungerar: ett test, ett curl-anrop eller en skärmbild.

Punkt 3 är den som folk hoppar över, och det är där det mesta av den ”nästan rätta” koden kommer ifrån. Modellen vet inte att din hjälpfunktion withRetry finns om du inte nämner den eller om den kan läsa den. Det här gäller även erfarna utvecklare, eftersom ingen kan hålla hela kodbasen i huvudet samtidigt.

Hoppa över prompten ”bygg hela appen åt mig”. Både nybörjare och seniora utvecklare får samma resultat av den: en stor diff som ingen förstår och ett projekt som aldrig blir klart. Ju mindre och tydligare uppgiften är, desto lättare är det att bedöma svaret.

Hur ser en bra prompt ut i praktiken?

Ta ett verkligt jobb: webhook-avsändaren tappar händelser när mottagaren timeoutar. En svag prompt lyder ”fixa webhook-tillförlitligheten”. En användbar prompt ser ut som ett ärende.

Lägg till retry med exponentiell backoff i sendWebhook() i src/webhooks/sender.ts.
Återanvänd withRetry() från lib/http.ts. Max 4 försök, med jitter på.
Ändra inte den publika signaturen och lägg inte till beroenden.
Lägg till ett vitest-fall för en mottagare som misslyckas två gånger och sedan lyckas.

Prompten anger filen, hjälpfunktionen som ska återanvändas, en gräns och en kontroll. Resultatet blir en diff på kanske 30 rader som du kan läsa på en gång. Om diffen kommer tillbaka på 150 rader har modellen spårat ur, och då förkastar du resultatet i stället för att redigera det. Det sparar tid, eftersom en omskriven halvfärdig diff är svårare att granska än en ny körning med tydligare instruktioner.

Två små knep hjälper. Be om en plan först och läs den innan någon fil ändras: en felaktig plan kostar trettio sekunder, en felaktig diff kostar tio minuter. Och när ett svar är fel, upprepa bivillkoret som bröts i stället för att argumentera. ”Du lade till ett nytt beroende, regeln är inga” fungerar bättre än ett helt stycke förklaring.

Vilken typ av AI-verktyg passar vilket jobb?

Det finns tre former, och att blanda ihop dem är det näst vanligaste misstaget.

Inline-komplettering förutspår nästa rader när du skriver. Den är bra för boilerplate och tester där mönstret redan syns på skärmen. Chatt i editorn svarar på frågor om markerad kod och föreslår ändringar som du godkänner hunk för hunk. Agenter tar en uppgift, läser filer, kör kommandon och kommer tillbaka med en gren.

Välj efter hur billigt du kan verifiera resultatet. En komplettering som du kan läsa på två sekunder har låg risk. En agentkörning som rör 14 filer ger hög vinst men också hög granskningskostnad.

Cursor är det editorförsta alternativet: en VS Code-fork med stark Tab-komplettering och parallella agentsessioner. Det är värt det om du arbetar i en editor hela dagen. Hoppa över det om ert team har standardiserat på JetBrains och inte tänker byta.

GitHub Copilot är det lågfriktionsval som passar team som redan använder GitHub, eftersom PR:ar, ärenden och granskning ligger på samma ställe. Håll koll på faktureringen: den övergick till användningsbaserade AI Credits i juni 2026, så tung agentanvändning kostar mer än platspriset antyder.

Claude Code är terminalbaserat och agentiskt: du delegerar en refaktorisering eller en buggjakt och granskar sedan resultatet. Det har ingen inline-autokomplettering och kör bara Claude-modeller. Det är en rimlig avvägning om du vill delegera på uppgiftsnivå.

Aider är det skriptbara, git-nära alternativet. Det committar automatiskt varje ändring med ett meddelande, så en återställning är ett git revert. Du betalar bara för modelltokens, vilket passar dig som vill ha kontroll över kostnaden.

Hur hindrar du AI från att skriva kod som ignorerar ditt repo?

Ge den kontext medvetet. Det mesta av den dåliga utdatan går tillbaka på att modellen aldrig har sett den relevanta filen.

Tre vanor hjälper. Bifoga de två eller tre filer som definierar mönstret, inte hela katalogen. Klistra in det misslyckade testet eller felet ordagrant i stället för att beskriva det. Och ha en kort regelfil i repot, med namngivning, felhantering och förbjudna bibliotek, som verktyget läser vid varje körning. De flesta agentverktyg stödjer någon form av det.

# AI-RULES.md
- Fel: returnera Result, kasta aldrig undantag i services/
- HTTP-anrop går genom lib/http.ts (har retry och spårning)
- Inga nya beroenden utan notering i PR-beskrivningen
- Tester: vitest, placerade bredvid som *.test.ts

Fyra rader som dessa tar bort en överraskande stor andel granskningskommentarer. De hjälper också människor, eftersom de samma regler gäller för dem.

I ett repo som du inte känner ännu bör du ställa frågor innan du ber om ändringar. ”Var upprätthålls sessionsutgången och vad anropar den?” är en bättre första prompt än ”lägg till en refresh-token”. Du läser svaret, öppnar de två filer det hänvisar till och bestämmer först sedan vad som ska ändras. Det är samma loop med grep, blame och att fråga någon som du redan gör, bara snabbare.

Hur granskar du AI-genererad kod?

Långsammare än du granskar en kollegas kod. En kollega har en historik i er kodbas. Modellen har inte det.

Min checklista, i ordning:

• Kör den innan du läser den. Ett godkänt test som du själv har skrivit slår en självsäker förklaring.

• Läs importerna. Påhittade paket och okända hjälpfunktioner syns där först.

• Leta efter det som saknas. Felvägar, null-hantering och städning. Modeller skriver den lyckliga vägen väl.

• Kontrollera diffens storlek. Bad du om en 10-radersfix och fick 120 rader har något skrivits om som du inte bad om.

• Ta bort det du inte kan förklara. Om du inte kan försvara en rad i granskningen går den inte in.

Håll committen liten och meddelandet ärligt. ”Lägg till retry i webhook-avsändaren (AI-assisterad, tester tillagda)” är helt okej. Att dölja det hjälper ingen och gör senare felsökning svårare.

Vad bör du aldrig lämna över till AI?

Allt där fel blir tyst och dyrt. Autentiseringslogik, betalningsflöden, datamigreringar och behörighetskontroller är platser där ”nästan rätt” klarar testerna och faller i produktion.

Du kan fortfarande använda AI där, men i ett annat läge: be den granska din kod och lista risker i stället för att skriva koden. Att läsa en lista med fem möjliga problem tar tre minuter. Att läsa en genererad migrering kan ta hela eftermiddagen, eftersom du sedan ägnar tiden åt att tvivla på den.

Om du lär dig finns ett andra undantag. Skriv den första versionen själv och be sedan modellen kritisera den. En junior som alltid accepterar den genererade versionen lär sig att prompta, inte att programmera, och gapet syns i deras första driftstörning.

Hur förändras det för ett team?

Skillnaden mellan individer och team är granskningsbelastningen. En utvecklare som använder agenter kan öppna fler PR:ar per dag än granskarna hinner läsa. Kom överens om tre saker tidigt:

1. En storleksgräns. PR:ar över några hundra ändrade rader delas upp, oavsett vem eller vad som skrev dem.

2. En norm för öppenhet. Säg när en ändring är AI-assisterad, så att granskarna kan justera sin uppmärksamhet.

3. En delad regelfil. En källa till sanning för konventioner slår fem personliga prompter.

För onboarding är det bästa användningssättet jag har sett frågedriven läsning. Nyanställda frågar assistenten var saker finns och verifierar sedan i koden. Det förkortar den första veckan av ”vem äger det här?” utan att ge dem kod som de inte kan underhålla.

En förstaveckoplan du kan kopiera

Dag 1: använd bara inline-komplettering, för tester och boilerplate. Dag 2: ställ tre kodbasfrågor per dag i chatten och verifiera varje svar. Dag 3: låt chatten föreslå en liten ändring per uppgift och läs varje hunk. Dag 4: prova en agent på ett lågriskjobb, till exempel att byta namn på en konfigurationsnyckel över flera filer, på en egen gren. Dag 5: skriv din regelfil utifrån det som irriterade dig i granskningen.

Följ ett tal under hela veckan: minuter från att du startar ett ärende till en sammanfogad PR, inklusive rättningar efter granskning. Om det inte sjönk har du lärt dig var verktyget inte passar ditt arbete, och det är också ett resultat.

Använd det först för läsning, sedan för skrivande

Den snabbaste ärliga vinsten jag har sett är inte generering. Det är förståelse: att förstå en okänd modul på tio minuter i stället för en timme. Att skriva kod har aldrig varit den långsamma delen av jobbet. Läsning, beslut och verifiering var det. Rikta verktyget mot dem, behåll ditt eget omdöme på knappen för sammanfogning, så följer resten.