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 förr tog en timme att få klar tar nu en dag. En kund rapporterar något som inte borde vara möjligt. AI:n skriver fortfarande gärna mer kod — men varje ny grej den lägger till verkar ställa till med något i det som redan fanns.
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 först under press: riktiga användare, riktiga datamängder, riktig skala, riktiga säkerhetskrav. Då ser koden fin ut — vilket är precis därför felsökning tar längre tid.
De flesta grundare, även de som borde veta bättre, utgår i det tysta ifrån:
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 kod som ser ut som kod man vet fungerar, eftersom det är vad som finns i dess träningsdata. Men att se ut som kod som fungerar och att faktiskt fungera är inte samma sak.
Det här är problemen som dyker upp när vi granskar en MVP som byggts främst med AI-hjälp. Inget av dem är exotiskt. 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 dem är en enradsfix var för sig. Tillsammans innebär de att vem som helst som verkligen vill kan utge sig för att vara en annan 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 tre månader senare försöker lägga till "en grej till" som en kund efterfrågat, visar det sig att den ursprungliga tabellstrukturen byggde på antaganden som inte längre stämmer — en användare per konto, en produkt per beställning, en valuta, ett språk.
Du kan alltid migrera. Men för en produkt i drift med riktig data i sig är migreringen raka motsatsen till den "tvåtimmars AI-funktion" som 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 ytterligare en nästan identisk funktion. Efter några månader är kodbasen ett museum av nästan identiska dubbletter, var och en med små skillnader.
Problemet här visar sig inte som en krasch. Det är att en fix i 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, så slår den gärna in saker i try/except-block som sväljer fel i tysthet. Fel som borde varna någon loggas istället till konsolen — eller värre, loggas inte alls. Data som borde tvinga fram ett tvärstopp blir i tysthet null och flödar vidare nedströms. 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 sprider sig genom hela produkten för att en tjänst de är beroende av hickade till.
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 med frågor som någon tekniskt kunnig går igenom med några veckors mellanrum, 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. Hoppar du över den gång på gång får du exakt den felmod som 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 som 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 billigt nå en första signal om product-market fit. Men de misslyckas i en bestämd riktning: kod som ser trovärdig ut men 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 ärligt till dig om en granskning eller räddning passar din situation — eller om ingen av dem gör det.
Boka ett introduktionssamtal →