Så granskar du AI-genererad kod

För att granska AI-genererad kod börjar du med vad som ändrats, vilka filer och varför, och testar sedan beteendet själv innan du läser en enda rad kod. Därefter kontrollerar du de områden där AI-kod oftast går fel: saknade behörighetskontroller på servern, hemligheter som exponeras för webbläsaren, ovaliderad indata, paket eller funktioner som inte finns, och redigeringar av saker du aldrig bad den röra.

AI skriver kod som oftast fungerar och ofta ser städad ut. Det gör den lätt att godkänna utan att verkligen kontrollera den. Den här guiden är en granskningsrutin som fungerar oavsett om du läser kod flytande eller inte alls.

Anpassa granskningen efter risken

Alla ändringar behöver inte samma uppmärksamhet.

Steg 1: Se vad som ändrats

Innan du bedömer koden, skaffa listan över ändringar:

• Om projektet ligger i Git, titta på diffen: filerna och raderna som ändrats sedan senaste commit. Se så använder du Git med en AI-byggd app.
• Eller fråga AI:n direkt:

Lista varje fil du ändrade i den senaste ändringen, och förklara för varje fil med en mening vad som ändrats och varför.

Röda flaggor i det här steget: filer som inte har med förfrågan att göra, raderade filer, ändringar i konfiguration eller beroenden som du inte bad om.

Steg 2: Testa beteendet först

Kod berättar vad den är tänkt att göra; testning visar vad den faktiskt gör. Innan du läser:

• Prova ändringen som en vanlig användare, på dator och på en skärm i telefonstorlek.
• Prova med felaktig indata: tomma fält, mycket lång text, negativa tal, ett datum i det förflutna.
• Prova utloggad, och som en annan användare.
• Kör om de flöden som är viktigast: registrering, inloggning, huvudåtgärden, betalning.

Faller testerna har du sparat läsningstid. Rapportera tydligt och låt AI:n åtgärda det. Se så skriver du en bra buggrapport.

Steg 3: Kontrollera behörigheter på servern

Det viktigaste att kontrollera. AI-verktyg döljer ofta en knapp i sidan men låter servern ändå utföra åtgärden för vem som helst som frågar.

För varje rutt eller funktion som läser eller ändrar data, fråga:

• Kontrollerar den att användaren är inloggad?
• Kontrollerar den att just den här användaren får åtkomst till den här posten?
• Sker kontrollen på servern, inte bara i sidan?

För varje API-rutt du har lagt till eller ändrat, berätta vilken behörighetskontroll den gör på servern, och citera raden. Flagga varje rutt som saknar en.

Testa sedan: logga in som användare A, notera ett posts ID, logga in som användare B och begär den. Säkerhetschecklistan för AI-byggda appar har hela testet.

Steg 4: Leta efter exponerade hemligheter

• Sök i de ändrade filerna efter allt som liknar en nyckel eller ett lösenord.
• Kontrollera att hemliga nycklar läses från miljövariabler och bara används i serverkod.
• Var uppmärksam på publika prefix som VITE_ eller NEXT_PUBLIC_ på hemliga variabler. De byggs in i kod som körs i webbläsaren.

Se så håller du API-nycklar säkra.

Steg 5: Kontrollera indata och fel

• Validering på servern. Kontroller i webbläsaren kan kringgås. Obligatoriska fält, längder, format och tillåtna värden bör kontrolleras av servern också.
• Databasfrågor använder parametrar, inte text som byggs genom att sammanfoga användarens indata till en fråga.
• Fel sväljs inte. En try/catch som inte gör något döljer fel. Fel bör loggas och användaren bör se ett enkelt meddelande.
• Inga interna detaljer visas för användare. Stack traces och databasfel hör hemma i loggarna.

Steg 6: Kontrollera att det är verkligt

AI-modeller producerar ibland kod som ser rätt ut men hänvisar till saker som inte finns.

• Paket: varje nytt beroende bör vara ett verkligt, underhållet paket med exakt det namnet. Var försiktig med namn som ser ut som stavfel av populära paket.
• Funktioner och API-alternativ: om koden anropar en biblioteksfunktion eller ett externt API-alternativ du aldrig sett, kontrollera den officiella dokumentationen.
• Platshållarkod: sök efter TODO, mock, fake, hårdkodad exempeldata eller funktioner som returnerar ett fast värde.

Har du lagt till några nya paket? Ange för varje exakt namn, vad det är till för och om vi kan klara oss utan det.

Steg 7: Kontrollera att det passar

Kod kan fungera och ändå göra appen svårare att ändra senare:

• Dubblering. Samma logik kopierad till flera ställen glider isär.
• Konsekvens. Den ska följa de mönster resten av appen använder.
• Storlek. En förfrågan på 20 rader som gav 600 rader förtjänar en fråga.
• Död kod. Gamla versioner som lämnats kvar bredvid nya.

Finns det kod i projektet som nu inte används på grund av den här ändringen, eller logik som är duplicerad någon annanstans? Ändra ingenting; lista bara.

Vanliga misstag

• Godkänna för att det ser rent ut. Snygg kod kan fortfarande hoppa över en behörighetskontroll.
• Läsa i stället för att testa. Testa först; läs sedan.
• Bara testa den lyckade vägen. Prova dålig indata, fel användare och utloggad.
• Ignorera oväntade filändringar. Fråga varför varje fil ändrats.
• Lita helt på AI:ns egen granskning. Använd den som ett första varv och bekräfta genom testning.
• Granska en veckas ändringar på en gång. Granska små ändringar när de sker.

Checklista

• Jag vet vilka filer som ändrats och varför, och inget oväntat har ändrats.
• Ändringen fungerar på dator och telefon, med dålig indata, utloggad och som en annan användare.
• Varje datarutt kontrollerar inloggning och ägarskap på servern.
• Inga hemligheter i kod eller i webbläsarpaketen.
• Indata valideras på servern; frågor använder parametrar.
• Fel loggas, sväljs inte och visas inte i detalj för användare.
• Nya paket är verkliga och behövs; inga påhittade funktioner eller platshållare finns kvar.
• Ändringar med hög risk har läst noggrant och vid behov granskats av en andra person.

Granska kod på Mythex

• Frågeläget svarar på frågor om koden utan att redigera den, vilket är perfekt för prompter som ”förklara varje ändring” och ”vilka rutter saknar en behörighetskontroll”. Se Chatt.
• Kodvyn visar filträdet, editorn och terminalen på alla planer (skrivskyddad på Free, redigerbar på Pro), så att du kan läsa vad som ändrats själv. Se Kodeditor.
• /test låter agenten klicka igenom förhandsgranskningen som en användare och rapportera trasiga flöden.
• Checkpoints låter dig återställa en ändring som inte klarar granskningen.

Om en utvecklare granskar åt dig beskriver så arbetar du med en utvecklare i en AI-byggd app överlämningen. Om granskningen hittar en bugg, se så felsöker du en AI-byggd app.

Frågor