OpenAI Codex för nybörjare: låt agenten förklara koden först

Har du någon gång öppnat en liten webbplatsmapp, ett gammalt skript eller ett kursprojekt och tänkt: "Jag vill ändra en sak, men jag vågar knappt röra filerna"? Då är OpenAI Codex ett bra nästa steg efter vanlig ChatGPT. Men börja inte med att be agenten bygga om allt. Be den förklara projektet först.

OpenAI Codex är en AI-agent för kod: den kan arbeta inne i ett projekt, läsa filer, föreslå ändringar och hjälpa dig granska resultatet. Den ersätter inte ditt omdöme. Poängen i den här första guiden är att du ska behålla kontrollen: liten uppgift, tydliga behörigheter, granskning av diffen och en enkel kontroll innan du sparar något.

Källa: OpenAI Codex developer overview och OpenAI Codex quickstart.

Vem den här guiden passar

Den här guiden är för dig som redan har testat ChatGPT, Claude, Gemini eller en Custom GPT och nu vill förstå vad en AI-agent kan göra med kod. Du behöver inte vara professionell utvecklare. Du behöver däremot välja ett litet första projekt: en kopia av en enkel webbplats, ett övningsprojekt, ett kursprojekt eller ett kort internt skript.

Om onsdagens guide om Copilot Notebooks handlade om att samla projektkällor i Microsoft 365, handlar den här om något annat: ett kodprojekt, en föreslagen ändring och en diff som du själv granskar innan du accepterar något.

Det du lär dig på 10-20 minuter

Efter guiden kan du:

• hitta en rimlig första väg in i Codex,
• välja ett litet projekt som inte är känsligt,
• be Codex förklara filerna innan den ändrar något,
• be om en liten, reversibel ändring med tydliga villkor,
• granska diffen, alltså före/efter-vyn av ändrade filer,
• testa eller kontrollera resultatet innan du behåller det.

Var hittar du OpenAI Codex?

OpenAI beskriver flera sätt att använda Codex: app, IDE-tillägg, CLI och webben/molnet. För en första övning är den enklaste berättelsen ofta lokal: öppna Codex-appen om den är tillgänglig för din dator, logga in med ditt ChatGPT-konto och välj en liten projektmapp.

Om du använder webben går du till https://chatgpt.com/codex. Den vägen är mer kopplad till GitHub-repon och molnmiljöer, så låt inte det bli första kaninhålet om du bara vill förstå arbetssättet. Tillgång, gränser och arbetsyteinställningar kan skilja sig mellan konton, planer och administrerade arbetsytor.

Källa: Codex quickstart, Codex app och Codex cloud.

Innan du börjar: välj ett litet och kontrollerat projekt

Välj inte produktionskoden första gången. Ta en kopia, ett exempelprojekt eller en liten mapp där det är okej att testa. Om projektet redan använder Git kan du spara en checkpoint eller commit innan du startar, så att ändringar blir lätta att se och ångra.

Håll också gränserna rena. Lägg inte med .env-filer, API-nycklar, kunddata, produktionslösenord eller privat kod som du inte har rätt att använda. Det handlar inte om att undvika integrationer för alltid. Det handlar om att göra första integrationen begriplig: avgränsad mapp, tydliga behörigheter, godkännande innan Codex går utanför uppgiften och en logg/diff som en människa kan granska.

Källa: Codex sandboxing, agent approvals and security och Codex permissions.

Steg 1: öppna ett litet projekt

Starta Codex och välj en liten projektmapp eller ett litet repo. Om du jobbar lokalt är målet bara att Codex ska se projektet och förstå sammanhanget. Om du jobbar via molnet kan GitHub och miljöinställningar behövas, men spara den fördjupningen till senare om den stör första övningen.

Bra första exempel:

• en enkel landningssida där du vill ändra en text eller knapp,
• ett kursprojekt där du vill förstå filerna,
• ett litet skript som skapar en rapport,
• en kopia av ett demo-repo där inget kundkritiskt står på spel.

Steg 2: be Codex förklara innan den ändrar

Klistra in den här prompten först:

Förklara det här projektet innan du ändrar något.

Gör detta:
1. Beskriv på enkel svenska vad projektet gör.
2. Lista de 5-8 viktigaste filerna eller mapparna.
3. Berätta hur jag kan köra eller förhandsvisa projektet, om det framgår.
4. Peka ut sådant som verkar riskabelt, oklart eller saknas.
5. Ändra inga filer ännu.

Läs svaret som om du bad en kollega gå igenom projektet. Förstår du fortfarande inte? Be Codex förenkla, jämföra med något vardagligt eller visa vilken fil du ska läsa först.

Steg 3: be om en liten första ändring

När förklaringen är begriplig kan du be om ett förslag. Håll uppgiften liten.

Föreslå en liten, reversibel förbättring i det här projektet.

Kontext:
- Jag är nybörjare och vill kunna granska ändringen noggrant.
- Begränsa ändringen till [en fil / en komponent / en textändring / en liten buggfix].
- Rör inte hemligheter, miljövariabler, deployment-inställningar eller orelaterade filer.

Innan du ändrar något vill jag se:
1. exakt vilken ändring du föreslår,
2. varför den är säker och användbar,
3. vilka filer som skulle påverkas,
4. hur vi ska verifiera den.

Klart när: jag kan granska diffen och välja om jag vill behålla eller ångra ändringen.

Om Codex föreslår för mycket, stoppa där. Skriv: "Gör uppgiften mindre. Välj bara en fil och en tydlig ändring." Det är ett bra tecken när agenten går att styra tillbaka.

Källa: Codex prompting och Codex best practices.

Steg 4: godkänn bara den lilla ändringen

När planen är rimlig kan du låta Codex göra just den ändringen. Om den ber om nätverksåtkomst, full åtkomst eller rätt att ändra filer utanför projektmappen, fråga varför. För en första övning är svaret ofta: nej, inte än.

Bra nybörjarregel: Codex får gärna läsa och föreslå, men den ska inte få mer frihet än uppgiften kräver. I ett riktigt team kan samma princip bli en enkel rutin: avgränsade behörigheter, hemligheter i en hemlighetshanterare eller miljövariabler utanför chatten, godkännandesteg, loggar och granskning av diffen.

Steg 5: granska diffen innan du accepterar

En diff är före/efter-vyn av vad som ändrades. Titta efter sådant som inte hör hemma:

• nya filer som du inte bad om,
• ändrade inställningar,
• nya beroenden,
• borttagna kommentarer eller kontroller,
• ändringar i flera delar av projektet när du bad om en liten sak.

Om något känns för stort, kommentera eller skriv en följdfråga:

Håll scope mindre. Åtgärda bara de kommentarer jag lämnade i diffen. Ändra inga orelaterade filer.

Källa: Codex review pane.

Steg 6: verifiera innan du behåller ändringen

Be Codex föreslå den enklaste kontrollen. Det kan vara ett testkommando, lint, lokal förhandsvisning eller en manuell checklista. Om du inte vet hur du kör projektet, be Codex förklara kontrollen steg för steg.

Föreslå den minsta kontrollen för att verifiera den här ändringen.
Om det finns test-, lint- eller preview-kommandon i projektet, visa dem.
Om jag inte kan köra dem, ge mig en manuell kontrollista.

Spara eller committa bara det du faktiskt vill behålla. Ångra resten. Det låter långsamt, men det är mycket snabbare än att senare försöka förstå varför en AI-agent ändrade fem filer när du bad om en knapptext.

Återanvändbar första Codex-kort

Spara den här prompten för nästa lilla uppgift:

Du hjälper mig med min första lilla Codex-uppgift.

Regler:
- Förklara innan du ändrar.
- Håll uppgiften liten och reversibel.
- Rör inte hemligheter, .env-filer, deployment-inställningar eller orelaterade filer.
- Fråga innan du använder nätverk eller lämnar projektmappen.
- Markera allt osäkert som "behöver mänsklig kontroll".

Uppgift:
1. Förklara projektet på enkel svenska.
2. Föreslå en säker första förbättring.
3. Visa vilka filer som skulle ändras.
4. Vänta på godkännande innan du ändrar.
5. Efter ändringen: sammanfatta diffen och berätta hur jag verifierar den.

Vanliga misstag

Det vanligaste misstaget är att börja för stort: ett produktionsrepo, en vag prompt som "fixa allt" eller full åtkomst för att en video på nätet gjorde så. Ett annat är att lita på svaret för att det låter säkert. Kod måste fortfarande granskas.

Undvik också att blanda allt på första passet: app, CLI, IDE, moln, GitHub, AGENTS.md, MCP, worktrees och automations. Första passet ska lära dig rytmen: förklaring, liten plan, godkännande, diff, kontroll.

Nästa steg

Om första övningen fungerar kan du skapa en liten projektanteckning, eller senare en AGENTS.md, med hur projektet körs, testas och ska granskas. Det är ett bra nästa steg eftersom Codex då slipper gissa lika mycket nästa gång.

Vill du testa kodagenter i ett team eller företag på ett kontrollerat sätt? Hammer kan hjälpa dig välja ett litet första repo, sätta enkla behörighetsregler och bygga en rutin för förklaring, plan, diff, test och mänsklig granskning.

Nästa naturliga guide i serien kan bli Codex med AGENTS.md eller en första lätt Claude Code-guide, beroende på vad läsare och Shorts-data visar.