Kodgranskning kräver nu ett annat förhållningssätt. När merparten av koden i en pull request skrevs av den person som skickade in den, var granskarens uppgift att fånga misstag och dela kunskap. När mycket av den genererats av en modell måste granskaren också verifiera att upphovsmannen faktiskt förstår vad de mergar.
Varför problemets karaktär har förändrats
AI-modeller producerar kod som är syntaktiskt ren, välformaterad och ofta rimlig vid en första anblick. Ytan ser färdig ut. Buggar, när de finns, tenderar att ligga i logik, kantfall eller integrationsantaganden snarare än i uppenbara syntaxfel. Det innebär att de visuella signaler som granskare brukade förlita sig på, stökig formatering, ovanliga mönster, uppenbar klipp-och-klistra, är mindre användbara. Något kan se korrekt ut och ändå vara fel på sätt som spelar roll.
Det finns också ett volymproblem. Utvecklare som använder AI-verktyg kan producera mer kod snabbare. Pull requests blir större och kommer in oftare. Att granska 800 rader kod som en person skrev under två dagar skiljer sig från att granska 800 rader som en modell producerade på tjugo minuter, eftersom det i det andra fallet finns mindre garanti för att upphovsmannen har spårat igenom all kod.
Vad granskare nu kontrollerar
Den praktiska förändringen är att granskare i allt högre grad kontrollerar upphovsmannens förståelse, inte bara kodens korrekthet. Användbara frågor under granskning inkluderar nu:
- Kan upphovsmannen förklara ett specifikt block om man frågar?
- Återspeglar testtäckningen förståelse för kantfall, eller bara de enkla fallen?
- Finns det mönster som ser ut att ha accepterats från modellen utan ändringar?
- Är felhanteringen rimlig för detta system, eller är det generisk standardkod?
Det här är inte ett påstående om att AI-genererad kod är sämre i genomsnitt. Det är ett påstående om att riskprofilen är annorlunda, och att granskningsprocesser byggda för mänskligt skriven kod inte automatiskt fångar felmoderna hos modellgenererad kod.
För mer om vad du bör titta efter när du arbetar med kod du inte har skrivit, se hur man granskar AI-genererad kod och att testa programvara du inte har designat.
Teknisk skuld ackumuleras på ett annat sätt
Med mänskligt skriven kod byggs teknisk skuld vanligtvis upp gradvis. Genvägar tas under tidspress, och den som tog dem vet i allmänhet var problemen döljer sig. Med AI-genererad kod som accepterades utan fullständig förståelse kan skulden se strukturellt sund ut medan de underliggande antagandena är felaktiga. Att refaktorera den senare är svårare eftersom ingen i teamet har en tydlig bild av varför den skrevs på det sättet.
Det gäller särskilt i kodbaser där flera utvecklare använder AI-verktyg var för sig och mergar kod som de andra inte har läst noga. Sammantaget kan kodbasen bli svår att resonera kring: ingen enskild fil behöver vara dålig, men den mentala modellen av hur delarna hänger ihop byggdes aldrig upp ordentligt.
Vad som inte har förändrats
Målet med kodgranskning är fortfarande detsamma: delad förståelse för vad som finns i produktion och förtroende för att det beter sig korrekt. Metoderna för att uppnå det målet har förändrats. Att be upphovspersoner gå igenom logiken muntligt, kräva förklaringar av icke-uppenbara designbeslut och vara mer noggrann med testkvalitet är alla metoder som var bra tidigare och är viktigare nu.
Vissa team har svarat med att också lägga till AI-verktyg på granskningssidan och använder modeller för att flagga potentiella problem innan mänsklig granskning. Det kan minska bruset, men det tar inte bort behovet av en mänsklig granskare som förstår systemet.
Vad vi testar
Båda sessionerna i hur vi granskar är direkt relevanta här. Session 1 fastställer om en utvecklare kan hitta verkliga problem utan hjälp, genom strukturerad felsökning och genuin teknisk förståelse av stacken. Session 2 testar samma instinkter under andra förhållanden: om de fångar upp hallucinerade API:er eller subtilt felaktig logik i genererat resultat innan det levereras, och om de kan förklara en ändring de inte skrivit själva. Utvecklare som behandlar verifiering av AI-resultat som valfritt tenderar att göra granskning till en ceremoni snarare än något användbart.
Korta svar
Är AI-genererad kod svårare att granska än mänskligt skriven kod?
Den är annorlunda att granska, inte nödvändigtvis svårare i volymmässig bemärkelse. Ytan är ofta ren, vilket kan dölja logikfel eller felaktiga antaganden. Den huvudsakliga utmaningen är att granskare inte längre kan anta att upphovspersonen fullt ut förstår varje rad de lämnade in.
Innebär snabbare kodgenerering mer teknisk skuld?
Det kan det, om granskningsrutinerna inte håller jämna steg. När kod genereras och accepteras utan att upphovspersonen har gått igenom den ackumulerar teamet antaganden som ingen har verifierat. Det skapar en skuld som är svårare att hitta och åtgärda än den som medvetet byggs upp under tidspress.
Bör team lägga till AI-verktyg i själva granskningsprocessen?
Det kan hjälpa med ytliga kontroller, men det ersätter inte en granskare som förstår systemet. Automatiserad granskning fångar vissa problem, men verifierar inte att upphovspersonen förstod vad de mergade eller att designen passar in i den bredare kodbasen.
