Claude Code eller Codex? Repository-testen bør afgøre abonnementet

Vælg Claude Code eller Codex efter de ændringer, teamet faktisk kan godkende i sit eget repository. Den bedste løsning er den, der løser jeres typiske opgaver inden for en acceptabel ramme for udviklertid og forbrug. En hurtig aflevering tæller mindre, hvis review afslører fejl, manglende tests eller et diff, der må skrives om.

Prøv derfor begge agenter på de samme afgrænsede opgaver, før I vælger abonnement. Bedøm både den første aflevering og arbejdet frem til en godkendelig ændring. Arbejdsformen skal også passe til teamet: Nogle opgaver kræver løbende afklaringer, mens andre egner sig til at blive afleveret som selvstændige ændringer til senere review.

Terminal, cloudopgaver og styring undervejs

Codex kan bruges direkte i projektmappen via CLI, og Codex Cloud kan køre opgaver på OpenAI-administrerede computere, mens udviklerens egen computer er slukket. OpenAI’s vejledning til Codex beskriver også, hvordan brugeren kan ændre retning under en kørsel eller lægge en besked i kø til næste kørsel. Cloudadgang afhænger af plan, udrulning og arbejdsområdets indstillinger, så adgang til Codex giver ikke automatisk adgang til den ønskede cloudopsætning.

Claude Code kan startes som en interaktiv session fra projektets terminal. Anthropics installationsvejledning angiver Pro, Max, Team, Enterprise og Console som adgangsveje og beskriver også brug via understøttede tredjepartsudbydere. Det gør den konkrete kørselsform til en del af købsprøven: En opgave med lokale tjenester og afhængigheder bør afprøves i det miljø, hvor den senere skal løses.

Registrér, hvornår en udvikler må gribe ind, og hvad indgrebet tilfører. Et spørgsmål fra agenten kan spare en forkert refaktorering, hvis kravene er uklare. Ved en velafgrænset fejlretning kan den samme pause derimod være ekstra arbejdstid. Begge typer tid hører med i vurderingen af, hvilken arbejdsgang teamet vil bruge.

Hvad koster en godkendt ændring?

OpenAI’s Codex-side viser amerikanske listepriser på 20 dollar om måneden for ChatGPT Plus, 100 dollar for Pro og 20 dollar pr. bruger om måneden for Business ved årlig betaling og mindst to pladser. Codex er inkluderet i planerne, men brugsrammen varierer. Det er derfor utilstrækkeligt at sammenligne pladsprisen alene, hvis teamets opgaver kræver en højere plan eller ekstra forbrug.

Anthropics prisside viser Claude Pro til 20 dollar ved månedsbetaling, Max fra 100 dollar om måneden og en Team-standardplads til 20 dollar pr. måned ved årlig betaling. Claude Code indgår i de betalte planer, og brug i Claude Code og andre Claude-flader trækker på samme forbrugsramme. Prissiderne viser beløb i dollar; et dansk teams faktiske betaling afhænger også af de vilkår og den pris, der vises ved køb.

Den relevante enhed er en ændring, der kan sendes videre efter review. Medregn tiden til at skrive opgaven, besvare spørgsmål, undersøge diffet og rette fejl samt det forbrug, der går til genkørsler. En billig plads kan blive et dårligt køb, hvis de fleste ændringer kræver meget efterarbejde. En dyrere plan giver omvendt kun mening, hvis den ekstra kapacitet bliver brugt på opgaver, der skaber værdi.

Hvad kan en offentlig tokenmåling fortælle?

En gennemgang hos Zapier gengiver en Figma-til-kode-måling, hvor Claude Code brugte omkring 6,2 millioner tokens og Codex omkring 1,5 millioner. Det er tal for den omtalte opgave og opsætning. Den større Claude Code-leverance blev beskrevet som mere omfattende, så tokenforskellen kan ikke i sig selv afgøre, hvilken løsning der ville bestå review i et andet repository.

Tokenforbrug er alligevel nyttigt at registrere, når værktøjernes målinger kan aflæses. En agent kan bruge flere tokens på at undersøge kodebasen og skrive tests, mens en anden hurtigt afleverer et mindre diff. Resultatet skal holdes op mod acceptkriterierne: Hvis begge ændringer godkendes, bliver forbrug og tid afgørende; hvis kun den ene består, er et lavt tokenantal ikke nok.

Modelversion, tilladte værktøjer, adgang til filer og opgavens formulering påvirker sammenligningen. Notér derfor konfigurationen sammen med resultatet, så en senere ændring i model eller plan ikke forveksles med en stabil egenskab ved agenten. Hvis tjenesterne viser forbrug i forskellige enheder, bør tallene bevares hver for sig frem for at blive lagt sammen til en misvisende fælles score.

Fem opgaver fra det repository, der skal arbejdes i

Vælg opgaver, der ligner ændringer, teamet normalt sender til review. Beskriv forventet adfærd og godkendelseskriterier, før agenterne starter. Opgaverne skal være afgrænsede nok til, at en reviewer kan vurdere både kode, tests og eventuelle sideændringer.

1. Fejlretning: Giv begge agenter den samme reproducerbare fejl. En godkendelig ændring skal rette adfærden og have en test, der kan påvise fejlen før rettelsen.
2. Refaktorering: Vælg en kodevej med kendt adfærd. Bedøm, om strukturen bliver klarere, mens eksisterende kontrakter og relevante tests bevares.
3. Testskrivning: Brug en eksisterende funktion med svag testdækning. Se efter relevante grænsetilfælde og tests, der ville afsløre en reel regression.
4. Dokumentation: Vælg en funktion eller opsætning, som teamet faktisk skal forklare. Kontroller, om kommandoer, forudsætninger og eksempler passer til repositoryet.
5. Ny funktion: Beskriv en lille ændring med tydelige input, output og acceptkriterier. Vurder funktionen, dens tests og om diffet er overskueligt at gennemgå.

De forskellige opgaver viser mere end én samlet karakter ville gøre. En agent kan være stærk til veldefinerede fejl, men kræve flere afklaringer ved en refaktorering. En anden kan skrive læsbar dokumentation, men overse grænsetilfælde i tests. Vægt derfor opgaverne efter den type arbejde, teamet faktisk forventer at give agenten.

En sammenlignelig prøve før køb

Start hver opgave fra samme commit i hver sin rene gren. Giv agenterne samme opgavebeskrivelse, adgang til relevante filer og mulighed for at køre de samme tests. Hvis en cloudopgave mangler en lokal tjeneste eller en nødvendig afhængighed, skal forskellen registreres som et forhold ved kørselsformen.

Fastlæg en stopregel for tid eller forbrug på forhånd, og gem den første afleverede ændring. Registrér derefter særskilt, hvor mange afklaringer og rettelsesrunder der kræves, før den kan godkendes. Mål den samlede forløbstid, udviklerens aktive tid, testresultater og reviewkommentarer; de tal viser, hvor agentens arbejde sparer tid, og hvor det flytter arbejde til revieweren.

Lad om muligt den samme reviewer bedømme ændringerne efter de samme kriterier uden først at kende agentens navn. Gentag især opgaver, hvor resultaterne ligger tæt, så én heldig kørsel ikke afgør et tilbagevendende abonnement. Vælg den plan og kørselsform, der giver flest godkendelige ændringer inden for teamets reelle tids- og forbrugsramme.

Læs også:

• ChatGPT, Claude eller Gemini til 20 dollar? Pakken afgør valget
• Claude Team eller ChatGPT Business? Fem sæder ændrer startprisen
• Proton Mail eller Tuta? Mailklienten kan afgøre mere end krypteringen