Codex mod Claude Code: derfor bruger jeg begge

I mit eget udviklingsarbejde bruger jeg både Codex og Claude Code. Jeg vil kunne komme videre, når en AI sidder fast, bygger på en forkert antagelse eller laver en ændring, der kræver en nærmere gennemgang.

At vælge ét værktøj er en rimelig beslutning. Abonnementet skal være pengene værd, og værktøjet tager tid at lære. Min holdning er, at adgang til et andet værktøj er værd at betale for i udviklingsarbejdet, når det kan spare tid på gentagne forsøg, der ikke fører videre. Det kræver ikke, at begge bliver brugt til hver opgave.

Sådan adskiller de sig i mit arbejde nu

Iagttagelserne er fra oktober 2026, hvor jeg bruger GPT-6.1 Sol i Codex og Claude Opus 5.5 i Claude Code. Begge er blevet meget bedre til at skrive kode. Forskellen mellem dem ændrer sig med hver ny version, men nogle mønstre går igen i mit eget arbejde.

Claude Code følger instruktioner tæt. Det er det, jeg vil have, når instruktionen er rigtig. Er min instruktion forkert, gør den typisk alligevel, som jeg har bedt om, så det er selve instruktionen, der skal kontrolleres.

Codex siger oftere fra, når jeg giver en dårlig instruktion. Til gengæld går den nogle gange videre end opgaven, selv med en god instruktion, og ændrer ting, jeg ikke har bedt om. Med Codex skal kodeændringerne derfor kontrolleres for, om de holder sig til opgaven.

Med begge værktøjer skal jeg både vurdere instruktionen og gennemgå kodeændringerne. Det er de tendenser, jeg især holder øje med hos hver af dem, ud fra mit eget arbejde med de modeller. Det er ikke en sammenlignende test.

Claude har ikke indbygget billedgenerering til fotos og illustrationer. Artikelbillederne på denne hjemmeside laver jeg med Codex.

Derfor vælger jeg stadig begge

Det andet værktøj giver mig en ny mulighed, når den første samtale ikke længere fører videre. Hvis gentagne rettelser ender med den samme uønskede ændring, kan et nyt forsøg tage udgangspunkt i det oprindelige krav og koden uden at overtage forklaringen fra den første samtale.

Det giver mig også en ekstra vurdering af en foreslået løsning. Ved en ændring med væsentlige konsekvenser beder jeg det andet værktøj om at gennemgå kravene og kodeændringerne, før det får den første models begrundelse. Så er det lettere at se, om de to tilgange bygger på forskellige antagelser.

En uenighed kan pege på noget, der bør undersøges. Som et tænkt eksempel antager det ene værktøj, at et API-svar altid indeholder et bestemt felt, mens det andet spørger, hvad der sker, når feltet mangler. Næste skridt er at kontrollere API’ets specifikation eller genskabe et svar uden feltet. Er de to modeller enige, skal resultatet stadig kontrolleres.

En konvertering fra PHP til Astro, der gik ud over opgaven

For noget tid siden, med tidligere modeller, brugte jeg under en konvertering fra PHP til Astro næsten en time på at få en AI til at bevare layoutet, beholde Tailwind CSS og lade stylingen være. Den omskrev dele af layoutet, introducerede specialtilpasset CSS og “forbedrede” ting, jeg ikke havde bedt om.

Begrænsningen stod allerede i instruktionen. Det var ikke en pålidelig løsning at gentage “ændr ikke stylingen”. Resultatet skulle kontrolleres op imod den eksisterende side.

Begge værktøjer er blevet meget bedre siden da, men kontrollen af den slags opgaver er den samme:

• Bevarede resultatet HTML-strukturen og Tailwind-klasserne dér, hvor det var et krav?
• Holdt ændringen sig til de aftalte filer?
• Bevarede den færdige side layoutet ved de relevante skærmstørrelser?
• Hvor meget rettelse og kontrol krævede resultatet?

En gyldig Astro-komponent kan stadig være forkert, når opgaven er at bevare et layout. Det værktøj, der kræver mindst efterfølgende rettelse til den opgave, er det mest nyttige valg til den. Det samme værktøj bør vurderes særskilt til fejlfinding eller arkitektur.

I dag kan jeg også lade Claude Code åbne siden i en browser og sammenligne det færdige resultat, hvilket fanger den slags afvigelser hurtigere end en gennemlæsning af kodeændringerne.

Hvad de nye modeller ændrer

Iagttagelser som mine er knyttet til bestemte modeller og programmer. En sammenligning skal angive modellen, programmet, de tilgængelige værktøjer og selve opgaven.

Oversigten er kontrolleret den 17. oktober 2026:

• OpenAIs modeldokumentation peger på GPT-6 Astra, når en opgave kræver mest mulig kapacitet på tværs af trin og værktøjer, på GPT-6.1 Sol til arbejde med kode, programmer og dokumenter, når prisen betyder noget, og på GPT-6 Luna til afgrænsede opgaver i store mængder.
• Anthropics modeloversigt omfatter Claude Fable 5.1, Opus 5.5, Sonnet 5.5 og Haiku 5.5. Anthropic foreslår Opus 5.5 som udgangspunkt til de fleste opgaver og Fable til krævende analyse og længerevarende arbejde med AI-agenter.

Det er leverandørernes anbefalinger, ikke resultater fra min egen sammenligning. Kontrollér, hvad din konto faktisk giver adgang til, før du betaler for en bestemt model.

Nye udgivelser er min anledning til at afprøve igen, hvilket værktøj jeg starter med, så en gammel præference for én leverandør ikke træffer beslutningen for mig. De har ikke fjernet min grund til at have begge.

Sådan vælger jeg det primære værktøj

Selv med begge til rådighed lader jeg ét værktøj stå for implementeringen af en bestemt ændring. At flytte hele opgaven frem og tilbage giver ekstra arbejde og gør det sværere at holde styr på, hvad der er kontrolleret.

Når du skal vælge det primære værktøj, så sammenlign dem på opgaver fra din egen kodebase. Det kan være en lille fejl, der kan genskabes, en komponentkonvertering med stramme krav til layoutet eller en gennemgang af en eksisterende kodeændring.

Giv hvert forsøg den samme oprindelige kode, de samme krav, projektinstruktioner og relevante oplysninger. Brug separate grene eller worktrees, så det ene forsøg ikke overtager det andets ændringer. Notér modellen og indstillingerne, og vurder derefter:

• Korrekthed: opfylder resultatet kravene?
• Afgrænsning: blev der ændret noget uden for opgaven?
• Kontrol: hvad blev faktisk kørt, og hvad mangler stadig at blive undersøgt?
• Tidsforbrug: hvor meget udviklertid gik til rettelser og gennemgang?
• Omkostninger: hvilket forbrug og hvilke abonnementsudgifter krævede resultatet?

Et hurtigt første svar betyder mindre, hvis rettelsen tager længere tid at gøre færdig. En dyrere model kan være pengene værd til en svær opgave uden at blive standardvalget til hver lille ændring.

Den praktiske opsætning er beskrevet i brug af Claude Code og Codex i en eksisterende kodebase. Fælles krav hører hjemme i AGENTS.md og CLAUDE.md med projektinstruktioner, så et skift af værktøj ikke kræver, at du forklarer projektet forfra.

Hvornår jeg tager det andet værktøj i brug

Jeg tager det andet værktøj i brug, når arbejdet går i stå, når et valg af arkitektur fortjener en ekstra vurdering, eller når en ændrings konsekvenser gør en ekstra kodegennemgang relevant.

Giv det et afgrænset spørgsmål. Ved en kodeændring kan du bede det sammenligne ændringen med kravene og finde utilsigtede ændringer i funktionaliteten. Ved en fejl kan du spørge, hvilke observationer der støtter den foreslåede årsag, og hvad der ville afkræfte den.

De konkrete arbejdsgange er beskrevet i AI-kodegennemgang med Claude og Codex og fejlfinding med Claude Code og Codex.

Behold én løsning, og kontrollér den. To agenter bør ikke lave konkurrerende ændringer i den samme arbejdsmappe.

Hvad hvert abonnement skal gøre sig fortjent til

Hvert abonnement skal være pengene værd gennem nyttigt arbejde. Det vurderer jeg ud fra tiden frem til et kontrolleret resultat, der kan vedligeholdes, og de fejl, der bliver fundet undervejs.