AI tar dig till 80% snabbt. Men de sista 20% är där all riktig ingenjörskonst bor — och där de flesta projekt dör.
Jag har byggt applikationer i över 10 år. 60+ no-code- och AI-genererade projekt levererade, de flesta av dem räddningsaktioner — grundare som byggt det själva eller lät AI generera alltihop, och sedan kom till mig med samma problem: ”Det fungerade på demon, men det faller ihop i produktion.”
Här är vad folk gör fel. De ser en 90-procentig lösning på ett komplext problem och tror att det är 90% av arbetet. Det är vanligtvis högst 50%. Troligen mindre. För det är inte samma sorts arbete. De första 80% är prototypen. De sista 20% är ingenjörskonst — säkerhet, felhantering, skalbarhet, testning, driftsättning, övervakning. Allt det som gör att appen överlever mötet med riktiga användare.
Det finns en konstig kultur av ”jag skeppade det på en helg”-inlägg som helt hoppar över delen där du faktiskt måste härda applikationen innan riktiga människor använder den. Ingen pratar om HTTPS-konfiguration, säkerhetsheaders, eller vad som händer när två processer försöker skriva till samma post. Men det är precis där de riktiga problemen bor.
Den här artikeln handlar om den delen. Om de specifika felmönster jag ser i varje AI-genererat projekt, och hur man fixar dem — steg för steg, utan teori.
Innan vi går in på specifika buggar, låt oss prata om matematiken. För det är här illusionen av AI-genererade appar faller samman.
Säg att varje steg i ditt agent-arbetsflöde har 95% noggrannhet. Låter bra, eller hur? Det är en generös uppskattning för de flesta AI-genererade komponenter. Men titta vad som händer när stegen ackumuleras:
Tjugo steg och din ”revolutionerande automatisering” misslyckas oftare än den lyckas. Det här är inte ett AI-modellproblem. Det är ett systemkomplexitetsproblem, och inga bättre prompter kommer att lösa det.
Agenterna som faktiskt fungerar i produktion? De gör en tråkig sak riktigt bra. De ”navigerar inte autonomt komplexa arbetsflöden” — de parsar en faktura eller sammanfattar en e-posttråd. Teamen som konsekvent sluter loopen begränsar agenten till att äga en komplett delprocess istället för att försöka automatisera ett helt arbetsflöde.
Den verkliga flaskhalsen är inte längre AI-modellen. Det är gapet mellan att tänka och att göra. En bra agent måste faktiskt utföra uppgifter från början till slut, inte bara generera text.
Efter att ha fixat dussinvis av AI-genererade projekt ser jag samma mönster. Det här är inte slumpmässiga buggar. De är systematiska brister som kommer från hur AI genererar kod — den bygger den lyckliga vägen och ignorerar helt allt som kan gå fel.
Här är listan jag ser i praktiskt taget varje projekt:
Var och en av dessa är trivial att fixa om du vet att den finns. Problemet är att AI inte ser dem, för ur AI:s perspektiv — ”fungerar” koden.
De flesta misslyckanden berodde inte på modellen. De berodde på saknade kontrakt. Ingen tydlig definition av vad agenten får göra, hur giltig output ser ut, eller vilken status den ska bevara.
När saker går fel börjar folk justera prompter istället för att fixa strukturen. Det döljer bara problemet. En vecka senare spottar den ut något annat, för grundorsaken — saknade kontrakt — är fortfarande densamma.
De flesta agentprojekt designas kring vad AI kan göra snarare än vad arbetsflödet faktiskt behöver från början till slut. Det är precis bakvant. En solid agent börjar med:
Först därefter tänker du på UI och integrationer.
Agenter lär sig inte naturligt av sina misstag. De minns inte ens sina misstag om du inte bygger in det. Varje konversation är en isolerad bubbla. Det betyder att varje session börjar från noll — samma fel, samma naiva antaganden, samma saknade kantfall. Om du inte fångar lärdomarna från en session och matar dem till nästa, kommer AI att upprepa samma problem i det oändliga.
Fungerar på localhost. Underbart. Men vad händer när du kastar upp det på en server?
AI-verktyg är bra för prototyper, men det finns ett gap mellan en demo och en riktig produkt. Här är listan över problem som dyker upp i samma ögonblick någon annan än du börjar använda din app:
Frontend på en domän, backend på en annan, inga korrekta headers. Fungerar på localhost för att webbläsaren är tolerant. I produktion? Fel för varje enskild användare.
N+1-databasförfrågan, ingen paginering, laddar hela tabeller i minnet. Med 5 testposter märker du det inte. Med 5 000 — sidan tar 30 sekunder att ladda och servern äter allt tillgängligt RAM.
AI tänker inte på vad som händer när en användare öppnar två flikar, förlorar uppkopplingen eller kommer tillbaka efter en timme. Går sessioner ut? Uppdateras token? Vem hanterar konfliktlösning? Ingen, för AI tänkte inte på det scenariot.
Ingen Dockerfile. Inga miljövariabler — allt hårdkodat. Ingen CI/CD. Ingen hälsocheck. Ingen rollback-strategi. Ingen autoskalning. En server, noll redundans. Om den går ner — går allt ner.
De flesta dra-och-släpp-plattformar löser uppkoppling. Tillförlitlighet — hantering av partiella fel, omförsök, kantfall — är där det blir rörigt i produktion.
Du behöver inte kasta bort AI-genererad kod. Du behöver härda den. Här är konkreta steg, inte teori:
Det är rådet jag ger alla. Om din app känns bräcklig, börja med dessa två. Radnivåsäkerhet (RLS) i Supabase, Postgres-policyer, eller middleware som kontrollerar om en användare har rätt att se en viss post. Sedan databasnormalisering — länkade tabeller istället för data duplicerad på varje post.
All validering som bara finns i frontend är en inbjudan till missbruk. Priser, rabatter, behörigheter, gränser — allt på serversidan. Frontend är bara presentationslagret. Om någon kan öppna DevTools och ändra priset på en produkt — har du ett problem.
Varje API-anrop kan misslyckas. Varje betalning kan avvisas. Varje databasanslutning kan brytas. AI genererar kod som antar att ingenting någonsin går sönder. Lägg till try/catch med meningsfulla meddelanden. Lägg till omförsök med exponential backoff. Lägg till fallbacks — om den primära tjänsten går ner, vad händer?
Miljövariabler, inte hårdkodade strängar. AWS Secrets Manager, Doppler, eller åtminstone en .env-fil med korrekt .gitignore. Om din API-nyckel finns i frontend-koden — är den offentlig. Inga undantag.
GitHub Actions, GitLab CI, Bitbucket Pipelines — spelar ingen roll vilken. Det som spelar roll är att varje deploy går igenom: lint, tester, build, deploy till staging, sedan till produktion. Noll manuella FTP-uppladdningar.
Sentry för frontend- och backend-fel. CloudWatch eller Datadog för servermetriker. Slack- eller e-postlarm när felfrekvensen överskrider ett tröskelvärde. Om du inte vet att något gick sönder — är det som om det inte gick sönder. Tills en kund berättar för dig.
När saker går fel börjar folk justera prompter istället för att fixa strukturen. Det är som att måla ett hus med sprucken grund. Det ser bättre ut i en vecka. Sedan kommer sprickorna tillbaka.
Gå igenom detta före varje deploy. Varje punkt är något jag sett saknas i riktiga projekt.
Det är precis det jag fixar. Låt oss prata — jag kollar vad som behöver härdas och berättar hur lång tid det tar.
Boka ett gratis samtal →