Verkliga orsaker och konkreta lösningar. AI optimerar för en fungerande demo, inte ett produktionssystem. Med 15–30 tysta arkitekturbeslut per feature med ~70% träffsäkerhet vardera, är sannolikheten att ALLA är korrekta praktiskt taget noll.
“Det fungerar på min maskin” är det äldsta skämtet inom mjukvaruutveckling. Med AI-genererade appar är det inget skämt — det är standardtillståndet. AI tänker inte på produktion. Den vet inte vad en lastbalanserare, anslutningspool eller hemlighetshanterare är. Den ser bara en sak: din lokala kontext, din fil, ditt försök att köra den.
När AI bygger en feature fattar den 15–30 tysta arkitekturbeslut: vilken databas, hur man ansluter till ett API, var man lagrar nycklar, hur man hanterar fel. Varje beslut har ungefär 70% chans att vara korrekt. Men för att hela featuren ska fungera i produktion måste alla beslut vara korrekta. Sannolikheten? Med 20 beslut: 0.7^20 = 0.08%. Praktiskt taget noll.
Den här artikeln tar upp de sex vanligaste orsakerna till att AI-appar fungerar lokalt men kraschar i produktion — med konkreta exempel och lösningar. Om du bygger med Cursor, Bolt, Lovable, Replit eller något annat AI-verktyg, är den här guiden för dig.
Detta är den mest uppenbara och samtidigt vanligaste orsaken till produktionsfel: konfiguration som bara fungerar lokalt. Din .env-fil på din laptop har riktiga API-nycklar, korrekta URL:er, fungerande hemligheter. I produktion? Platshållare, saknade variabler eller helt andra adresser.
AI tänker aldrig på konfigurationshantering — den ser bara lokal kontext. När den genererar kod som ansluter till ett API skriver den http://localhost:3000 direkt i koden. När den behöver en API-nyckel skapar den en variabel med ett standardvärde. När den bygger en databas-URL hardkodar den anslutningssträngen.
Typiska problem:
http://localhost:3000/api istället för en miljövariabel. Fungerar lokalt, pekar ingenstans i produktion..env-fil. Du måste sätta variabler i din hostingpanel (Vercel, Railway, Render).http://, produktion kräver https://. Att blanda protokoll orsakar webbläsarblockering (mixed content) och CORS-fel.Din lokala .env har riktiga nycklar. Produktion kan ha platshållare, felaktiga URL:er eller saknade hemligheter. AI tänker aldrig på konfigurationshantering — den ser bara lokal kontext.
Externalisera ALL konfiguration. Varje URL, varje nyckel, varje hemlighet bör komma från en miljövariabel — aldrig från källkod. Använd en hemlighetshanterare (t.ex. Doppler, AWS Secrets Manager, Vercel Environment Variables). Skapa en .env.example-fil med namnet på varje krävd variabel (utan värden) och lägg till den i repot som dokumentation.
AI älskar SQLite. Den är enkel, kräver ingen server, det är bara en fil. Perfekt för en prototyp. Problemet? Serverlösa plattformar (Vercel, Netlify Functions, AWS Lambda) stödjer inte SQLite eftersom varje förfrågan kan träffa en annan instans — det finns inget delat filsystem.
Men databasen är inte bara motorn. Det är en hel uppsättning antaganden som AI gör tyst:
AI använder SQLite för att den inte kräver någon server. Men serverlösa plattformar bryter SQLite — varje förfrågan kan träffa en annan instans utan delat filsystem. Förfrågningar som fungerar på 50 rader tar 30 sekunder på 50 000 utan index.
Använd PostgreSQL eller MySQL i produktion. Konfigurera anslutningspoolning (PgBouncer, Supabase har det inbyggt). Lägg till index på kolumner som används i WHERE och JOIN. Planera en migrationsstrategi — använd ett verktyg som Prisma Migrate, Drizzle eller vanliga SQL-filer med versionering. Modifiera aldrig ditt produktionsschema manuellt.
En Georgetown CSET-studie fann att 45% av AI-genererad kod innehåller säkerhetsbrister. Det här är inte ett marginellt problem — det är nästan hälften av all kod. Och kod som “fungerar” på localhost behöver inte vara säker.
En skanning av 5 600 vibe-kodade appar avslöjade över 2 000 högriskbrister och över 400 exponerade hemligheter. Plattformen Moltbook exponerade 1,5 miljoner API-nycklar — Row Level Security på Supabase aktiverades aldrig. Lovable hade inverterad åtkomstkontroll över 170 produktionsappar (CVE-2025-48757): autentiserade användare blockerades medan oautentiserade fick full åtkomst.
Problem jag ser regelbundet:
45% av AI-kod innehåller säkerhetsbrister. Skanning av 5 600 vibe-kodade appar: 2 000+ högriskbrister, 400+ exponerade hemligheter. Lovable hade inverterad åtkomstkontroll över 170 produktionsappar.
Kör en OWASP Top 10-granskning. Aktivera Row Level Security på Supabase. Validera alla inputs på serversidan (lita aldrig på klienten). Skanna ditt repo efter exponerade hemligheter (använd gitleaks eller trufflehog). Lägg till rate limiting på alla publika endpoints. Flytta API-nycklar från frontend till backend.
Din applikation fungerar för de första 100 förfrågningarna. Förfrågan nummer 1 001 orsakar en krasch — alla databasanslutningar är uttömda. Varför? För att AI aldrig stängde dem. Varje förfrågan öppnade en ny anslutning, men ingen frigav den.
Samma sak gäller filhandtag, WebSocket-lyssnare, timers och prenumerationer. AI skapar resurser men frigör dem inte. På localhost märker du inte det för att servern startas om var några minut och återställer allt. I produktion kör servern kontinuerligt — och resurser tar slut.
Ännu värre är tysta fel:
try/catch-block — betalning misslyckas, webhook avfyras inte, men användaren ser inget fel. Data försvinner tyst.Databasanslutningar som aldrig stängs. Filhandtag som lämnas öppna. WebSocket-lyssnare som aldrig rensas. Fungerar för de första 100 förfrågningarna — förfrågan 1 001 kraschar för alla anslutningar är uttömda.
Lägg till error boundaries på frontend (React: ErrorBoundary). Lägg till en global felhanterare på backend (process.on('uncaughtException')). Driftsätt strukturerad loggning (Sentry, LogRocket, Pino). Stäng databasanslutningar efter användning (eller använd anslutningspoolning). Rensa lyssnare och timers i useEffect cleanup. Belastningstesta — att kontrollera att det fungerar en gång räcker inte.
Det här är inte teoretiska hot. Det här är incidenter som redan har hänt:
t3.micro kostar annorlunda än r5.4xlarge. Kostnadsskalning är något AI aldrig tänker på.plan istället för price), dubbeldebiteringar i 2 veckor innan någon märkte.AI lovade 10x-utvecklare. Istället: juniorer blev promptingenjörer, seniorer blev kodstädare. Kostnaden för att fixa AI-kod överstiger ofta kostnaden för att skriva den från början.
Mönstret upprepas: AI genererar kod som ser bra ut. Den klarar kodgranskning (för den är läsbar). Den klarar tester (för den testar den lyckliga vägen). Sedan exploderar den i produktion för att ingen kontrollerade prestanda under belastning, felhantering, säkerhet eller infrastrukturkostnader.
Innan du driftsätter din applikation, gå igenom dessa punkter. Varje ouppfylld punkt är ett potentiellt produktionsfel. Denna checklista byggdes från dussintal AI-appgranskningar jag genomfört för kunder.
För att localhost är en perfekt miljö: same-origin (ingen CORS), noll nätverkslatens, dev-läge maskerar varningar, du är den enda användaren (inga race conditions, ingen belastning). I produktion är varje ett av dessa villkor annorlunda — och något av dem kan orsaka ett fel.
Saknade miljövariabler och hardkodad konfiguration. Det är trivialt, men det står för majoriteten av “fungerar lokalt, misslyckas i produktion”-problemen. Din .env har nycklar — produktionsservern har det inte. AI hardkodar URL:er i källkoden istället för att använda miljövariabler.
Enkel fråga: om du inte kan svara på “vad händer när X går ner?” för varje kritisk väg, är din app inte klar. Vad händer när databasen är otillgänglig? När Stripe-API:et returnerar ett fel? När 100 användare klickar “Köp” samma sekund? Om du inte har svar — har du arbete att göra.
Vanligtvis inte. Börja med en granskning. Identifiera kritiska brister (säkerhet, databas, konfiguration). Fixa dem punkt för punkt. En fullständig omskrivning är bara meningsfull när arkitekturen är fundamentalt felaktig — men i de flesta fall kan du fixa befintlig kod iterativt utan att förlora det arbete som gjorts hittills.
Plattform är inte lika med produktionsklar. Vercel och Netlify är utmärkta hostingverktyg, men hosting ensamt är inte “produktion”. Du behöver fortfarande korrekt CORS-konfiguration, övervakning, felhantering, säkerhet, en riktig databas och belastningstester. Knappen “Deploy” är början, inte slutet.
Vi hjälper dig identifiera och fixa vart och ett av dessa problem. Granskning, fix, driftsättning — från prototyp till produktion.
Boka ett gratis samtal →