AI doprowadzi Cię do 80% w rekordowym tempie. Ale te ostatnie 20% to miejsce, gdzie mieszka prawdziwa inżynieria — i gdzie większość projektów umiera.
AI gets you to 80% fast. But that last 20% is where all the actual engineering lives — and where most projects die.
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.
AI tar deg til 80% raskt. Men de siste 20% er der all ekte ingeniørkunst bor — og der de fleste prosjektene dør.
Budujemy aplikacje od ponad 10 lat. Ponad 60 projektów no-code i AI-generated — większość z nich to były akcje ratunkowe. Founderzy, którzy sami to zbudowali albo pozwolili AI wygenerować całość, przychodzili z tym samym problemem: „Działało na demo, ale na produkcji się sypie.”
I tu jest sedno sprawy. Ludzie widzą 90-procentowe rozwiązanie złożonego problemu i myślą, że to 90% roboty. W rzeczywistości to najwyżej połowa. Pewnie nawet mniej. Bo to nie jest ten sam rodzaj pracy. Te pierwsze 80% to prototyp. Te ostatnie 20% to inżynieria — bezpieczeństwo, obsługa błędów, skalowalność, testy, deployment, monitoring. Wszystko to, co sprawia, że aplikacja przeżywa spotkanie z prawdziwym użytkownikiem.
Jest taka dziwna kultura postów „wysłałem to w weekend”, która całkowicie pomija część, w której musisz to zahartować, zanim prawdziwi ludzie zaczną tego używać. Nikt nie mówi o konfiguracji HTTPS, o zabezpieczeniach, o tym co się dzieje, kiedy dwa procesy próbują zapisać ten sam rekord. A to właśnie tam żyją prawdziwe problemy.
Ten artykuł jest o tej części. O konkretnych wzorcach awarii, które widzę w każdym AI-generowanym projekcie, i o tym, jak je naprawić — krok po kroku, bez teorii.
I've been building apps for over 10 years. 60+ no-code and AI-generated projects shipped, most of them rescues — founders who built it themselves or had AI generate the whole thing, then came to me with the same problem: "It worked on the demo, but it's falling apart in production."
Here's the thing people get wrong. They see a 90% solution to a complex problem and think that's 90% of the work. It's usually at best 50%. Probably less. Because it's not the same kind of work. That first 80% is the prototype. That last 20% is engineering — security, error handling, scalability, testing, deployment, monitoring. Everything that makes the app survive contact with real users.
There's this weird culture of "I shipped it in a weekend" posts that completely skip the part where you need to actually harden it before real people use it. Nobody talks about HTTPS configuration, security headers, or what happens when two processes try to write the same record. But that's exactly where the real problems live.
This article is about that part. About the specific failure patterns I see in every AI-generated project, and how to fix them — step by step, no theory.
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.
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.
Zanim przejdziemy do konkretnych bugów, porozmawiajmy o matematyce. Bo to tutaj iluzja AI-generowanych aplikacji się rozpada.
Załóżmy, że każdy krok w Twoim workflow ma 95% dokładności. Brzmi dobrze, prawda? To jest naprawdę hojna ocena dla większości AI-generowanych komponentów. Ale popatrzmy, co się dzieje, kiedy te kroki się składają:
Dwadzieścia kroków i Twoja „rewolucyjna automatyzacja” zawodzi częściej niż się udaje. To nie jest problem modelu AI. To jest problem złożoności systemu, i żadna ilość lepszych promptów tego nie naprawi.
Agenty, które faktycznie działają w produkcji? Robią jedną nudną rzecz naprawdę dobrze. Nie „autonomicznie nawigują złożonych workflowów” — parsują fakturę albo podsumowują wątek e-maili. Zespoły, które zamykają pętlę konsekwentnie, ograniczają agenta do jednego pełnego podprocesu zamiast próbować automatyzować cały workflow.
Before we get into specific bugs, let's talk about the math. Because this is where the illusion of AI-generated apps falls apart.
Say each step in your agent workflow has 95% accuracy. Sounds good, right? That's a generous estimate for most AI-generated components. But watch what happens when those steps compound:
Twenty steps and your "revolutionary automation" fails more than it succeeds. This isn't an AI model problem. This is a system complexity problem, and no amount of better prompts will fix it.
The agents that actually work in production? They do one boring thing really well. They don't "autonomously navigate complex workflows" — they parse an invoice, or summarize an email thread. The teams that close the loop consistently scope the agent to own one complete subprocess rather than trying to automate an entire workflow.
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.
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.
Prawdziwym wąskim gardłem nie jest już model AI. To jest przepaść między myśleniem a działaniem. Dobry agent musi faktycznie wykonywać zadania od początku do końca, a nie tylko generować tekst.
The real bottleneck isn't the AI model anymore. It's the gap between thinking and doing. A good agent needs to actually execute tasks end-to-end, not just output text.
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.
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.
Po naprawieniu dziesiątek AI-generowanych projektów widzę ten sam wzorzec. To nie są losowe bugi. To są systemowe braki, które wynikają z tego, jak AI generuje kod — działa na szczęśliwą ścieżkę i kompletnie ignoruje wszystko, co może pójść nie tak.
Oto lista, którą widzę praktycznie w każdym projekcie:
Każdy z tych problemów jest trywialny do naprawienia, jeśli wiesz, że istnieje. Problem w tym, że AI ich nie widzi, bo z perspektywy AI — kod „dziala”.
After fixing dozens of AI-generated projects, I see the same pattern. These aren't random bugs. They're systematic gaps that come from how AI generates code — it builds the happy path and completely ignores everything that can go wrong.
Here's the list I see in virtually every project:
Every single one of these is trivial to fix if you know it exists. The problem is that AI doesn't see them, because from AI's perspective — the code "works."
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.
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.
Większości awarii nie powodował model. Powodowały je brakujące kontrakty. Brak jasnej definicji tego, co agent ma prawo robić, jak wygląda poprawny output i jaki stan ma zachowywać.
Kiedy coś idzie nie tak, ludzie zaczynają poprawiać prompty zamiast naprawiać strukturę. To tylko maskuje problem. Tydzień później wypluwa coś innego, bo podstawowy problem — brak kontraktów — jest nadal taki sam.
Większość projektów agentowych jest projektowana wokół tego, co AI potrafi zrobić, a nie tego, czego workflow faktycznie potrzebuje od początku do końca. To jest dokładnie odwrotnie. Solidny agent zaczyna od:
Dopiero potem myślisz o UI i integracjach.
Agenty nie uczą się na własnych błędach. Nawet ich nie pamiętają, chyba że to wbudujesz. Każda konwersacja to izolowany bąbek. To znaczy, że każda sesja zaczyna się od zera — te same błędy, te same naiwne założenia, te same brakujące edge case'y. Jeśli nie zapiszesz lekcji z jednej sesji i nie przekażesz ich następnej, AI będzie powtarzać te same problemy w nieskończoność.
Most failures were not model issues. They were missing contracts. No clear definition of what the agent is allowed to do, what valid output looks like, or what state it's supposed to preserve.
When things go wrong, people start tweaking prompts instead of fixing the structure. That just hides the problem. A week later it spits out something else, because the root cause — missing contracts — is still the same.
Most agent projects are designed around what the AI can do rather than what the workflow actually needs end-to-end. That's exactly backwards. A solid agent starts with:
Only then do you think about UI and integrations.
Agents don't naturally learn from their mistakes. They don't even remember their mistakes unless you build that in. Every conversation is an isolated bubble. That means every session starts from zero — the same errors, the same naive assumptions, the same missing edge cases. If you don't capture the lessons from one session and feed them to the next, AI will repeat the same problems indefinitely.
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.
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.
Działa na localhost. Pięknie. Ale co się dzieje, kiedy wrzucisz to na serwer?
AI narzędzia są świetne do prototypowania, ale istnieje przepaść między demo a prawdziwym produktem. To jest lista problemów, które pojawiają się w momencie, kiedy ktoś inny niż Ty zaczyna używać Twojej aplikacji:
Frontend na jednej domenie, backend na drugiej, brak odpowiednich headerów. Na localhost działa, bo przeglądarka odpuszcza. Na produkcji? Błąd na każdym użytkowniku.
Zapytania N+1 do bazy danych, brak paginacji, ładowanie całej tabeli do pamięci. Przy 5 rekordach testowych tego nie zauważyć. Przy 5000 — strona ładuje się 30 sekund, a serwer zjada cały RAM.
AI nie myśli o tym, co się dzieje, kiedy użytkownik otwiera dwie karty, traci połączenie albo wraca po godzinie. Sesje wygasają? Token się odświeża? Kto obsługuje conflict resolution? Nikt, bo AI nie pomyślało o tym scenariuszu.
Brak Dockerfile. Brak zmiennych środowiskowych — wszystko zahardkodowane. Brak CI/CD. Brak health checka. Brak strategii rollbacku. Brak autoskalowania. Jeden serwer, zero redundancji. Jeśli padnie — padnie wszystko.
Większość drag-and-drop platform rozwiązuje łączność. Niezawodność — obsługa częściowych awarii, retry'e, edge case'y — to jest miejsce, gdzie robi się bałagan na produkcji.
Works on localhost. Beautiful. But what happens when you throw it on a server?
AI tools are great for prototyping, but there's a gap between a demo and a real product. Here's the list of problems that surface the moment someone other than you starts using your app:
Frontend on one domain, backend on another, no proper headers. Works on localhost because the browser is lenient. In production? Error for every single user.
N+1 database queries, no pagination, loading entire tables into memory. With 5 test records you don't notice. With 5,000 — the page takes 30 seconds to load and the server eats all available RAM.
AI doesn't think about what happens when a user opens two tabs, loses connectivity, or comes back after an hour. Do sessions expire? Does the token refresh? Who handles conflict resolution? Nobody, because AI didn't think about that scenario.
No Dockerfile. No environment variables — everything hardcoded. No CI/CD. No health check. No rollback strategy. No autoscaling. One server, zero redundancy. If it goes down — everything goes down.
Most drag-and-drop platforms solve connectivity. Reliability — handling partial failures, retries, edge cases — is where things get messy in production.
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.
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.
Nie musisz wyrzucać AI-generowanego kodu. Musisz go wzmocnić. Oto konkretne kroki, nie teoria:
To jest rada, którą daję każdemu. Jeśli Twoja aplikacja wydaje się krucha, zacznij od tych dwóch. Row-level security (RLS) w Supabase, Postgres policies, albo middleware sprawdzający, czy użytkownik ma prawo widzieć dany rekord. Potem normalizacja bazy — linkowane tabele zamiast danych powielonych na każdym rekordzie.
Każda walidacja, która jest tylko we frontendzie, to zaproszenie do nadużywania. Ceny, rabaty, uprawnienia, limity — wszystko po stronie serwera. Frontend to tylko warstwa prezentacji. Jeśli ktoś może otworzyć DevTools i zmienić cenę produktu — masz problem.
Każde API call może się nie udać. Każda płatność może zostać odrzucona. Każde połączenie z bazą danych może się zerwać. AI generuje kod, który zakłada, że nic nigdy się nie psuje. Dodaj try/catch z sensownymi komunikatami. Dodaj retry z exponential backoff. Dodaj fallbacki — jeśli główna usługa padnie, co się dzieje?
Zmienne środowiskowe, nie zahardkodowane stringi. AWS Secrets Manager, Doppler, albo chociaż .env z prawidłowym .gitignore. Jeśli Twój klucz API jest w kodzie frontendowym — jest publiczny. Nie ma wyjątków.
GitHub Actions, GitLab CI, Bitbucket Pipelines — nie ma znaczenia które. Ważne, że każdy deploy przechodzi przez: lint, testy, build, deploy na staging, potem na produkcję. Zero ręcznego wrzucania plików przez FTP.
Sentry na błędy frontendowe i backendowe. CloudWatch albo Datadog na metryki serwerowe. Alerty na Slacku albo e-mailu, kiedy error rate przekroczy próg. Jeśli nie wiesz, że coś się popsuło — to tak, jakby się nie popsuło. Do momentu, aż klient Ci powie.
You don't need to throw away AI-generated code. You need to harden it. Here are concrete steps, not theory:
This is the advice I give everyone. If your app feels fragile, start with these two. Row-level security (RLS) in Supabase, Postgres policies, or middleware that checks whether a user has the right to see a given record. Then database normalization — linked tables instead of data duplicated on every record.
Any validation that's only in the frontend is an invitation to abuse. Prices, discounts, permissions, limits — all server-side. The frontend is just the presentation layer. If someone can open DevTools and change a product price — you have a problem.
Every API call can fail. Every payment can be declined. Every database connection can drop. AI generates code that assumes nothing ever breaks. Add try/catch with meaningful messages. Add retries with exponential backoff. Add fallbacks — if the primary service goes down, what happens?
Environment variables, not hardcoded strings. AWS Secrets Manager, Doppler, or at minimum an .env file with a proper .gitignore. If your API key is in frontend code — it's public. No exceptions.
GitHub Actions, GitLab CI, Bitbucket Pipelines — doesn't matter which. What matters is that every deploy goes through: lint, tests, build, deploy to staging, then to production. Zero manual FTP uploads.
Sentry for frontend and backend errors. CloudWatch or Datadog for server metrics. Slack or email alerts when error rate exceeds a threshold. If you don't know something broke — it's as if it didn't break. Until a customer tells you.
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.
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.
Kiedy coś idzie nie tak, ludzie zaczynają poprawiać prompty zamiast naprawiać strukturę. To jak malowanie domu, który ma pęknięty fundament. Wygląda lepiej przez tydzień. Potem pęknięcia wracają.
When things go wrong, people start tweaking prompts instead of fixing the structure. That's like painting a house with a cracked foundation. It looks better for a week. Then the cracks come back.
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.
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.
Przejdź przez to przed każdym deployem. Każdy punkt to coś, co widziałem brakującego w prawdziwych projektach. Go through this before every deploy. Every item is something I've seen missing in real projects. Gå igenom detta före varje deploy. Varje punkt är något jag sett saknas i riktiga projekt. Gå gjennom dette før hver deploy. Hvert punkt er noe jeg har sett mangle i ekte prosjekter.
To dokładnie to, co naprawiam. Porozmawiajmy — sprawdzę, co trzeba wzmocnić, i powiem Ci, ile to zajmie. That's exactly what I fix. Let's talk — I'll check what needs hardening and tell you how long it will take. 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. Det er nøyaktig det jeg fikser. La oss snakke — jeg sjekker hva som må herdes og forteller deg hvor lang tid det tar.
Zarezerwuj bezpłatną rozmowę → Book a free call → Boka ett gratis samtal → Bestill en gratis samtale →