Läsa AI-genererad kod utan att kunna programmera

Del 2 av 6 i vibecoding-spåret — för dig som bygger genom att beskriva vad du vill ha. Skriver du kod till vardags är guideserien mer detaljerad.

Kort sagt

Du behöver inte kunna skriva koden för att kunna läsa den. Att läsa är en betydligt lägre tröskel — du behöver bara känna igen formen och kunna ställa rätt fråga om resten. Den här sidan lär dig se ungefär vad en fil gör på en minut, utan att lära dig något programmeringsspråk.

Varför det lönar sig

Så länge du inte tittar på koden alls är du helt beroende av att modellen har rätt. Du kan inte upptäcka att den lade till något du inte bad om, att den tog bort något du behövde, eller att den löste problemet genom att stänga av det som gick sönder.

Med en grov läsförmåga ändras det. Du behöver inte förstå varje rad — du behöver upptäcka när något ser fel ut, så att du vet när du ska fråga.

Det du faktiskt behöver känna igen

All kod, oavsett språk, är i grunden byggd av ett fåtal saker. Känner du igen de här fem har du kommit långt.

Namn på saker

Något får ett namn och ett värde. const antalRundor = 12 betyder ungefär "antalRundor är 12".

Om–annars

if betyder om. else betyder annars. Det du ser inuti klamrarna händer bara i det fallet.

Upprepning

for, while eller .map( betyder "gör det här för varje sak i listan".

Funktioner

Ett namngivet block som gör något. function sparaRunda(...) är en instruktion som kan användas på flera ställen. Namnet berättar oftast vad den gör.

Anrop utåt

fetch, await, http eller en adress i texten betyder att koden pratar med något utanför sig själv. Det är här saker går sönder oftast.

Läs en fil på en minut

Du behöver inte läsa uppifrån och ned. Gör så här i stället:

Läs filnamnet. Det säger nästan alltid vad filen handlar om. login.js hanterar inloggning.

Leta upp funktionsnamnen. Sök efter ordet function eller efter namn följda av parentes. De är innehållsförteckningen.

Läs texten inom citattecken. Meddelanden till användaren, adresser, namn på fält. Det är den mest begripliga delen och avslöjar mycket om vad som händer.

Leta efter orden som betyder något allvarligt. delete, remove, drop, password, token, admin. De förtjänar en extra fråga.

Be om förklaringen — och kontrollera den

Det bästa verktyget för att läsa kod är samma modell som skrev den. Men be inte bara "förklara det här" — då får du en sammanfattning som låter bra oavsett om koden är rätt.

Förklaringsprompt Utan förkunskaper

Förklara vad den här koden gör, som om jag inte kan programmera: [klistra in]

Svara på tre saker separat:

1. Vad gör den, i två meningar?

2. Vad händer om något går fel — vad ser användaren då?

3. Finns det något här jag inte bad om?

Den tredje frågan är den som ger mest. Det är den som avslöjar när modellen la till en funktion, ett bibliotek eller ett beteende du inte kände till.

Jämför alltid med din avsikt

Om förklaringen inte stämmer med vad du bad om är det ett fel — oavsett hur bra koden ser ut. Missmatchen mellan "vad jag ville ha" och "vad den säger att den gör" går att upptäcka utan någon som helst programmeringskunskap, och det är det vanligaste felet av alla.

Fem saker som ska få dig att fråga en gång till

En rad som ser ut som en nyckel eller ett lösenord ligger direkt i koden. Fråga var den ska ligga i stället.
Ett catch som inte gör något — koden fångar ett fel och fortsätter som om inget hänt. Då döljs problemet.
Ett nytt namn du inte känner igen högst upp i filen. Något biblioteket lades till. Fråga varför, och om det behövdes.
Kod som rör användare i plural när uppgiften handlade om en. Det kan betyda att fel person kan se fel sak.
Något som kommenterats bort i stället för att lösas. Ofta ett tecken på att felet kringgicks.

Med den här läsförmågan går det att göra det som annars är det svåraste momentet: att ta sig ur läget när appen slutat fungera och man inte vet varför.

Nästa del

När appen går sönder

→