Claude Code og Codex sammen: 3 arbeidsmønstre

Praktisk materiale om å jobbe med agenter og vibe coding: Ailoot-dokumentasjon.

Hvorfor er ikke ett verktøy nok lenger i 2026?#

I mai 2026 gikk OpenAI inn på Anthropics område med GPT-5.5-modellen i Codex CLI. I nyere benchmarker har Codex et tydelig forsprang på terminaloppgaver og i SWE-bench Verified-modus. Anthropic svarte med Opus 4.8 og Dynamic Workflows og beholdt dermed forspranget på SWE-bench Pro (en test utformet for å forhindre datalekkasje, der det ikke hjelper å trene en modell på benchmarken). En grundig sammenligning side om side finner du i guiden Codex vs Claude Code—her går vi rett på kombinasjonen.

I 2026 finnes det ingen enkelt vinner. Ett mønster dominerer—team beholder Codex til rimelig, autonomt arbeid og Claude Code til risikable arkitekturbeslutninger.

Den viktigste forskjellen som avgjør hvordan arbeidet skal fordeles:

• Claude Code er forskeren. Den opprettholder en lang, grundig dialog, stiller spørsmål ved antakelser og vurderer flere tilnærminger før den velger en løsning. Den passer i situasjoner der det ikke er åpenbart fra starten hva som er riktig å gjøre.
• Codex er utføreren. Den får en oppgave og jobber målrettet mot resultater i en sandbox. Den passer til tydelige oppgaver som krever en rask «gi og få»-syklus.

Hvis du har begge verktøyene tilgjengelig, trenger du ikke velge mellom «å tenke» og «å gjøre». Du delegerer basert på oppgavetypen. Hvis du ikke har bestemt deg for hvilket av dem du skal installere først, finner du en sammenligning side om side i guiden Codex vs Claude Code.

Mønster 1: Claude Code skriver koden, Codex gjennomgår den#

I dette mønsteret forblir Claude Code hovedredaktøren. Codex kommer først inn på PR-nivå via skymodusen (Codex kjører direkte fra ChatGPT eller GitHub-appen, så du trenger ikke en ekstra terminal).

Slik ser det ut i praksis:

1. Trinn 1: Skriv funksjonen i Claude Code

   Åpne repositoriet i VS Code, start Claude Code, bytt til Plan Mode og diskuter arkitekturen for funksjonen. Du får utkast til kode, tester og migreringer. Gjør en commit til en feature branch.

2. Trinn 2: Opprett en PR i GitHub

   Åpne en pull request fra feature-branchen til main. Skriv inn @codex review this PR for edge cases, security issues, and test coverage gaps i beskrivelsen.

3. Trinn 3: Codex gjennomgår PR-en asynkront

   I skymodus kloner Codex repositoriet til sandboxen sin, leser diffen, kjører tester og linter og ser etter sårbarheter. Etter 5-15 minutter legger den igjen kommentarer direkte på PR-en.

4. Trinn 4: Gjør endringer i Claude Code

   Gå tilbake til Claude Code og gi den Codex-kommentarene som kontekst: «Her er det gjennomgangen fant; rett punktene 1, 3 og 5.» Claude gjør endringene og publiserer dem til repositoriet.

Dette mønsteret fungerer fordi Claude og Codex er trent på ulike datasett og har forskjellige filosofier. Codex oppdager det Claude overså på grunn av en blindflekk i modellen, og omvendt.

Risikoer ved mønster 1:

• Codex kan godkjenne en PR uten å oppdage et arkitekturproblem. Gjennomgå viktige beslutninger selv.
• Doble tokenkostnader: Claude og Codex analyserer den samme koden. Det lønner seg for komplekse funksjoner og er dyrt for små.
• Codex i skymodus kan ikke se det lokale miljøet ditt—miljøvariabler eller lokale databaser. Hvis funksjonen berører dem, bytt til en manuell kjøring.

Mønster 2: Codex lager et utkast, Claude Code forbedrer arkitekturen#

Dette mønsteret ble brukt i prosjektet som ble beskrevet i 2026, da en prototype av en registreringsfunnel med e-postvarsler måtte bygges på én kveld. I en slik situasjon kunne du brukt en time på å diskutere arkitekturen med Claude Code. Codex produserte et fungerende utkast på 12 minutter.

Slik fungerer det:

Det fungerer slik: Codex gjør grovarbeidet de første 15 minuttene, deretter løfter Claude det til produksjonskvalitet.

Ber du Codex lage noe polert med én gang, setter den seg fast i uklarheter. Ber du Claude Code jobbe raskt med én gang, begynner den å tvile. Gi hver av dem arbeidet de er laget for.

Risikoer ved mønster 2:

• Codex lager et utkast basert på antakelser som kan være vanskelige å rydde opp i senere. Hvis utkastet går i feil retning, er det billigere å forkaste det og starte på nytt enn å rette det.
• Claude Code kan bruke en halvtime på å gi variabler nye navn og glemme det egentlige arkitekturproblemet. Gi den konkrete endringer, ikke «rydd opp i dette».
• Kontekst går tapt mellom øktene. For at Claude Code skal forstå hva Codex mente, trenger du en AGENTS.md (se mønster 5) eller en detaljert kommentar øverst i filen.

Mønster 3: Codex for infrastruktur, Claude Code for forretningslogikk#

Tanken er enkel: ulike deler av en kodebase krever ulike måter å jobbe på.

Dette mønsteret utfyller tilnærmingen med å kjøre flere Claude Code-instanser parallelt—der håndterer samme modell ulike oppgaver gjennom git worktrees; her fordeler to forskjellige agenter ansvarsområdene.

Infrastrukturlag (Codex):

• GitHub Actions: legg til en ny jobb, juster caching, få CI til å gå raskere.
• Tester: skriv en suite med integrasjonstester etter en refaktorering.
• Prisma-migreringer: generer en migrering og sjekk at den kan rulles tilbake.
• Docker / Coolify-konfigurasjoner: legg til miljøvariabler, oppdater health check.
• Cron-jobber: skriv et sett med cron-handlere.

Codex gjør det best her fordi infrastrukturarbeid ofte består av mange små filer med standardkode. Codex henger seg ikke opp i at det «må tenke grundig gjennom dette»; den jobber helt til oppgaven er ferdig.

Forretningslogikk (Claude Code):

• Registreringsfunnel: hva brukeren skal se på hvert trinn.
• Prisberegning som tar hensyn til rabatter, avbetaling og gavepromokoder.
• Automatiserte varslingsflyter: hvilke utløsere og vilkår.
• Integrasjoner med eksterne API-er: feilhåndtering, retries, caching.
• Finansielle modeller: beregning av enhetsøkonomi og inntektsprognoser.

Claude Code gjør det best her fordi oppgavene krever utvidet dialog med produktforståelse. Uten å diskutere scenarioer ender du med en teknisk løsning som ikke tar hensyn til brukerens faktiske smertepunkter.

Slik fordeles arbeidet i repositoriet:

project/
├── .github/workflows/      ← Codex (CI, tests)
├── infra/                  ← Codex (Docker, Coolify, migrations)
├── scripts/                ← Codex (task scripts)
├── tests/                  ← Codex (integration tests)
├── src/
│   ├── lib/                ← Claude Code (business logic)
│   ├── app/                ← Claude Code (routes, forms, pages)
│   └── components/         ← Claude Code (UI)
└── prisma/
    └── schema.prisma       ← Claude Code (data models—product decision)

Dette er ingen fast regel. Det kan være overlapp—for eksempel kan Claude Code redigere en GitHub Action hvis den har produktbetydning (som å sende et varsel etter publisering). Men 80% av oppgavene passer godt med denne fordelingen.

Hvordan synkroniserer du CLAUDE.md og AGENTS.md?#

En uventet utfordring dukket opp i den beskrevne erfaringen med å bruke Claude Code og Codex parallelt. Claude Code fulgte reglene i CLAUDE.md («ikke rør migreringer uten bekreftelse»). Codex kunne ikke se reglene og kjørte migreringer i et arbeidsmiljø uten å nøle. Etter den tredje ødelagte databasen ble det nødvendig å finne ut hvordan begge filene kunne holdes skikkelig synkronisert.

Begge filer kan inneholde prosjektkontekst, samtalepreferanser, testkommandoer, katalogunntak og commit-standarder. Gjenbruk regler som gjelder begge verktøy, og hold deretter verktøyspesifikke kommandoer og konfigurasjon atskilt. Et forbud mot å endre migreringer hører for eksempel hjemme i begge instruksjonssett hvis det gjelder begge agenter.

Dette er likt i begge filene:

• Stack: hvilke rammeverk, hvilken database, hvilken ORM.
• Prosjektbeskrivelse: hva det er, hvem det er for, og hvilke hovedentiteter det har.
• Forbud: hvilke mapper som ikke skal røres, og hvilke kommandoer som ikke skal kjøres.

Dette er forskjellig:

• Claude Code-spesifikke hooks, innstillingslag og MCP-konfigurasjon hører hjemme i de relevante konfigurasjonsfilene for Claude Code. Tekst som beskriver konvensjonene, kan refereres fra CLAUDE.md; den blir ikke portabel konfigurasjon bare ved kopiering.
• AGENTS.md er en åpen standard. Codex, Cursor, Aider, Continue, Cline og Factory Droid leser den—25+ agenter. Den separate guiden går nærmere inn på AGENTS.md-formatet. Codex MCP-konfigurasjoner lagres i ~/.codex/config.toml (TOML, ikke JSON som hos Claude).

Et utbredt mønster i 2026 er én kanonisk kilde til regler i /context/-mappen i monorepoet, som et synkroniseringsskript bruker til å generere CLAUDE.md, .cursor/rules/*.mdc og AGENTS.md. De verktøyspesifikke filene markeres som skrivebeskyttet; bare kilden redigeres.

Kjør synkroniseringsskriptet gjennom en pre-commit-hook eller gjennom en GitHub Action. Hvis det gjøres endringer direkte i CLAUDE.md, feiler CI. Dette hindrer at reglene for de ulike verktøyene sklir fra hverandre.

Et annet alternativ er den offisielle Codex Plugin for Claude Code (kunngjort 30. mars 2026, versjon 1.0.4). Den legger til kommandoene /codex:review, /codex:adversarial-review og /codex:rescue i Claude Code. Codex kjører som en subagent med sin egen ~/.codex/config.toml og AGENTS.md. Dermed trenger du ikke en ekstra terminal, men AGENTS.md er fortsatt nødvendig.

Hva koster det å beholde begge, og hvor ligger besparelsene?#

Her er prisene for juni 2026 (data fra de offisielle abonnementssidene til Anthropic og OpenAI og den offisielle Codex-siden):

Minste fungerende kombinasjon: Claude Pro ($20) + ChatGPT Plus ($20) = $40/måned. Nok for soloprosjekter med et par økter om dagen.

En reell kombinasjon for en aktiv vibe coder: Claude Max 5x ($100) + ChatGPT Plus ($20) = $120/måned. I erfaringen som beskrives, ble denne kombinasjonen brukt de siste 2 månedene: i løpet av denne tiden ble tre prosjekter lansert, og Claude-grensene ble aldri nådd.

En kombinasjon for et team: Claude Max 20x ($200) + Codex Pro ($200) = $400/måned. Det gir mening når det er jevn strøm av PR-gjennomganger og skyoppgaver som kjører parallelt med lokalt arbeid.

Her kommer besparelsene fra:

• Mindre tid per funksjon. Forfatterens måling: for 12 funksjoner i mai-juni falt tiden fra «en idé dukket opp» til «i produksjon» fra 4 timer (én Claude Code) til 2.5 timer (kombinasjonen). Målt på forfatterens oppgaver; dine tall vil være annerledes.
• Færre feil. Ifølge observasjonene som beskrives, oppdager Codex PR-gjennomganger 2-3 av 10 problemer som Claude overser. Hvert slikt produksjonsproblem tar en time eller to å rette, i tillegg til mulig nedetid.
• Parallellitet. Codex jobber med funksjon A i skymodus mens brukeren jobber med Claude på funksjon B. Det dobler gjennomstrømningen.

Det lønner seg ikke hvis du skriver 1-2 funksjoner i uken. Da er én Claude Code Pro nok.

Når trenger du ikke et ekstra verktøy?#

Kombinasjonen passer ikke for alle. Ofte tilfører den bare støy. Her er fire situasjoner der du ikke trenger et ekstra verktøy:

1. Soloprosjekt i startfasen. Hvis du har én idé og bare tester den, holder det med én Claude Code + Plan Mode i en måned. Legg til kombinasjonen når du møter en flaskehals i tempoet.

2. Strengt budsjett. Hvis $20/måned er grensen, skaff deg Claude Pro og ikke bekymre deg for det. Claude alene dekker 80% av oppgavene til en vibe coder.

3. Enkel arkitektur. Et nettsted med et skjema, en bot med et par scenarioer, et skript som pakker inn et API—å dele opp etter lag tilfører ingenting her. Én Claude Code kan håndtere det.

4. Alt fungerer allerede. Hvis du har brukt Claude Code og ikke har hatt en eneste oppgave den har stått fast på eller mislyktes med den siste måneden, ikke fiks noe som fungerer. Legg til Codex når behovet blir tydelig.

Og omvendt—tydelige tegn på at det er på tide å hente inn et ekstra verktøy:

• Claude Code har blitt en flaskehals: du venter på den i stedet for å jobbe.
• Det har dukket opp mye standardarbeid med infrastruktur (migreringer, CI, tester) som du misliker å kjøre gjennom Claude.
• Ulike personer i teamet bruker allerede ulike verktøy—det trengs ett felles språk.
• Benchmarkene viser at Codex håndterer oppgavetypen din raskere (for eksempel terminaloperasjoner).

Slik setter du opp kombinasjonen på én kveld#

En konkret plan for den første kvelden:

1. Trinn 1: Installer Codex CLI

   I terminalen: npm install -g @openai/codex. Logg inn med codex login—en nettleser åpnes, og du logger inn med ChatGPT-kontoen din. Codex ser abonnementet ditt (Plus / Pro) og bruker grensene derfra.

2. Trinn 2: Skriv AGENTS.md som et operativt dokument

   Gjennomgå CLAUDE.md og gjenbruk reglene som gjelder begge verktøy i AGENTS.md: test- og lintkommandoer, commit-format, forbudte mapper og beskrivelse av teknologistakken. Samtalepreferanser kan også deles. Tilpass verktøyspesifikke kommandoreferanser, og behold kjørbare hook- og MCP-innstillinger i hvert verktøys egen konfigurasjon. En kopiert Markdown-fil alene konfigurerer dem ikke.

3. Trinn 3: Velg et mønster for prosjektet ditt

   Hvis du programmerer alene og har CI, bruk mønster 1 (Claude skriver, Codex gjennomgår). Hvis det er et nytt prosjekt og du trenger fart, bruk mønster 2 (Codex lager et utkast, Claude rydder opp). Hvis det er et etablert prosjekt med et infrastrukturlag, bruk mønster 3 (deling etter lag).

4. Trinn 4: Eksperimenter i én uke

   Bruk det valgte mønsteret på 5-7 funksjoner. Følg med på tiden. Noter hvilket verktøy som håndterte hver funksjon best. Etter en uke har du et reelt bilde av bruken din.

5. Trinn 5: Sett opp synkronisering av regler

   Legg til skriptet scripts/sync-agent-rules.sh (se avsnittet om synkronisering). Koble det til som en pre-commit-hook eller gjennom en GitHub Action. Deretter overføres reglene automatisk til begge filene.

Kombinasjonen er ingen magi. Det er ganske enkelt to hoder i stedet for ett, der hvert av dem dekker den andres svake punkter. Det viktigste er å ikke bli sittende fast i diskusjonen «Claude eller Codex» når det riktige svaret for lengst har vært «både Claude og Codex—for ulike typer oppgaver».

Praktisk materiale om å jobbe med agenter: Ailoot-dokumentasjon.

Mer materiale og verktøy: Ailoot.