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 gjerne 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 — som er akkurat hvorfor feilsøking tar lengre tid.

Antakelsen det er verdt å utfordre

De fleste gründere, inkludert de som burde vite bedre, antar 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 output som ser ut som kjent god kode, fordi det er det som er i treningsdataene dens. Å 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 enhver bestemt person kan utgi seg for å være en 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 vente seg 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 en andre nesten-identisk funksjon. Etter noen måneder er kodebasen et museum av nær-duplikater, hver subtilt forskjellig.

Feiloverflaten her er ikke en krasj. Det er at en fiks til én kopi ikke fikser de andre, og gründeren har ingen måte å 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 logget til konsollen — eller verre, ikke logget i det hele tatt. Data som burde forårsake en hard stopp blir stille null og flyter nedstrøms. Produktet "krasjer aldri". Det forteller deg heller aldri når noe er galt.

5. Tredjeparts-integrasjoner som henger sammen med snor

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 kaskaderer gjennom produktet fordi én oppstrøms-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 teknisk kompetent går gjennom med noen ukers mellomrom, pluss én gang før hver betydelig kunde- eller investormilepæl.

En praktisk rytme:

• Ukentlig (15 minutter, du): skum 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. Produserer 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 — tilsvaret av å skifte olje på en bil du kjører hver dag. Rutinmessig hoppet over produserer den nøyaktig den feilmoden de fleste AI-genererte MVP-er ender opp 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 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 å komme til product-market-signal billig. Men de feiler i en spesifikk retning: plausibelt utseende kode som går i stykker 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 enkeltmest verdifulle du kan gjøre denne måneden å få noen som ikke er AI-en — og ikke deg — til å lese den.