De usynlige buggene i AI-generert kode

Spør en ikke-teknisk gründer som bygget MVP-en sin med et AI-kodeverktøy hvordan det gikk, og du får en versjon av den samme historien: forbløffende raskt først, så stadig rarere. En funksjon som pleide å leveres på en time tar en dag. En kunde rapporterer noe som ikke skulle være mulig. AI-en skriver fortsatt villig vekk mer kode — men hver ny ting den legger til ser ut til å ødelegge noe eldre.

Dette er ikke et argument mot AI-assistert koding. Det er et argument for å forstå hvordan den pleier å feile, slik at du kan oppdage feilene før de finner kundene dine.

Tesen

AI-kodeverktøy skriver vanligvis ikke ødelagt kode. De skriver plausibel kode. Forskjellen viser seg bare under stress: ekte brukere, ekte data, ekte skala, ekte sikkerhet. Da ser koden bra ut — og det er nettopp derfor den tar lengre tid å feilsøke.

Antakelsen det er verdt å utfordre

De fleste gründere, også de som burde vite bedre, antar i det stille:

Hvis den kjører og passerer happy path, fikk AI-en det riktig.

Dette er rimelig i enhver annen kontekst. En kompilatorfeil, en runtime-krasj, en feilende test — dette er ærlige signaler. LLM-generert kode er uærlig på en spesifikk måte: den er trent til å produsere kode som ser ut som kjent god kode, fordi det er det som ligger i treningsdataene. Å se ut som kjent god kode og å være kjent god kode er ikke det samme.

Fem mønstre vi ser igjen og igjen

Dette er problemene som dukker opp når en revisjon lander på en MVP som er bygget primært med AI-hjelp. Ingen av dem er eksotiske. Alle er stille helt til de ikke er det.

1. Autentisering som er nesten riktig

AI-en skriver innlogging, registrering, passord-tilbakestilling, sesjonshåndtering. UX-en ser flott ut. Så et sted midt i flyten mangler det en sjekk — en token som ikke valideres på et kritisk endepunkt, en cookie uten HttpOnly-flagget, en passord-tilbakestilling som ikke ugyldiggjør den gamle sesjonen. Hver av disse er en enlinjefiks isolert. Sammen betyr de at hvem som helst med litt vilje kan utgi seg for å være en annen bruker.

Gründeren vet vanligvis ikke at dette skjer fordi autentiseringen fungerer. Du kan logge inn. Du kan logge ut. Hullet er i det som skjer imellom.

2. Datamodeller som ikke kan utvikle seg

AI-en designer et skjema basert på prompten den fikk. Den prompten beskrev produktet i dag. Skjemaet reflekterer i dag. Når en gründer prøver å legge til "én ting til" en kunde ba om tre måneder senere, viser det seg at den opprinnelige tabellstrukturen antok ting som ikke er sanne lenger — én bruker per konto, ett produkt per bestilling, én valuta, ett språk.

Du kan alltid migrere. Men migreringen, for et live-produkt med data i, er det motsatte av den "totimers AI-funksjonen" gründeren har blitt vant til.

3. Overspesifikk kode som later som den er generell

LLM-er elsker å skrive hjelpefunksjoner. Funksjoner med navn som getUserOrdersByStatusAndDate. De ser gjenbrukbare ut. Det er de ikke — de håndterer bare den nøyaktige kombinasjonen gründeren spurte om. Neste gang noen trenger bestillinger etter status uten etter dato, skriver AI-en enda en nesten identisk funksjon. Etter noen måneder er kodebasen et museum av nesten-duplikater, der hver enkelt er litt forskjellig fra de andre.

Faren her er ikke en krasj. Den er at en fiks i én kopi ikke fikser de andre, og gründeren har ingen mulighet til å vite hvilken kopi som kjører i produksjon for hvilken funksjon.

4. "Defensiv" kode som skjuler bugs

Be en AI om å gjøre koden mer robust og den vil gjerne pakke ting inn i try/except-blokker som stille svelger feil. Feil som burde varsle noen, blir i stedet logget til konsollen — eller verre, ikke logget i det hele tatt. Data som burde utløse en hard stopp, blir stille til null og flyter videre nedover i systemet. Produktet "krasjer aldri". Det forteller deg heller aldri når noe er galt.

5. Tredjeparts-integrasjoner som er holdt sammen med teip

Stripe, SendGrid, Supabase, OpenAI — AI-assistenter er flinke til å lage en første integrasjon. Men retries, idempotens, webhook-verifisering, rate limiting, feilhåndtering når leverandøren er nede — det er disse delene som hoppes over fordi prompten ikke ba om dem. Gründeren finner det ikke ut før den første dobbeltbelastningen, den første mislykkede registrerings-e-posten, eller det første avbruddet som sprer seg gjennom hele produktet fordi én underliggende tjeneste snublet.

Den mulige løsningen: et gjennomgangsmønster, ikke en omskriving

Du trenger ikke skrive om en AI-generert MVP for å gjøre den sikker. Du trenger et gjennomgangsmønster — en kort liste med spørsmål som noen som er teknisk kompetent går gjennom med noen ukers mellomrom, pluss én gang før hver viktig kunde- eller investormilepæl.

En praktisk rytme:

• Ukentlig (15 minutter, du): skum gjennom listen over nye filer og endepunkter. Hvis noe nytt berører auth, betalinger eller kundedata, merk det for en ordentlig gjennomgang før det sendes ut.
• Månedlig (1–2 timer, en spesialist): kjør en sjekkliste-gjennomgang på de fem mønstrene over. Det gir en kort liste med "fiks denne måneden"-punkter, ikke mer.
• Før milepæler (en halv dag, en spesialist): full gjennomgang før en enterprise-demo, sikkerhetsspørreskjema, finansieringsrunde eller første reelle tekniske ansettelse.

Dette er ikke en full revisjon hver gang. Det er en rutine — tilsvarende det å skifte olje på en bil du kjører hver dag. Dropper du den gang på gang, ender du opp med nøyaktig den feilmoden de fleste AI-genererte MVP-er havner i: greit, greit, greit, katastrofe.

Et kort praktisk eksempel

En gründer bygget et B2B-verktøy med en AI-assistent på tre helger. Det fikk fem betalende kunder på seks uker. I uke elleve lastet en av disse kundene — ved et uhell, gjennom et nettleserbokmerke — en annen kundes dashbord. Fiksen var to linjer. Skaden var e-posten gründeren måtte sende.

Gjennomgangen som ville fanget det opp, ville tatt nitti minutter og kostet mindre enn gründerens månedlige kaffebudsjett.

Oppsummering

AI-genererte MVP-er er ikke en dårlig idé. De er en flott måte å nå product-market-signal billig på. Men de feiler i en spesifikk retning: kode som ser plausibel ut, men som ryker under reelle forhold. Kostnaden for en lett, planlagt gjennomgang er triviell. Kostnaden for den første unngåelige hendelsen er det ikke.

Hvis du har bygget MVP-en din primært med AI-hjelp, er det aller mest verdifulle du kan gjøre denne måneden å få noen som ikke er AI-en — og ikke deg — til å lese den.