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 10 år. 60+ no-code- og AI-genererte prosjekter levert, de fleste av dem redningsaksjoner — grundere som bygde det selv eller lot AI generere hele greia, og så kom til meg med samme problem: «Det fungerte på demoen, men det faller fra hverandre i produksjon.»
Her er det folk tar feil. De ser en 90%-løsning på et komplekst problem og tror det er 90% av jobben. Det er vanligvis høyest 50%. Sannsynligvis mindre. Fordi det ikke er samme type arbeid. De første 80% er prototypen. De siste 20% er ingeniørfag — sikkerhet, feilhåndtering, skalerbarhet, testing, deployment, monitorering. Alt det som gjør at appen overlever møtet med ekte brukere.
Det finnes en rar kultur med «jeg shippa det på en helg»-innlegg som fullstendig hopper over delen der du faktisk må herde applikasjonen før ekte mennesker bruker den. Ingen snakker om HTTPS-konfigurasjon, sikkerhetsheadere, eller hva som skjer når to prosesser prøver å skrive til samme post. Men det er nøyaktig der de virkelige problemene bor.
Denne artikkelen handler om den delen. Om de spesifikke feilmønstrene jeg ser i hvert AI-generert prosjekt, og hvordan fikse dem — steg for steg, uten teori.
Før vi går inn på spesifikke bugs, la oss snakke om matematikken. For det er her illusjonen av 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 estimat for de fleste AI-genererte komponenter. Men se hva som skjer når stegene akkumuleres:
Tjue steg og den «revolusjonerende automatiseringen» din feiler oftere enn den lykkes. Dette er ikke et AI-modellproblem. Det er et systemkompleksitetsproblem, og ingen mengde bedre prompter vil fikse det.
Agentene som faktisk fungerer i produksjon? De gjør en kjedelig ting veldig bra. De «navigerer ikke autonomt komplekse arbeidsflyter» — de parser en faktura eller oppsummerer en e-posttråd. Teamene som konsekvent lukker sirkelen, begrenser agenten til å eie en komplett delprosess i stedet for å prøve å automatisere en hel arbeidsflyt.
Den virkelige flaskehalsen er ikke lenger AI-modellen. Det er gapet mellom å tenke og å gjøre. En god agent må faktisk utføre oppgaver fra start til slutt, ikke bare generere tekst.
Etter å ha fikset titalls AI-genererte prosjekter ser jeg det samme mønsteret. Dette er ikke tilfeldige bugs. De er systematiske mangler som kommer fra måten AI genererer kode på — den bygger den lykkelige stien og ignorerer fullstendig alt som kan gå galt.
Her er listen jeg ser i praktisk talt hvert prosjekt:
Hver eneste av disse er triviell å fikse hvis du vet at den finnes. Problemet er at AI ikke ser dem, fordi fra AIs perspektiv — «fungerer» koden.
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 nøyaktig baklengs. En solid agent starter med:
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ærdomiene fra en sesjon og mater dem til neste, vil AI gjenta de samme problemene i det uendelige.
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:
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.
N+1-databasesporringer, ingen paginering, lasting av hele tabeller i minnet. Med 5 testposter merker du det ikke. Med 5 000 — siden bruker 30 sekunder på å laste, og serveren spiser alt tilgjengelig RAM.
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.
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.
Du trenger ikke kaste bort AI-generert kode. Du må herde den. Her er konkrete steg, ikke teori:
Dette er rådet jeg gir alle. Hvis appen din føler seg 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.
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.
Hvert API-kall kan feile. Hver betaling kan bli avvist. Hver databasetilkobling kan falle. 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?
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.
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.
Sentry for frontend- og backendfeil. CloudWatch eller Datadog for servermetrikker. Slack- eller e-postvarsler når feilraten overskrider en terskel. Hvis du ikke vet at noe gikk i stykker — er det som om det ikke gikk i stykker. Til en kunde forteller deg det.
Når ting går galt, begynner folk å justere prompter i stedet for å fikse strukturen. Det er som å male et hus med sprukket fundament. Det ser bedre ut i en uke. Så kommer sprekkene tilbake.
Gå gjennom dette før hver deploy. Hvert punkt er noe jeg har sett mangle i ekte prosjekter.
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 →