Så kontrollerar du AI-genererad kod om du inte kan läsa kod: 7 kontroller för icke-programmerare

AI satte ihop en webbplats eller bot åt dig på en kväll. Allt öppnas, knapparna fungerar och det verkar rulla på. Du visar projektet för andra – och en dag senare får du veta att betalningsformuläret tar betalt, men att beställningarna aldrig kommer fram. Eller att databasen med kundernas telefonnummer är öppen för hela internet.

Jag brukade också lansera mina första projekt på det sättet: saker som verkade fungera bjöd på överraskningar för riktiga användare. Nu går jag igenom samma checklista innan jag visar något för andra. Jag läser inte en enda kodrad när jag gör det – jag kom inte hit för det, och det gjorde du förmodligen inte heller.

Och det här är inte paranoia. Anthropic analyserade 400 000 Claude Code-sessioner: under sju månader sjönk andelen arbete som ägnades åt att laga trasig kod från 33 % till 19 %. Den sjönk – men försvann inte. Var femte session handlar fortfarande om att ”laga det AI:n förstörde”.

Själva kodskrivandet är inte längre flaskhalsen. Det viktiga nu är hur väl du förstår uppgiften och hur väl du kan kontrollera resultatet.

Ytterligare material om hur du ställer in verktyg finns i Ailoot-dokumentationen.

Varför kontrollera AI-genererad kod om den redan fungerar?#

AI skriver kod som klarar en första anblick. Den körs, skärmen visas och demon ser övertygande ut. Men en lansering säger ingenting om huruvida pengarna räknas rätt, om databasen är exponerad för omvärlden eller om allt kraschar när den hundrade användaren dyker upp.

Siffrorna bekräftar det här. Benchmarken FrontierCode undersökte i juni 2026 hur redo AI-genererad kod var för verkligt arbete utan ändringar. Även för de bästa modellerna på de svåraste uppgifterna låg andelen på omkring 13 %. Med andra ord måste det mesta av AI-genererad kod på allvarliga uppgifter finjusteras manuellt innan du kan lita på den.

Det goda är att vem som helst kan kontrollera koden. Här är Anthropics slutsats från samma 400 000 sessioner:

Din fördel gentemot en programmerare du anlitar är att du förstår din uppgift. Kontroll handlar också om förståelse; du behöver inte läsa kod för att göra det. Kontrollerna nedan är precis sådana du kan göra själv, utan krångel.

Vad kan faktiskt gå fel med AI-genererad kod?#

Innan du kontrollerar är det bra att veta vad du letar efter. AI-genererad kod har fem typiska problem, och du kan upptäcka alla fem utan att läsa kod – genom att se hur projektet beter sig.

Nedan följer sju kontroller i ordning. De första fångar ”fungerar inte” och ”fungerar fel”; de mittersta täcker säkerhet och påhitt; de sista är skyddsåtgärder före publicering. Gå helst igenom dem i följd: varje kontroll bygger på att den föregående är klar.

Kontroll 1: Be AI förklara koden med vanliga ord#

Du beskrev uppgiften med ord. AI översatte den till kod. Betydelsen kan gå förlorad mellan de två stegen: AI kan ha förstått dig annorlunda, fyllt i sådant åt dig eller tagit genvägar. Du kan upptäcka skillnaden utan att läsa kod – be den bara beskriva vad den gjorde med vanliga ord.

Förklara på vanlig svenska, utan kod, exakt vad du just gjorde:

vilken uppgift koden löser

vad som händer när en användare klickar på knappen eller skickar formuläret

var data lagras och vem som har åtkomst till den

vad som kan gå sönder och i vilken situation

Skriv som om du förklarade för någon som aldrig har programmerat. Om det finns någon del som du inte är säker på stämmer, säg det tydligt.

Läs svaret och jämför med vad du hade tänkt dig. Om det stämmer går du vidare. Om AI ”svamlar”, blir förvirrad i sin egen förklaring eller beskriver något annat än det du bad om, betyder det att den inte helt förstår vad den byggde. Be den göra om arbetet med ett förtydligande i stället för att bara lita på dess ord.

Förresten, om AI ofta gör något annat än det du bad om beror problemet ofta på hur uppgiften formulerades, inte på själva modellen. Jag har en separat genomgång om varför Claude inte gör det du ber om.

Att kontrollera AI:s resultat är en del av kontextteknik: du styr både vad du ger AI som indata och hur du utvärderar resultatet som utdata. Verktygslådan innehåller en AI-klon, en Second Brain och kontextteknik. Därefter slutar Claude vara en ”hallucinerande assistent” och blir ett verktyg som du faktiskt kan lita på med ett projekt.

Kontroll 2: Gå igenom scenarierna som en riktig användare#

En AI-demo följer alltid det lyckliga flödet: korrekta uppgifter, ett klick, allt går bra. En riktig användare beter sig inte så. Hen gör misstag, klickar på fel sak eller skriver en emoji i telefonfältet. Ditt jobb är att gå igenom projektet som användaren skulle göra.

1. Genomför huvudsakliga scenariot från början till slut

   Gör det projektet är till för: registrera dig, lägg en beställning, skicka en förfrågan. Gå hela vägen till slutet, inte bara halvvägs.

2. Kontrollera betalningen separat och på riktigt

   Om projektet tar emot pengar gör du själv en betalning på minsta beloppet i testläge. Kontrollera att beställningen skapas, statusen ändras och ett mejl skickas till dig och kunden. En betalning som ”går igenom” men inte skapar en beställning är ett klassiskt tyst fel.

3. Försök medvetet att få saker att gå fel

   Lämna fält tomma. Skriv bokstäver där siffror förväntas. Klicka på ”Skicka” två gånger i rad. Ladda upp en fil i fel format. Ett bra projekt säger artigt ”det där går inte”; ett dåligt kraschar eller sväljer tyst datan.

4. Öppna det på en telefon

   Hälften av användarna kommer från en telefon. Kontrollera att layouten håller ihop och att samma knappar fungerar där.

Ge AI allt du hittade i en och samma lista: ”Här är det som gick sönder i de här stegen; laga det och förklara varför det hände.” Ta inte ett problem i taget – ge den listan, så att AI kan se helheten och har mindre risk att förstöra en sak när den lagar en annan.

Kontroll 3: Fråga AI om säkerhet – här är en prompt#

En trasig knapp syns direkt. En säkerhetsbrist gör det inte: projektet fortsätter fungera som om inget vore fel tills någon utnyttjar bristen. De vanligaste problemen i vibe-kodade projekt är hemliga nycklar som skrivits direkt i koden, en databas som exponerats mot internet och formulär som låter någon skicka skadlig indata. AI kan hitta allt detta om du frågar rakt ut.

Granska det här projektet för säkerhetsproblem och förklara varje fynd på vanlig svenska, utan fackjargong. Gå igenom den här listan:

Kontrollera om några hemliga nycklar, lösenord eller token är inskrivna direkt i koden. Privata hemligheter får bara användas på servern, med lokal hemlighetskonfiguration som .env undantagen från git. .env och .gitignore förhindrar inte att frontend-/public-variabler hamnar i ett webbläsarbygge. Granska faktisk JavaScript, källkartor, HTML och nätverkssvar som skickas till klienten och verifiera att privata nycklar saknas.

Kontrollera om databasen är exponerad mot internet och vem som har åtkomst till den.

Kontrollera om indata kan få formulären att gå sönder: injektioner i databasfrågor eller extra kod i textfält.

Vad händer om en användare skickar skadlig data?

Kontrollera om några interna sidor eller adminpanelen är åtkomliga utan lösenord.

För varje punkt, säg om det finns ett problem, ge ett tydligt exempel på risken och förklara hur det kan åtgärdas. Börja med det farligaste problemet.

Kontrollera också att projektet inte blint gör vad det än får utifrån. Det kallas indirekt promptinjektion: ett kommando göms i ett mejl, en kommentar eller någon annans fil och AI-agenten följer det, eftersom den misstar det för en uppgift. Om projektet läser extern data och agerar på den, fråga AI vad som skulle hända om datan innehöll en dold instruktion.

Det här är ett djupt ämne, och en enda prompt kan inte täcka det helt. Om projektet hanterar pengar eller kunders personuppgifter läser du den separata guiden om säkerhet vid vibe-kodning.

Kontroll 4: Hittade AI på bibliotek eller data?#

AI skriver självsäkert saker som inte finns. Den kan lägga till ett bibliotek med ett rimligt namn som i själva verket inte finns. Den kan lämna testplatshållare i projektet: en produkt som heter ”Example”, mejladressen example@example.com eller utfyllnadstext i stället för riktigt innehåll. Det är lätt att missa i en demo, men för en riktig användare är det pinsamt eller gör att projektet inte fungerar.

Du kan upptäcka detta i två steg. Fråga först rakt ut:

Gå igenom projektet och kontrollera ärligt:

Finns alla externa verktyg och bibliotek du lade till på riktigt och går de att installera korrekt? Hittade du på något?

Finns det några testplatshållare, exempel eller utfyllnadstext kvar i stället för riktiga data?

Är alla länkar, adresser och kontaktuppgifter i projektet riktiga och inte platshållare?

Lista vad du hittade och föreslå vad det ska ersättas med.

Kör sedan bara projektet och titta igenom det. Ett påhittat bibliotek orsakar nästan alltid ett fel vid start. Och platshållare är lätta att upptäcka: om sidan säger ”Product 1” har du inte ersatt dem.

Påhittade bibliotek innebär en särskild fara eftersom angripare medvetet registrerar verktyg med namn som AI gillar att hitta på. Installerar du ett får någon annans kod tillgång till ditt projekt. Därför bör du ta frågan ”finns det här biblioteket ens på riktigt?” på allvar – den handlar direkt om säkerheten i ditt projekt.

Kontroll 5: Låt en andra modell kontrollera den första#

AI har en otrevlig egenskap: den håller med. Fråga ”är allt bra här?” så bekräftar den att allt är bra, eftersom den anpassar sig efter svaret den förväntar sig. Det kallas AI-sycophancy, och jag har skrivit om det separat. En samtalspartner av det slaget kommer att vara mild mot sitt eget arbete.

Lösningen är enkel: be om en andra bedömning. Öppna en ny session eller använd en annan modell och ge den projektet för granskning med samma prompt som i kontroll 3, med ett tillägg: ”en annan AI skrev den här koden; hitta dess svaga punkter.” En ny modell är inte bunden till den tidigare konversationen och pekar därför oftare ut problem.

1. Öppna en ren session eller använd en annan modell

   Använd en andra modell eller samma modell i ett nytt fönster utan någon uppgiftshistorik.

2. Ge den projektet och rätt instruktion

   Säg tydligt: ”en annan AI skrev den här koden; ditt jobb är att hitta fel och risker, inte berömma den.” Det motverkar smickerbeteendet.

3. Jämför de två bedömningarna

   Om båda håller med har de förmodligen rätt. Om de inte är överens undersöker du den punkten – det är där det blir intressant.

Det är precis det som händer i branschen just nu: AI skriver, AI kontrollerar och det slutliga beslutet ligger kvar hos en människa. Du kan inte överlåta det till modellen – det är ditt jobb.

Kontroll 6: Hur kan du återställa om en ändring förstör något?#

Kontrollerna på den här listan leder ofta till ändringar, och ändringar förstör ibland sådant som fungerade. För att undvika att det blir en katastrof sparar du den fungerande versionen i git före varje omgång med korrigeringar. Det är som att spara ett spel: om du förstör något laddar du den senaste sparpunkten.

Du behöver inte läsa kod för det här. Be bara AI: ”spara den nuvarande fungerande versionen i git med en tydlig etikett innan du ändrar något.” Och om allt går snett efter ändringarna: ”återställ projektet till den tidigare sparade versionen.”

Om git fortfarande känns främmande har jag två guider åt dig: så återställer du ändringar i Claude Code och vad du gör om AI raderade databasen. Den andra är till för när det redan är för sent att återställa, men du fortfarande kan återskapa datan.

Kontroll 7: Vad ska du kontrollera sist före publicering?#

De första sex kontrollerna handlar om vad koden gör. Den sjunde handlar om huruvida projektet är redo att möta människor. Det är här folk oftast snubblar: projektet fungerar, men de glömde att växla betalningen från testnyckeln till den skarpa, så de första kunderna betalar ”på låtsas”.

1. Betalning: från test till skarpt läge

   Om du tar emot betalningar ska du kontrollera att betalsystemets skarpa nyckel är ansluten, inte testnyckeln. Gör en riktig betalning på minsta beloppet och återbetala den till dig själv.

2. Hemligheter finns där de ska

   Fråga AI: ”Används privata nycklar bara på servern, med .env undantagen från git? Innehåller faktiskt webbläsarbygge eller något klientsvar en privat nyckel, även genom frontend-/public-variabler eller källkartor?” Kontrollera byggda filer och webbläsarens nätverkssvar, inte bara källans .env-fil. Git-undantag håller inte ett värde utanför ett frontendpaket.

3. Säkerhetskopiera datan

   Kontrollera att databasen sparas automatiskt någonstans. Om projektet körs på din egen server förklarar jag vad du ska göra inför publicering i Coolify-guiden.

4. Publiceringen fungerar utanför din egen enhet

   Öppna projektet på din telefon via en extern länk, inte bara på din egen dator. Något som fungerar lokalt fungerar inte alltid efter publicering.

Gå igenom alla fyra punkter, så kan du visa projektet för andra med gott självförtroende. Om något inte stämmer är det bättre att lägga en halvtimme nu än att ta hand om missnöjda kunder senare.

Vad händer om kontrollen tar för lång tid – ska du bara lita på AI?#

Jag förstår frestelsen. Kontroll känns tråkigt och ”inte vad jag skaffade AI för”. Men det är du, inte modellen, som ansvarar för resultatet. AI har inget anseende och drabbas inte av några konsekvenser: den producerade koden och glömde bort den. Du får svara kunden vars betalning inte gick igenom.

Skaparen av Claude Code har ett ännu bredare perspektiv:

Kodskrivandet har slutat vara flaskhalsen – AI tog hand om det. Värdet ligger nu någon annanstans: i att förstå uppgiften och kontrollera resultatet. Det är din styrka – du vet bättre än någon extern utvecklare vad resultatet ska vara för din kund.

Varför är kontroll en färdighet och inte en engångsuppgift?#

De här sju kontrollerna är det minsta som skiljer ”jag lanserade det och hoppas” från ”jag lanserade det och vet att det fungerar”. Gå igenom dem en gång, så fångar du redan de flesta överraskningarna innan dina kunder gör det.

Därifrån blir det en vana. Ge AI rätt kontext som indata och kontrollera resultatet som utdata, så sätts varje nytt projekt ihop snabbare eftersom du inte börjar från noll.

AI-klon, Second Brain och kontextteknik – hitta ytterligare material om att arbeta med verktyg i Ailoot-dokumentationen.