Läsbar AI-kod räcker inte när produktbesluten saknas

Utvecklaren Yves Habchy fick fem veckor på sig att göra en utbildningsapp produktionsklar. Appen hade byggts i Lovable under ungefär ett halvår och gick att exportera som vanlig React- och Supabase-kod.

Koden gick att läsa. Problemet var att ingen längre kunde avgöra varför centrala delar fungerade som de gjorde.

I en öppen förstahandsessä beskriver Habchy övertagandet. Kunden är anonymiserad, koden är inte publicerad och Debrief har inte granskat systemet. Fallet ska därför läsas som en erfarenhet från en utvecklare, inte som ett generellt test av Lovable.

Säkerhetsbristerna gick att hitta

Habchy började med att få den exporterade appen att köra mot en ny Supabase-miljö. Där mötte han 132 migreringar, saknade databastillägg, dubbla triggers och behörigheter som hade lagts till manuellt utan att dokumenteras i migreringarna.

En första agentgranskning gav enligt honom 108 fynd, varav 23 klassades som kritiska. En mer omfattande process, där flera modeller granskade mindre delar och försökte lösa oenighet med kodbevis, gav 319 fynd. Habchy hittade dessutom problem manuellt som båda granskningarna hade missat.

Siffrorna är inte oberoende verifierade. De visar ändå en viktig skillnad: säkerhetsfel och trasiga migreringar kan lokaliseras i artefakten. En oskyddad slutpunkt går att peka ut. En felaktig policy går att ändra. Ett saknat test går att skriva.

Det svåra började när koden var begriplig men beslutet bakom den saknades.

Fyra funktioner gav olika betyg

Appens kärna var en daglig poäng för elevens insats, som föräldern fick se som ett bokstavsbetyg. Habchy beskriver fyra funktioner som kunde räkna fram poängen.

En daglig och en veckovis kalkyl byggde på avklarade mål. En generell och en satsvis beräkning blandade i stället insats, kunskapsnivå och tillförlitlighet över tvåveckors- och månadsperioder. Funktionerna använde olika viktning men skrev till samma fält. Den som kördes sist bestämde resultatet.

Gränserna för bokstavsbetyget fanns dessutom på fem ställen. Olika versionstaggar antydde att någon hade sett beräkningarna som skilda modeller. Det fanns däremot ingen dokumentation som sade vilken modell som var den rätta.

Det gör felet till något annat än teknisk skuld. Att välja en funktion hade kunnat ändra vilket betyg ett barn fick och vilket besked en förälder såg. Ett test hade inte löst frågan, eftersom testet bara skulle ha gjort utvecklarens gissning permanent.

Habchy eskalerade därför frågan som ett produktbeslut.

Kod kan bevara hur, men tappa varför

AI-verktyg är bra på att göra en idé körbar. De kan också producera kommentarer, tester och läsbara funktioner. Men ingen av de artefakterna räcker när flera rimliga implementationer motsvarar olika verksamhetsregler.

Det här problemet är inte unikt för AI-byggda appar. Äldre handskrivna system är fulla av odokumenterade beslut. Skillnaden är tempot och överlämningen. När en icke-teknisk beställare kan bygga en stor produkt utan en utvecklare i varje beslut blir det lättare att skapa fungerande kod utan ett gemensamt språk för varför den ser ut så.

Habchy pekar också på ett missvisande ansvarsglapp. Verktygen säljs med löftet att användaren inte behöver veta vad en utvecklare vet. Då behöver verktyget hjälpa till att fånga just sådant som en erfaren utvecklare normalt hade frågat efter: vilken regel är auktoritativ, vilket alternativ övergavs och vad får inte förändras utan ett nytt verksamhetsbeslut.

Det behöver inte bli ett tungt kravdokument. Men produktens centrala beräkningar måste ha en spårbar källa till sanning utanför den senaste kodversionen.