Granska AI-genererad kod: sju frågor per diff

Del tre i serien. Granskningen blir avsevärt enklare om ändringen är liten — se Små diffar vinner.

Kort sagt

AI-genererad kod misslyckas på ett annat sätt än handskriven. Den innehåller sällan slarvfel och nästan aldrig stavfel. Den innehåller desto oftare kod som är korrekt i allmänhet och fel just här — rätt mönster på fel plats, hantering av fall som inte finns, och avsaknad av det ni faktiskt behöver. Granska efter det, inte efter buggar i syntaxen.

Varför AI-kod granskas annorlunda

Traditionell kodgranskning bygger på ett antagande som inte längre håller: att den som skrev koden förstod den. När en kollega lämnar en pull request kan du ställa frågan "varför gjorde du så här?" och få ett svar som bygger på ett resonemang. När koden kommer från en modell finns inget sådant resonemang att fråga efter — bara ett mönster som passade.

Det gör att risken flyttar. Handskriven kod går sönder på det författaren missade. AI-genererad kod går sönder på det som såg tillräckligt rätt ut för att ingen skulle titta närmare.

Praktiskt betyder det två saker. Du kan lita mer på att koden kompilerar och kör. Du kan lita mindre på att den gör rätt sak i ditt system.

Vad du tittar på först

Ordningen spelar roll, för uppmärksamheten tar slut. Börja där konsekvenserna är störst, inte där koden är lättast att läsa.

Behörighet och åtkomst. Kan fel användare nå fel data? Det här är det vanligaste som saknas helt, eftersom det sällan syns i uppgiftsformuleringen.

Vad som händer när något går fel. Fångas felet, sväljs det, eller sprids det vidare? Tyst felhantering är svårast att upptäcka senare.

Gränsfallen i indata. Tomt, null, negativt, för långt, fel typ. Modellen skriver ofta för det förväntade fallet.

Nya beroenden. Kom det in ett bibliotek? Är det ett ni redan har, är det underhållet, behövdes det?

Sedan resten. Namngivning, struktur, dubblering. Viktigt, men billigare att rätta senare.

Sju frågor per diff

Frågorna är inte en process att dokumentera. De är sju saker att ha i huvudet medan du läser, och de går snabbt när de sitter.

Kan jag förklara varje rad? Om inte — fråga tills du kan, eller ta bort raden. Kod ingen förstår är kod ingen kan underhålla.
Gör den bara det jag bad om? Extra "förbättringar" i förbifarten är hur en liten ändring blir en stor.
Vad händer med tom eller ogiltig indata? Följ vägen genom koden, inte bara det lyckade fallet.
Var kommer datan ifrån, och är den betrodd? Användarindata som når en databasfråga eller ett skalkommando utan mellanled är den klassiska.
Vad loggas? Genererad felhantering loggar gärna hela objektet — inklusive lösenord, tokens och personuppgifter.
Stämmer det med hur vi gör i övrigt? Ett avvikande mönster är inte fel i sig, men det ska vara ett beslut och inte ett sammanträffande.
Hur vet jag att det fungerar? Om svaret är "det ser rätt ut" är granskningen inte klar.

Det som ser rätt ut men inte är det

Vissa fel är svåra att se just för att koden ser välskriven ut. De här återkommer.

Uppfunna API:er

En metod som borde finnas men inte gör det, eller som finns med andra parametrar i en annan version. Kompilerar inte i typade språk, men går rakt igenom i dynamiska.

Fel som sväljs

Ett catch som loggar och fortsätter. Programmet kraschar inte — det gör bara fel sak, tyst, tills någon upptäcker det i data.

Behörighet på fel nivå

Kontrollen finns i gränssnittet men inte i det som faktiskt hämtar data. Ser komplett ut i granskningen om du bara läser den ena filen.

Rätt mönster, fel plats

Ett helt korrekt cachelager, retry-mönster eller abstraktion — infört på ett ställe där det inte behövdes och nu ska underhållas för alltid.

Villkor som aldrig blir sanna

Hantering av ett fall som inte kan uppstå i ert system. Ofarligt men vilseledande: nästa läsare tror att fallet finns.

Tidszoner och lokalisering

Datumhantering som antar UTC, engelska månadsnamn eller punkt som decimaltecken. Fungerar i testet, går sönder hos användaren.

Att granska kod i ett språk du inte kan

Det här är en verklig situation nu på ett sätt det inte var förut: modellen skriver gärna Terraform, SQL eller en bash-rad åt någon som inte skriver sådant till vardags.

Du kan inte granska syntaxen. Du kan fortfarande granska tre saker, och de täcker det mesta av risken:

Granskning utan språkkunskap

Be om en förklaring rad för rad — och kontrollera att förklaringen stämmer med vad du bad om. Missmatchen mellan avsikt och förklaring syns även om koden inte gör det.
Leta efter det destruktiva. Vad tar bort, skriver över eller ger rättigheter? De orden går att hitta utan att kunna språket.
Kör det på något som inte spelar roll först. En testmiljö, en kopia, en tom databas. En körning säger mer än en genomläsning du inte är kvalificerad att göra.

Gränsen

Om koden rör pengar, användarkonton, personuppgifter eller något som inte går att backa — granska den inte ensam i ett språk du inte behärskar. Ta hjälp av någon som gör det. Det här är inte en formalitet; det är den situation där kostnaden för ett plausibelt men felaktigt svar är som störst.

Granskning i praktiken

Två vanor gör mer skillnad än någon checklista.

Läs diffen som om en kollega skickat den. Samma standard, samma frågor. Att koden kom från en modell är inte ett skäl att granska mildare — det är ett skäl att granska annorlunda.

Håll ändringen liten nog att orka. Det här är den verkliga flaskhalsen. En diff på fyrtio rader granskas ordentligt. En på fyrahundra skummas, oavsett hur samvetsgrann du är. Storleken på ändringen bestämmer kvaliteten på granskningen mer än granskarens ambition gör.

Granskningen fångar det som är fel i koden. Nästa guide handlar om det som fångas först när koden körs.

Nästa guide

Felsökning med AI

→