Vad som faktiskt går fel inuti MVP:er som "bara fungerade" på dag ett.
Fråga en icke-teknisk grundare som byggde sin MVP med ett AI-kodningsverktyg hur det gick, och du får någon version av samma berättelse: häpnadsväckande snabbt först, sedan allt konstigare. En funktion som tidigare levererades på en timme tar en dag. En kund rapporterar något som inte borde vara möjligt. AI:n skriver fortfarande gärna mer kod — men varje ny sak den lägger till verkar bryta något äldre.
Det här är inte ett argument mot AI-assisterad kodning. Det är ett argument för att förstå hur den tenderar att misslyckas, så du kan upptäcka felen innan de hittar dina kunder.
AI-kodningsverktyg skriver vanligtvis inte trasig kod. De skriver plausibel kod. Skillnaden visar sig bara under stress: riktiga användare, riktig data, riktig skala, riktig säkerhet. Då ser koden fin ut — vilket är precis därför felsökning tar längre tid.
De flesta grundare, inklusive de som borde veta bättre, antar tyst:
Om den körs och passerar happy path, fick AI:n det rätt.
Detta är rimligt i alla andra sammanhang. Ett kompilatorfel, en runtime-krasch, ett misslyckat test — dessa är ärliga signaler. LLM-genererad kod är oärlig på ett specifikt sätt: den är tränad att producera output som ser ut som känt bra kod, eftersom det är vad som finns i dess träningsdata. Att se ut som känt bra kod och att vara känt bra kod är inte samma sak.
Det här är problemen som dyker upp när en granskning landar på en MVP som byggts främst med AI-hjälp. Inga av dem är exotiska. Alla är tysta tills de inte är det.
AI:n skriver inloggning, registrering, lösenordsåterställning, sessionshantering. UX:en ser bra ut. Sedan någonstans mitt i flödet saknas en kontroll — en token som inte valideras på en kritisk endpoint, en cookie utan HttpOnly-flaggan, en lösenordsåterställning som inte ogiltigförklarar den gamla sessionen. Var och en av dessa är en enradsfix i isolation. Tillsammans innebär de att vem som helst som vill kan utge sig för att vara en användare.
Grundaren vet vanligtvis inte att detta händer eftersom autentiseringen fungerar. Du kan logga in. Du kan logga ut. Hålet är i vad som händer däremellan.
AI:n designar ett schema baserat på prompten den fick. Den prompten beskrev produkten idag. Schemat reflekterar idag. När en grundare försöker lägga till "en sak till" som en kund bad om tre månader in, visar det sig att den ursprungliga tabellstrukturen antog saker som inte längre är sanna — en användare per konto, en produkt per beställning, en valuta, ett språk.
Du kan alltid migrera. Men migreringen, för en live-produkt med data i, är motsatsen till den "tvåtimmars AI-funktion" grundaren vant sig vid.
LLM:er älskar att skriva hjälpfunktioner. Funktioner med namn som getUserOrdersByStatusAndDate. De ser återanvändbara ut. Det är de inte — de hanterar bara den exakta kombination grundaren frågade om. Nästa gång någon behöver orders efter status utan efter datum, skriver AI:n en andra nästan-identisk funktion. Efter några månader är kodbasen ett museum av nära-dubbletter, var och en subtilt olika.
Buggytan här är inte en krasch. Det är att en fix till en kopia inte fixar de andra, och grundaren har inget sätt att veta vilken kopia som körs i produktion för vilken funktion.
Be en AI att göra koden mer robust och den kommer gärna slå in saker i try/except-block som sväljer fel tyst. Fel som borde varna någon loggas istället till konsolen — eller värre, loggas inte alls. Data som borde orsaka ett hårt stopp blir tyst null och flödar nedåt. Produkten "kraschar aldrig". Den berättar också aldrig för dig när något är fel.
Stripe, SendGrid, Supabase, OpenAI — AI-assistenter är bra på att skapa en första integration. Men retries, idempotens, webhook-verifiering, rate limiting, felhantering när leverantören är nere — det är de delar som hoppas över eftersom prompten inte bad om dem. Grundaren får reda på det först vid den första dubbeldebiteringen, det första missade registreringsmejlet, eller det första avbrottet som kaskader genom produkten eftersom en uppströmstjänst stötte på problem.
Du behöver inte skriva om en AI-genererad MVP för att göra den säker. Du behöver ett granskningsmönster — en kort lista frågor som någon tekniskt kompetent går igenom varannan vecka, plus en gång före varje betydande kund- eller investeringsmilstolpe.
Ett praktiskt tempo:
Detta är inte en full granskning varje gång. Det är en rutin — motsvarigheten till att byta olja på en bil du kör varje dag. Rutinmässigt överhoppad producerar den exakt den felmod de flesta AI-genererade MVP:er hamnar i: bra, bra, bra, katastrof.
En grundare byggde ett B2B-verktyg med en AI-assistent på tre helger. Det fick fem betalande kunder på sex veckor. På vecka elva laddade en av dessa kunder — av misstag, via ett webbläsarbokmärke — en annan kunds dashboard. Fixet var två rader. Skadan var mejlet grundaren var tvungen att skicka.
Granskningen som skulle ha fångat det skulle ha tagit nittio minuter och kostat mindre än grundarens månadsbudget för kaffe.
AI-genererade MVP:er är inte en dålig idé. De är ett bra sätt att nå product-market-signal billigt. Men de misslyckas i en specifik riktning: plausibelt utseende kod som går sönder under verkliga förhållanden. Kostnaden för en lätt, schemalagd granskning är trivial. Kostnaden för den första undvikbara incidenten är det inte.
Om du byggt din MVP främst med AI-hjälp är det enskilt mest värdefulla du kan göra denna månad att låta någon som inte är AI:n — och inte du — läsa den.
Introduktionssamtalet är gratis. 30 minuter. Jag säger dig ärligt om en granskning eller räddning passar din situation — eller om ingen av dem gör det.
Boka ett introduktionssamtal →