Hvorfor AI-genererte apper feiler i produksjon
AI tar deg til 80% raskt. Men de siste 20% er der all ekte ingeniørkunst bor — og der de fleste prosjektene dør.
Jeg har bygget apper i over 20 år. 60+ no-code- og AI-genererte prosjekter levert, de fleste av dem redningsaksjoner — gründere som bygde det selv eller lot AI generere hele greia, og så kom til meg med det samme problemet: «Det fungerte på demoen, men det faller fra hverandre i produksjon.»
Her er det folk bommer på. De ser en 90%-løsning på et komplekst problem og tror det utgjør 90% av jobben. Det er som regel 50% på det meste. Sannsynligvis mindre. For det er ikke samme type arbeid. De første 80% er prototypen. De siste 20% er ingeniørfag — sikkerhet, feilhåndtering, skalerbarhet, testing, deployment, overvåking. Alt det som gjør at appen overlever møtet med ekte brukere.
Det finnes en rar kultur av «jeg shippa det på en helg»-innlegg som hopper helt over delen der du faktisk må herde applikasjonen før ekte folk tar den i bruk. Ingen snakker om HTTPS-oppsett, sikkerhetsheadere, eller hva som skjer når to prosesser prøver å skrive til samme rad. Men det er nøyaktig der de virkelige problemene ligger.
Denne artikkelen handler om den delen. Om de spesifikke feilmønstrene jeg ser i hvert eneste AI-genererte prosjekt, og hvordan du fikser dem — steg for steg, uten teori.
Pålitelighetsmatematikken ingen snakker om
Før vi går inn på konkrete bugs, la oss snakke om matematikken. For det er her illusjonen om AI-genererte apper faller fra hverandre.
Si at hvert steg i agent-arbeidsflyten din har 95% nøyaktighet. Høres bra ut, ikke sant? Det er et sjenerøst anslag for de fleste AI-genererte komponenter. Men se hva som skjer når stegene legger seg oppå hverandre:
- 5 steg: 0.95^5 = 77% pålitelighet
- 10 steg: 0.95^10 = 60% pålitelighet
- 20 steg: 0.95^20 = 36% pålitelighet
Tjue steg, og den «revolusjonerende automatiseringen» din feiler oftere enn den lykkes. Dette er ikke et problem med AI-modellen. Det er et systemkompleksitetsproblem, og ingen mengde bedre prompter fikser det.
Agentene som faktisk fungerer i produksjon? De gjør én kjedelig ting veldig bra. De «navigerer ikke autonomt i komplekse arbeidsflyter» — de leser en faktura eller oppsummerer en e-posttråd. Teamene som konsekvent får ting i mål, avgrenser agenten til å håndtere én komplett delprosess i stedet for å prøve å automatisere en hel arbeidsflyt.
De samme buggene, hver gang
Etter å ha fikset dusinvis av AI-genererte prosjekter ser jeg det samme mønsteret. Dette er ikke tilfeldige bugs. Det er systematiske hull som kommer av måten AI genererer kode på — den bygger for det ideelle scenarioet og overser fullstendig alt som kan gå galt.
Her er listen jeg ser i praktisk talt hvert prosjekt:
- Autentisering som liksom fungerer — til noen bruker en rar e-postleverandør eller prøver å tilbakestille passordet sitt.
- Databasespørringer som fungerer fint med 10 brukere og kollapser fullstendig ved 100. Ingen indekser, ingen normalisering, kundenavn, e-post og telefon duplisert på hver bestilling i stedet for lenkede tabeller.
- Feilhåndtering som bare sier «noe gikk galt» uten noen nyttig info. Betaling feiler? Arbeidsflyten stopper bare. Brukeren vet ikke hva som skjedde, du vet ikke hva som skjedde.
- Null rate limiting — en enkelt ondsinnet aktør kan senke hele greia. Jeg har sett dette flere ganger.
- API-nøkler hardkodet i frontend. Ja, flere ganger. ChatGPT bygde et «vakkert Node.js-API med perfekt feilhåndtering» — bortsett fra at det ikke hadde rate limiting, logget sensitive data og ville ha smeltet under reell trafikk.
- Ingen personvernregler — hver bruker kan se alle andre brukeres data. Row-level security? Finnes ikke.
- Ingen backendlogikk — alt på klientsiden, forretningslogikk eksponert i nettleseren.
- Dupliserte arbeidsflyter — AI legger til samme funksjon to ganger, to arbeidsflyter slåss mot hverandre.
Hver eneste av disse er triviell å fikse hvis du vet at den finnes. Problemet er at AI ikke ser dem, for sett fra AI-en — «fungerer» koden.
Hva AI-verktøy gjør feil
De fleste feilene skyldtes ikke modellen. De skyldtes manglende kontrakter. Ingen klar definisjon av hva agenten har lov til å gjøre, hvordan gyldig output ser ut, eller hvilken tilstand den skal bevare.
Når ting går galt, begynner folk å justere prompter i stedet for å fikse strukturen. Det skjuler bare problemet. En uke senere spytter den ut noe annet, fordi rotårsaken — manglende kontrakter — fortsatt er den samme.
De fleste agentprosjekter er designet rundt hva AI kan gjøre, i stedet for hva arbeidsflyten faktisk trenger fra start til slutt. Det er stikk motsatt av hva man bør gjøre. En solid agent starter med:
- Et klart avgrenset formål — én prosess, ett ansvar.
- Strenge inn-/utdataformater — JSON-skjema, typer, validering. Ikke «jeg burde returnere noe i format X.»
- Klare atferdsregler — hva agenten kan gjøre, hva den ikke kan, hva den gjør når den ikke vet.
Først deretter tenker du på UI og integrasjoner.
Agenter lærer ikke naturlig av feilene sine. De husker ikke engang feilene sine med mindre du bygger det inn. Hver samtale er en isolert boble. Det betyr at hver sesjon starter fra null — de samme feilene, de samme naive antagelsene, de samme manglende edge-casene. Hvis du ikke fanger opp lærdommene fra én sesjon og gir dem videre til den neste, vil AI gjenta de samme problemene i det uendelige.
Gapet mellom demo og produksjon
Fungerer på localhost. Nydelig. Men hva skjer når du kaster det opp på en server?
AI-verktøy er flotte for prototyping, men det er et gap mellom en demo og et ekte produkt. Her er listen over problemer som dukker opp i øyeblikket noen andre enn deg begynner å bruke appen din:
CORS og nettverksproblemer
Frontend på et domene, backend på et annet, ingen riktige headere. Fungerer på localhost fordi nettleseren er tolerant. I produksjon? Feil for hver eneste bruker.
Ytelse under belastning
N+1-databasespørringer, ingen paginering, hele tabeller lastes inn i minnet. Med 5 testposter merker du det ikke. Med 5 000 — siden bruker 30 sekunder på å laste, og serveren spiser alt tilgjengelig RAM.
Tilstands- og sesjonshåndtering
AI tenker ikke på hva som skjer når en bruker åpner to faner, mister tilkoblingen eller kommer tilbake etter en time. Utløper sesjoner? Oppdateres tokenet? Hvem håndterer konfliktløsning? Ingen, fordi AI ikke tenkte på det scenarioet.
Deployment og infrastruktur
Ingen Dockerfile. Ingen miljøvariabler — alt hardkodet. Ingen CI/CD. Ingen helsesjekk. Ingen rollback-strategi. Ingen autoskalering. En server, null redundans. Hvis den går ned — går alt ned.
De fleste dra-og-slipp-plattformer løser tilkobling. Pålitelighet — håndtering av delvise feil, retries, edge cases — er der ting blir rotete i produksjon.
Hvordan faktisk fikse det
Du trenger ikke kaste bort AI-generert kode. Du må herde den. Her er konkrete steg, ikke teori:
1. Sjekk personvernregler og databasestruktur først — de to alene fikser de fleste problemene
Dette er rådet jeg gir alle. Hvis appen din virker skjør, start med disse to. Row-level security (RLS) i Supabase, Postgres-policyer, eller middleware som sjekker om en bruker har rett til å se en gitt post. Deretter databasenormalisering — lenkede tabeller i stedet for data duplisert på hver post.
2. Flytt forretningslogikk til backend
All validering som bare finnes i frontend er en invitasjon til misbruk. Priser, rabatter, tillatelser, grenser — alt på serversiden. Frontend er bare presentasjonslaget. Hvis noen kan åpne DevTools og endre prisen på et produkt — har du et problem.
3. Legg til ekte feilhåndtering med fallbacks og retries
Hvert API-kall kan feile. Hver betaling kan bli avvist. Hver databasetilkobling kan ryke. AI genererer kode som antar at ingenting noensinne går i stykker. Legg til try/catch med meningsfulle meldinger. Legg til retries med exponential backoff. Legg til fallbacks — hvis den primære tjenesten går ned, hva skjer?
4. Sikre nøkler og hemmeligheter
Miljøvariabler, ikke hardkodede strenger. AWS Secrets Manager, Doppler, eller i det minste en .env-fil med korrekt .gitignore. Hvis API-nøkkelen din er i frontend-kode — er den offentlig. Ingen unntak.
5. Bygg en CI/CD-pipeline
GitHub Actions, GitLab CI, Bitbucket Pipelines — spiller ingen rolle hvilken. Det som betyr noe er at hver deploy går gjennom: lint, tester, build, deploy til staging, deretter til produksjon. Null manuelle FTP-opplastinger.
6. Legg til overvåking og varsling fra dag én
Sentry for frontend- og backendfeil. CloudWatch eller Datadog for servermetrikker. Slack- eller e-postvarsler når feilraten overstiger en terskel. Hvis du ikke vet at noe gikk i stykker — er det som om det ikke gikk i stykker. Helt til en kunde forteller deg det.
Produksjonsklar sjekkliste
Gå gjennom dette før hver deploy. Hvert punkt er noe jeg har sett mangle i ekte prosjekter.
- Row-level security / personvernregler. Hver bruker ser bare sine egne data. Test dette ved å logge inn som forskjellige brukere.
- Databasenormalisering + indekser. Lenkede tabeller, ikke dupliserte data. Indekser på kolonner du spør etter.
- Forretningslogikk på serversiden. Priser, rabatter, tillatelser — aldri bare i frontend.
- Feilhåndtering med fallbacks og retries. Hvert eksternt kall har try/catch, en meningsfull melding og en retry-strategi.
- Rate limiting. På innlogging, registrering og API-endepunkter. Beskytt mot brute force og ondsinnet trafikk.
- Hemmelighetsstyring. Null hardkodede nøkler. Miljøvariabler, secrets manager, kryptering av lagrede data.
- CI/CD-pipeline. Automatisert lint, tester, build, deploy. Null manuelle deployments.
- Overvåking og varsling. Sentry, CloudWatch, Datadog — hva som helst. Du må vite at noe gikk i stykker før en kunde forteller deg det.
- HTTPS + sikkerhetsheadere. TLS overalt. HSTS, Content-Security-Policy, X-Frame-Options.
- Inputvalidering. På serveren, ikke bare i frontend. Alle brukerinndata er potensielt ondsinnet.
- Connection pooling. Ikke opprett en ny databasetilkobling per forespørsel. PgBouncer, HikariCP eller en innebygd pool.
- Belastningstesting før lansering. k6, Artillery eller i det minste ab. Vit hvor det ryker før det ryker på en bruker.
Vanlige spørsmål
Er AI-generert kode produksjonsklar?
I seg selv — sjelden. Men det gjør den ikke ubrukelig. Behandle den som en solid prototype som trenger herding. Sjekk personvernregler, legg til feilhåndtering, flytt logikk til backend, legg til overvåking. Basekoden er ofte grei nok — det er produksjonslaget som mangler.
Hvor lang tid tar det å gå fra AI-prototype til produksjon?
Vanligvis 2-6 uker for en standard SaaS-app, avhengig av kompleksitet og antall integrasjoner. Hvis databasen er godt designet fra starten, går det raskere. Hvis den er flat (alle data i en tabell) — mye lenger, fordi du må migrere data.
Er det bedre å fikse AI-generert kode eller skrive om fra bunnen?
Nesten alltid bedre å fikse. Omskriving fra bunnen høres fristende ut, men det tar vanligvis 3-5 ganger lenger enn du forventer og introduserer nye bugs. Unntak: hvis arkitekturen er fundamentalt feil (f.eks. ingen backend i det hele tatt) eller hvis appen er veldig liten (<1 000 kodelinjer).
Hva er det viktigste å sjekke i en AI-generert app?
Tre ting: (1) personvernregler — kan brukere bare se sine egne data, (2) databasestruktur — er den normalisert eller er data duplisert overalt, (3) sikkerhet — er API-nøkler skjult, er forretningslogikken på serveren. Disse tre fikser 80% av problemene.
Trenger jeg DevOps og CI/CD for en MVP?
Ja. Du trenger ikke Kubernetes og 15 mikrotjenester, men en minimal pipeline (lint + tester + automatisert deploy) sparer deg timer og forhindrer «jeg glemte å pushe den nye versjonen.» GitHub Actions er gratis for små prosjekter. Det er ingen grunn til å ikke ha det.
Fungerer AI-appen din i demoen, men ikke i produksjon?
Det er nøyaktig det jeg fikser. La oss snakke — jeg sjekker hva som må herdes og forteller deg hvor lang tid det tar.
Bestill en gratis samtale →