Hvorfor AI-generert kode trenger menneskelig gjennomgang (og hvorfor det er helt greit)

Vi er midt i en spennende tid for utvikling. Verktøy som Claude og ChatGPT lar deg gå fra idé til kjørende kode på dager, ikke uker. Beskriv funksjonen, godta endringene, juster litt – og deploy. Dette øker farten dramatisk.

Men det er et men.

Jeg brukte en ettermiddag på å sjekke kode laget akkurat sånn. En enkel internapp, ikke kritisk, men typisk for hvordan vi jobber i 2024. Ikke noe dramatisk som "AI-en løp amok". Nei, 28 feil – mest sikkerhetsproblemer fra OWASP Top 10, kjent siden tidlig 2000-tall.

Dette handler ikke om farlig AI. Det handler om at lynrask kodeproduksjon slår strukturell tenkning som hindrer problemer.

Feilen ligger ikke i AI-en, men i spørsmålene du hopper over

Koden var egentlig bra. God arkitektur, smarte komponenter, fornuftige biblioteker. Hadde jeg laget det selv, ville det sett likt ut ved første øyekast.

Forskjellen er i det som skjer før koden skrives.

AI gjør nøyaktig det du ber om. "Lag et brukersystem" – og vips, der har du det. Men den spør ikke: Hvem får tilgang? Hvilke data er sensitive? Hvor sitter autentiseringen? Hva hvis noen hopper over frontenden?

AI bygger funksjoner. Den designer ikke sikker arkitektur som lar deg sove trygt.

Eksempel: Admin-funksjonen uten lås

Tenk deg en serverless-funksjon for admin-oppgaver: opprett brukere, nullstill passord, slett kontoer. Teamet holdt riktige nøkler på serveren – smart.

Men ingen autentiseringskontroll i det hele tatt.

Ikke svak kontroll. Null. Åpne DevTools, finn URL-en, send POST – og du kan rote fritt med databasen.

Frontenden skjulte admin-knappen for vanlige brukere. Fikst nok, men ubrukelig. Sikkerhet via UI er illusjon.

Klassisk bypass-feil, kjent siden 2003. AI-en sa ikke ifra fordi prompten var "lag funksjon for admin å opprette brukere". Den gjorde det. Uten å nevne at ikke-admins også kunne.

Poenget: AI vet ikke hva du glemte å si.

Databasen som så sikker ut – på papiret

Databasen hadde row-level security (RLS) – bra for å begrense tilgang basert på identitet. Passer når frontenden sender API-nøkler i JS.

Utvikler ba AI legge til multi-bruker-støtte. AI lagde nye tabeller med RLS. Perfekt.

Men de fem gamle tabellene med ekte data? Uendret. Kanskje RLS var på. Kanskje ikke. Migreringen sjekket ikke.

Kjør npm run db:push på ny infra – nye tabeller låst, gamle vidåpne for alle med endpoint-kunnskap.

AI traff målet, men var ufullstendig. Løste smal oppgave uten å spørre om resten.

Hvordan fikse dette i praksis

AI-hjelp er gull for fart. Men du trenger erfarne folk som ser på arkitektur, ikke bare syntaks.

Dette funker:

Sjekkliste før bygging. Spør: Hvem kan kalle endpointen? Hva skjer uten tillatelse? Er dataene åpne? Trenger alle tabeller RLS? Skriv det ned.

Seniorer modellerer trusler, ikke linje-for-linje. De 28 feilene var designfeil. AI genererer kode. Mennesker tenker sikkerhet.

Vær eksplisitt i promptene. Ikke "lag bruker-endepunkt". Si "lag endpoint kun for innlogget admin, og dokumenter autentiseringslogikken".

Test tilgang separat. Sjekk at ikke-autorisert ikke kommer inn, ikke bare at autorisert funker.

Mønsteret du må forstå

AI lager ikke usikker kode. Den lager nøyaktig det du ba om – og ignorerer det du glemte.

Det er en styrke. Du vil ikke ha hallucinasjoner. Men ansvaret flytter til deg. AI utfører dine designvalg, ikke dine tanker.

Koden min trengte et menneske som sa "dette trenger auth". Da tok fiksen minutter. Gammel feil møtte ny workflow – og vant, takket være oppmerksomhet.

Modellen fremover: AI for hastighet, mennesker for struktur. Begge nødvendige.

Vil du unngå slike feller? På NameOcean ser vi startups kjempe med teknisk gjeld fra rask shipping. Vår cloud hosting-plattform har innebygd sikkerhet som rate limiting, API-nøkkelhåndtering og audit logs – alltid på, uansett om du husker å be om det. En mindre ting å stresse med når teamet gasser på.