Mit første forsøg med Codex i VS Code: Én ændring ad gangen
mit første forsøg med codex i vs code. se hvordan jeg forbedrede sandboxer med en afgraenset ændring, lokal test og godkendelse før commit og merge.
Af. Jacob
Edited: 2026-09-24 14:13
Efterfølger til: Opsætning af et Codex-workflow til Sandboxer i VS Code
Jeg har været vant til at arbejde som udvikler uden AI-værktøjer og begyndte først senere at bruge AI gennem prompts i blandt andet ChatGPT. Derfor var det heller ikke umiddelbart oplagt for mig, hvordan Codex skulle passe ind i min normale arbejdsgang. Inden jeg begyndte at bruge det, overvejede jeg blandt andet, hvordan jeg overhovedet fik Codex ind i VS Code, hvor meget adgang det skulle have til projektet, og hvordan jeg kunne bruge det uden samtidig at miste forståelsen af den kode, der blev ændret.
Jeg har nu prøvet Codex i VS Code på Sandboxer, mit Docker-baserede udviklingsmiljø. Målet var at få hjælp til konkrete forbedringer og samtidig bevare overblikket over projektet. Jeg ønskede derfor at arbejde med små ændringer og gennemgå resultatet undervejs frem for blot at lade Codex ændre større dele af projektet på én gang. Her er processen bag den første ændring.
Først skulle rammerne på plads
Med hjælp fra ChatGPT begyndte jeg med at tilføje AGENTS.md og en agentbeskrivelse i .github/agents/sandboxer-maintainer.agent.md.
Filerne beskriver projektets formål og prioriteringer: Sandboxer skal være et enkelt, generelt udviklingsmiljø med små Alpine-baserede images og så få unødvendige afhængigheder som muligt.
Derefter bad jeg Codex gennemgå projektet uden at ændre noget. Gennemgangen omfattede Docker Compose, Dockerfiles, konfiguration, installationsscripts og dokumentation. Den pegede blandt andet på muligheder for at forbedre sikkerhed, opstart, afhængigheder og udvikleroplevelse.
Én ændring ad gangen
Listen gav anledning til en overvejelse: Skulle jeg lade Codex arbejde sig gennem det hele, eller ville jeg så miste overblikket over mit eget projekt?
Jeg valgte en arbejdsgang med én afgrænset ændring ad gangen. Codex forklarer forslaget, implementerer det på develop og udfører de tilgængelige kontroller. Jeg gennemgår ændringerne i VS Code og tester dem lokalt. Først efter min godkendelse bliver ændringen committed og eventuelt flettet ind i main.
Hver forbedring får sit eget commit. Det gør historikken lettere at følge og giver mig mulighed for at forstå og tage stilling til hver ændring.
Den første ændring: lokal adgang til Sandboxer
Vi begyndte med en lille ændring i docker-compose.yml. De publicerede porte skulle bindes til 127.0.0.1 for at begrænse utilsigtet adgang fra netværket. Det var særligt relevant, fordi miljøets phpMyAdmin var konfigureret til automatisk login som databaseadministrator.
En portbinding som denne:
ports:
- "80:80"
Blev ændret til:
ports:
- "127.0.0.1:80:80"
Codex opdaterede bindingerne for port 80, 443, 8000 og 3306 samt den tilhørende forklaring i README.md. Ændringen omfattede ingen opgraderinger eller andre rettelser.
Codex kontrollerede, og jeg testede
Codex validerede Compose-konfigurationen, kontrollerede de resulterende portbindinger og tjekkede for whitespace-fejl. Der var dog en begrænsning: Codex kunne ikke få adgang til Docker-daemonen i sit kørselsmiljø og kunne derfor ikke verificere de kørende containere.
I stedet gav det mig konkrete kommandoer og forklarede, hvad jeg skulle kigge efter:
docker compose up -d
docker compose ps
Jeg testede ændringen lokalt og bekræftede, at den virkede. Codex ventede derefter på min udtrykkelige godkendelse, før det oprettede et commit.
Resultatet
Ændringen blev committed på develop med beskeden Bind published sandbox ports to localhost og commit-id ee0c5d6. På min anmodning blev den derefter flettet ind i den lokale main-branch. På dette tidspunkt var ændringen endnu ikke pushet til GitHub.
Det vigtigste resultat af forsøget var en arbejdsgang, jeg selv kunne følge med i, uden at jeg pludselig ville have mistet overblikket over ændringerne eller projektet som helhed.
Codex stod for implementeringen og de kontroller, det havde adgang til. Jeg beholdt ansvaret for at gennemgå ændringen, teste den og beslutte, hvornår den var klar til commit og merge.
Jeg vil foreløbig fortsætte med denne tilgang: små ændringer og test mellem hvert skridt. Det giver mig mulighed for at få hjælp uden at miste min egen forståelse og overblik over projektet.
Hvis Codex foretager en lang række ændringer på én gang, som jeg ikke selv når at forstå, risikerer jeg gradvist at miste den mentale model af, hvordan projektet hænger sammen, og hvad det faktisk indeholder. Derfor vil jeg hellere arbejde iterativt og gennemgå ændringerne løbende. Codex får heller ikke lov til at introducere nye dependencies uden min eksplicitte godkendelse.
Denne artikel er delvist skrevet med hjælp fra AI for at spare tid. Jeg har selv gennemgået teksten og foretaget rettelser og justeringer, så den afspejler mine egne erfaringer og overvejelser.
Fortæl os hvad du tænker: