Den osynliga skatten på AI-genererad kod: Varför vibe coding haltar

Låt mig berätta om ett samtal jag hade förra veckan med en startup-grundare. Han hade levererat funktioner i en otrolig takt – tre gånger snabbare än på hans förra företag. "Vi vibe-codar allt," sa han stolt. Sedan nämnde han att hans autentiseringssystem hade utnyttjats två gånger under den senaste månaden.

Kopplingen är inte slumpmässig.

Fartfällan

Här är den obekväma sanningen som ingen pratar om på de där AI-konferenserna: den fantastiska hastighetsökningen kommer med en mätbar defektskatt. Forskning visar konsekvent att ungefär 45% av AI-genererad kod innehåller säkerhetsproblem. Inte småproblem – riktiga, utnyttjbara brister som kan exponera användardata, kringgå autentisering eller skapa vägar för angripare.

Mekanismen är inte att AI producerar dålig kod. Mekanismen är att vibe coding tar bort de grindar som fångar dålig kod.

När du promptar en AI-agent och skickar utdata utan att läsa den ordentligt kringgår du hela din SDLC. Ingen spec-granskning. Ingen säkerhetsrevision. Ingen verifiering av testtäckning. Ingen dokumentation. Du tar bort exakt de kontrollpunkter som finns för att skydda användare och ditt rykte.

Var AI:n gör fel (förutsägbart)

Här är vad som gör detta särskilt farligt: AI misslyckas inte slumpmässigt. Defekterna koncentreras på exakt fel ställen.

Cross-site scripting-sårbarheter dyker upp 2,74 gånger oftare än i mänskligt skriven kod. Logikfel förekommer 1,75 gånger över baseline. Det här handlar inte om estetiska problem eller hantering av kantfall – det här är sårbarheterna som betyder något för autentisering, betalningshantering och alla system som hanterar o betrodda användardata.

Oberoende säkerhetstelemetri bekräftar mönstret. Branschrapporter kopplar nu ökande sårbarhetsräkningar direkt till ökad adoption av generativ AI i utvecklingsarbetsflöden. Allvarlighetsgraden av dessa sårbarheter ökar också.

De tre egenskaperna som gör det farligt

Det här handlar inte bara om enskilda misstag. Problemet förstärks på grund av hur AI-agenter fundamentalt fungerar:

Hastigheten överstiger granskningen. En agent kan generera tusen rader kod på några sekunder. En mänsklig granskare kan inte meningsfullt inspecta den koden i samma tempo. Detta skapar strukturellt tryck att hoppa över granskningssteget.

Icke-determinism motverkar reproduktion. Samma prompt kan ge olika utdata. Den bugg du märkte? Lycka till med att reproducera exakt vilken version av koden som orsakade den. Detta gör debugging till en rörlig måltavla och granskningsspår opålitliga.

Kostnadstryck uppmuntrar genvägar. AI-tokens kostar pengar. Att köra omfattande tester kostar fler tokens. Det ekonomiska incitamentet driver mot att skära ner på verifiering – motsatsen till vad säkerhet kräver.

Verklig skada, verkliga exempel

Du kanske tror att det här är teoretiskt. Det är det inte.

Säkerhetsforskare har dokumenterat AI-genererad skadlig kod med kritiska implementeringsfel – kod som var tänkt att vara farlig men misslyckades med grundläggande kryptografisk implementation. Ännu mer oroande: välmenande utvecklare har skickat produktionsramverk med autentiseringskringgående-sårbarheter som AI-verktyg hjälpte till att generera. I båda fallen var felet inte illvilja eller inkompetens – det var att behandla AI-utdata som produktionsklart utan den normala verifieringspipelinen.

Mellanvägen

Jag säger inte att du inte ska använda AI-kodningsverktyg. Det vore som att 2015 råda utvecklare att undvika GitHub för att kodhosting kunde möjliggöra dåliga metoder. Produktivitetsvinsterna är verkliga och tekniken försvinner inte.

Men vi måste vara ärliga om var flaskhalsarna förskjuts.

Throughput-vinsten från AI-kodning är genuint. Men den flyttar flaskhalsen från att skriva till att verifiera. Om du inte räknar med den förskjutningen ackumulerar du teknisk skuld snabbare än du levererar funktioner.

Här är vad det betyder i praktiken:

Behandla AI som en höghastighets-praktikant, inte en senior ingenjör. En junior utvecklare kan generera kod snabbt. En senior utvecklare kan berätta varför den koden är säker att skicka. AI-verktyg är utmärkta på det förra. Du behöver människor för det senare.

Implementera ett PR-kontrakt. Varje pull request bör dokumentera: Vad var intentionen? Vilka bevis styrker att det fungerar? Vilken risknivå? Användes AI för att generera detta, och i så fall var? Detta tvingar fram den ansvarsskyldighet som vibe coding tar bort.

Decentralisera kritiska säkerhetskontroller. Lita inte på autentiserings-middleware som din enda grind. Implementera auktoriseringskontroller direkt i route-handlers. Flytta säkerhetskritisk logik bort från single points of failure som AI-verktyg might subtly miskonfigurera.

Reservera vibe coding för lämpliga sammanhang. Scaffolding en CLI? Prototyping ett UI? Utforska optimeringsmetoder innan du förbinder dig till en arkitektur? Perfekta användningsfall. Skicka direkt till produktion med obetrodda input-hantering? Det är där du behöver spec-driven development med granskningsgrindar.

Investera i threat modeling före merge. Varje kodväg som hanterar obetrodda input behöver en mänsklig threat-model-pass innan den når produktion. Inte valfritt. Inte hoppbart när du är efter på deadline.

Den faktiska regeln

Gränsen mellan "säkert att vibe" och "måste konstruera" är inte skarp. Den förskjuts när modeller förbättras och när ditt system växer i komplexitet. Regeln kan inte vara "använd aldrig AI för kodning." Regeln måste vara: "vet vilket läge du är i och grinda efter insatserna."

Men här är där alla är överens: så fort din bugg kan skada någon annan är prompt-and-ship en regression. Så fort din kod hanterar riktiga pengar, riktiga personuppgifter eller riktiga säkerhetsbeslut kan inte vibe codings hastighetsvinster motivera att ta bort den verifieringsinfrastruktur som skyddar dina användare.

Utvecklarna och teamen som ansvarsfullt levererar AI-genererad kod rör sig inte långsammare. De rör sig med medvetenhet om var verifieringsflaskhalsen nu finns – och budgeterar för den ärligt.

Dina användare räknar med att du fångar det AI:n missar.

Vi på NameOcean tror att kraftfulla verktyg förtjänar genomtänkt implementation. Oavsett om du registrerar en domain för ditt nästa projekt eller distribuerar AI-assisterad kod, gäller grunderna för ansvarsfull ingenjörskonst. Bygg snabbt, men bygg rätt.