Varför AI-genererad kod ändå behöver mänsklig granskning (och varför det är helt okej)

Vi befinner oss i en spännande fas av mjukvaruutveckling. Verktyg som Claude och ChatGPT förvandlar idéer till fungerande kod på dagar istället för veckor. Beskriv en funktion, godkänn ändringarna, iterera och driftsätt. Det ökar tempot rejält.

Men det finns en hake.

Jag granskade nyligen kod för ett enkelt internt verktyg. Inget kritiskt, men typiskt för hur vi bygger 2024. Inga sci-fi-fel där AI löper amok. Istället 28 problem, mest säkerhetsrelaterade. Många från OWASP Top 10 – kända svagheter sen millennieskiftet.

Det handlar inte om farlig AI. Det handlar om hur snabb feature-utveckling kan springa ifrån grundläggande säkerhetstänk.

Felet ligger inte i AI:n, utan i frågan du glömde ställa

Koden var faktiskt bra. Arkitekturen höll ihop. Komponenterna var logiska. Bibliotek valdes smart. Hade jag byggt det själv en helg hade det sett likadant ut vid första anblick.

Skillnaden gömmer sig i förarbetet. Innan första raden kod.

AI gör precis vad du ber om. "Skapa ett användarhanteringssystem" – och vips, där är det. Men den frågar inte: Vem får tillgång? Vilken data är känslig? Var hanteras autentisering? Vad händer vid bypass av frontenden?

AI levererar funktioner. Inte den säkerhetsarkitektur som låter dig sova gott.

Exempel: Admin-funktionen utan skydd

Tänk dig en serverless-funktion för admin-uppgifter. Skapa användare, nollställ lösenord, radera konton. Lagligt beslut: Starka credentials hålls på servern, aldrig i browsern.

Men ingen autentiseringskontroll alls.

Inte svag eller felaktig. Noll. Öppna DevTools, hitta endpointen, skicka POST – och du skapar admin-konton eller raderar databaser.

Frontenden dolde admin-knappen för icke-admins. Fint tänkt. Men värdelöst – säkerhet via UI är en illusion.

Klassisk authorization bypass, på listan sen 2003. Varför missade AI:n det? Prompten var "bygg en funktion för admins att skapa användare". Den gör det. Och låter även andra göra det, för prompten specificerade inte motsatsen.

Lärdomen: AI vet inte vad du glömt fråga efter.

Databasen som verkade säker

Databasen har row-level security (RLS) – perfekt för att begränsa åtkomst baserat på identitet. Särskilt när frontenden skickar API-nycklar i JavaScript.

En utvecklare bad AI lägga till multi-user-stöd. AI skapade nya tabeller med RLS. Toppjobb.

Men de fem befintliga tabellerna med affärsdata? Obekymrade. Migrationsscriptet kollade inte, aktiverade inte RLS, nämnde det inte.

Kör npm run db:push på ny infra – nya tabeller låsta, gamla vidöppna för vem som helst med endpoint-kunskap.

AI var inte fel. Bara ofullständig. Löste det smala problemet utan att ifrågasätta det stora (säkra allt?).

Så här anpassar du din utvecklingsprocess

AI-assisterad kodning är grymt. Snabbhet räknas. Men det kräver mänsklig input på arkitektur, inte bara syntax.

Vad som funkar:

Sätt upp säkerhetschecklista först. Fråga: Vem får kalla endpointen? Vad händer utan tillstånd? Ska datan vara publik? Behöver alla tabeller RLS? Dokumentera antaganden innan kodning.

Låt seniora devs modellera hot, inte granska rad för rad. De 28 felen var arkitekturmissar, inte stavfel. AI genererar kod. Människor tänker säkerhet.

Var explicit med auth i prompten. Skippa "bygg användarhantering". Säg "bygg användarhantering som bara inloggad admin når, och dokumentera auth-antaganden". Då visar AI sitt resonemang.

Testa auth separat från funktion. Skriv tester som bekräftar att icke-autentiserade inte kan agera, inte bara att autentiserade kan.

Mönstret du måste fatta

AI skapar inte osäker kod. Den skapar exakt vad du ber om – och missar det du glömmer nämna.

Det är en styrka, inte svaghet. Verktyget ska inte hitta på krav. Men ansvaret flyttas till dig. AI exekverar din säkerhetsdesign i stor skala, tänker inte ut den åt dig.

Koden jag granskade behövde en människa som sa "denna endpoint behöver auth". Fixen tog minuter. 20-årig sårbarhet mötte 2024-workflow – och workflowen vann, tack vare vaken blick.

Framtiden: AI för hastighet, människor för arkitektur. Båda behövs.

Vill du slippa såna här fällor i din kodbas? På NameOcean har vi sett startups drunkna i teknisk skuld från hastiga releaser. Vår cloud hosting-plattform har inbyggd säkerhet som rate limiting, API-nyckelhantering och audit logs – alltid på, oavsett om du tänker på det eller inte. Ett bekymmer mindre när teamet gasar på.