Da jeg har været vant til at arbejde uden AI-værktøjer og først senere begyndte at bruge AI gennem prompts i blandt andet ChatGPT, var det ikke umiddelbart oplagt for mig, hvordan Codex skulle passe ind i mit normale workflow. Faktisk var et af de første spørgsmål helt lavpraktisk: Hvordan får jeg overhovedet Codex ind i VS Code?

I stedet for først at læse mig gennem dokumentationen til VS Code, GitHub Copilot og OpenAI Codex valgte jeg derfor at diskutere mulige tilgange med ChatGPT.

Målet var i første omgang at prøve Codex på mit Sandboxer-projekt og finde en måde at bruge AI til konkrete forbedringer uden samtidig at miste overblikket over, hvad der sker i projektet. Tidligere har jeg dog også brugt den indbyggede CoPilot, dog uden .agents.md, så der har været nogle nye ting, at få prøvet af.

Sandboxer er mit generiske Docker-baserede udviklingsmiljø til lokal webudvikling. Jeg bruger det som en genanvendelig base, mens de enkelte applikationer senere får deres egne project-specific containers til production.

1. Første forsøg: en custom agent i VS Code

Mit første forsøg tog udgangspunkt i VS Codes custom agents. Jeg kørte:

/create-agent

Idéen var at lave en agent, som specifikt kendte formålet med Sandboxer. Den skulle blandt andet forstå, at projektet er et development environment og ikke en production deployment stack, at Alpine-baserede images som udgangspunkt foretrækkes, og at løsningen helst skal forblive lille og simpel.

/create-agent åbnede en interaktiv guide, og jeg oprettede agenten:

sandboxer-maintainer

VS Code oprettede herefter filen:

.github/sandboxer-maintainer.agent.md

Den automatisk genererede fil var ikke helt ved siden af. Den havde allerede aflæst en del om projektet, men ifølge ChatGPT gjorde den også nogle af de nuværende implementation details til mere permanente regler, end jeg ønskede.

På dette tidspunkt kendte jeg ikke agent-systemet godt nok til selv at vide, om alle ChatGPTs indvendinger var rigtige. De virkede dog rimelige, da jeg læste dem, og min vurdering var derfor, at jeg lige så godt kunne fortsætte. Hvis konfigurationen senere viser sig at være forkert, kan den ændres igen.

2. Agent-filen blev gjort meget mindre

I stedet for at placere alle regler direkte i VS Codes custom agent-fil endte jeg med at gøre den til en forholdsvis lille wrapper:

---
name: sandboxer-maintainer
description: Maintains and improves this minimal, Alpine-first Docker-based local web development sandbox.
---

Read and follow the repository's `AGENTS.md`.

Act as the Sandboxer maintainer.

Inspect the relevant repository files before changing behavior.

Keep changes narrowly scoped, validate them appropriately, and avoid destructive Docker operations.

Tanken er simpel: VS Code-agenten skal ikke indeholde endnu en stor kopi af projektets regler. Den henviser i stedet til AGENTS.md, som kan fungere som det centrale sted for project instructions.

Det virkede umiddelbart mere fornuftigt end at have to forskellige filer med næsten de samme regler, som senere risikerer at komme ud af sync.

3. Fra GitHub Copilot til Codex

Undervejs gik det op for mig, at jeg i første omgang hovedsageligt arbejdede med VS Codes GitHub Copilot-integration og ikke Codex.

Da jeg allerede har et ChatGPT Plus-abonnement, ville jeg gerne prøve Codex i stedet. Jeg installerede derfor den officielle Codex extension til VS Code og loggede ind med min eksisterende ChatGPT-konto.

På nuværende tidspunkt ved jeg ikke, om Codex eller GitHub Copilot er den bedste løsning for mig, hvis der overhovedet findes et entydigt svar på det. Foreløbig er det Codex, jeg eksperimenterer videre med.

4. Codex fik sit eget billede af projektet

Med Sandboxer åbent i VS Code kørte jeg:

/init

Codex analyserede projektet og oprettede AGENTS.md i project root.

Det var faktisk et ganske brugbart udgangspunkt. Codex identificerede blandt andet Docker Compose-strukturen, de eksisterende Dockerfiles, configuration directories, volumes og forskellige commands til validation.

/init viste sig at være et godt udgangspunkt, men ikke noget jeg bare ville acceptere ukritisk, og derfor fik jeg ChatGPT til at hjælpe med, at skrive min først AGENTS.md.

5. Hvad skal AGENTS.md egentlig fortælle Codex?

Det næste spørgsmål blev derfor ikke bare, hvilke regler der skulle stå i AGENTS.md, men hvilken type regler der overhovedet hører hjemme der.

Jeg ønsker ikke, at filen skal fryse den nuværende implementation fast. Den skal i stedet beskrive de principper, Codex skal arbejde ud fra, når implementation ændrer sig.

De vigtigste prioriteter blev derfor defineret nogenlunde sådan her af ChatGPT:

1. Correctness
2. Små og minimale images
3. Simpel architecture
4. Maintainability og reproducibility
5. Fornuftig local security og developer usability
6. Debugging convenience

Rækkefølgen er vigtig. Jeg vil eksempelvis gerne have små images, men ikke hvis resultatet er en markant mere kompliceret løsning. Derfor står der også eksplicit i filen, at simplicity ikke skal ofres for trivielle reduktioner i image size.

På samme måde er Sandboxer Alpine-first, men ikke Alpine-for-enhver-pris. Hvis noget reelt ikke fungerer ordentligt på Alpine, skal Codex kunne anbefale noget andet. Den skal bare forklare hvorfor først.

Det samme princip gælder dependencies, architecture og debugging: Codex må gerne foreslå ændringer, men den skal kunne skelne mellem et faktisk teknisk problem og noget, der blot er en stilistisk præference.

6. Alpine-first som udgangspunkt

Alpine fylder en del i mine instructions, fordi små images er et bevidst mål med Sandboxer.

Når Codex vurderer software eller dependencies, skal den derfor være opmærksom på eksempelvis musl kontra glibc, package availability, native dependencies og binaries, som måske er bygget med andre Linux-distributioner i tankerne.

Hvis et tool ikke fungerer ordentligt på Alpine, vil jeg hellere have en forklaring end et automatisk skift til Debian eller Ubuntu.

Omvendt skal Codex heller ikke bruge urimeligt meget kompleksitet på at spare nogle få megabytes. AGENTS.md forsøger derfor at gøre Alpine til et stærkt udgangspunkt frem for et absolut krav.

7. Debugging skal ikke fylde hele det normale image

Samme tankegang gælder debugging.

Jeg vil gerne kunne debugge projektet, men jeg ønsker ikke nødvendigvis at installere alle tænkelige debugging- og profiling tools permanent i de normale images.

Codex skal ikke bare spørge: Kan dette tool installeres? Den skal også overveje, om det overhovedet bør være en permanent del af miljøet. Faktisk foretrækker jeg selv at træffe den slags beslutninger.

8. Resultatet: to filer med hver sin rolle

Den relevante del af projektet ser nu omtrent sådan ud:

sandboxer/
├── AGENTS.md
├── docker-compose.yml
├── ...
└── .github/
    └── sandboxer-maintainer.agent.md

AGENTS.md indeholder de egentlige project instructions og principper for Sandboxer.

.github/sandboxer-maintainer.agent.md er derimod en lille custom agent-wrapper til VS Code, som henviser tilbage til AGENTS.md.

Det giver mig ét primært sted at vedligeholde reglerne i stedet for to næsten ens konfigurationer.

9. Første test: Codex må ikke ændre noget

Da opsætningen var på plads, var næste skridt at finde ud af, om Codex faktisk havde forstået den.

Jeg havde ikke lyst til at starte med en prompt som "fix mit projekt" og derefter se, hvad der skete. Derfor fik jeg ChatGPT til at formulere en prompt, der kunne gennemgå projektet og lave et review.

Jeg gav Codex den færdige prompt:

Review the current Sandboxer repository.

Do not modify anything yet.

Inspect the Docker Compose configuration, Dockerfiles, configuration files, setup scripts, networking, volumes, and README.

Identify the most worthwhile improvements and group them into:

- correctness issues
- image-size or dependency improvements
- Alpine compatibility issues
- outdated dependencies or base images
- security or host-exposure issues
- maintainability improvements
- developer-experience improvements

For each finding:
- explain the current situation
- explain whether you recommend changing it
- explain the tradeoff
- mention Alpine compatibility where relevant
- mention likely image-size impact where relevant

Prioritize the findings rather than producing a huge list of minor stylistic observations.

Formålet var ikke bare at få en liste over problemer. Jeg ville først se, hvordan Codex fortolkede projektet og de instructions, jeg havde givet den.

Hvis den straks begyndte at foreslå Kubernetes, production infrastructure, store kitchen-sink images eller et skift væk fra Alpine uden en konkret grund, ville det være et tegn på, at AGENTS.md stadig skulle justeres.

10. Jeg vil stadig forstå eventuelle ændringer

Den vigtigste del af mit workflow handler i sidste ende ikke om konfigurationen af Codex, men om hvor meget kontrol jeg vil afgive til den.

Jeg vil foreløbig starte med små ændringer, efterfulgt af test mellem hvert skridt. Det giver mig mulighed for at bruge Codex som hjælp uden at miste forståelsen af projektet inde i mit eget hoved.

Hvis Codex får lov til at foretage for mange ændringer på én gang, uden at jeg selv følger med, risikerer jeg at ende med et projekt, som måske virker, men som jeg ikke længere har ordentligt overblik over.

Af samme grund skal Codex heller ikke introducere nye dependencies uden min godkendelse.

Mit foreløbige workflow er derfor ganske simpelt:

1. Review en konkret del af projektet
2. Vælg én ændring, der faktisk er værd at lave
3. Lad Codex implementere eller hjælpe med ændringen
4. Gennemgå og test resultatet
5. Fortsæt først derefter til næste ændring

Jeg forsøger altså ikke at få Codex til automatisk at modernisere hele Sandboxer. Jeg vil snarere bruge den som en ekstra maintainer, der kan analysere projektet, udfordre mine valg og hjælpe med konkrete forbedringer, mens jeg selv beholder forståelsen, ejerskabet og kontrollen.

Da jeg har fået Codex til at virke, kan jeg endelig begynde at bruge det i udviklingen af projektet. Den første ændring har jeg dokumenteret her: Mit første forsøg med Codex i VS Code: Én ændring ad gangen