Hvis du allerede bor inne i Claude Code, kjenner du til de åpenbare tingene (terminal-native, tight loop, se det kjøre, grep logger, patche, kjøre på nytt, commit). Så her er det mer interessante spørsmålet: hvorfor føles Codex som om den tar igjen uten bare å klone den interaktive terminalagent-stemningen? Codex er delegeringsførst, ikke parprogrammeringsførst. Claude Codes superkraft er den stramme interaktive kontrollsløyfen: Du og agenten deler én cockpit. Den er verdt å se på. Du griper inn midt i flyturen. Du styrer før tiden brenner ned en dårlig vei. Det er i bunn og grunn agent som en forlengelse av skallet ditt. Codex sitt veddemål er annerledes: agent som en parallell kollega som jobber på sin egen datamaskin Den innrammingen innebærer en rekke produktkonsekvenser som er lette å overse hvis du bare sammenligner modellutdata: 1) Asynkroni som funksjon (ikke en bieffekt) Codex er designet for at du skal overlate en oppgave, gjøre noe annet, og komme tilbake til en gjennomgangsbar gjenstand Tyngdepunktet blir PR/diff. Derfor ser du språk som «deleger», «overflodstankesett», «sett opp en haug med oppgaver». Arbeidsflyten er: spawn N jobber, så gjennomgå/slå sammen. 2) Isolasjon og sandkasse er ikke bare infrastruktur, det er UX. Hver oppgave som kjører i sitt eget isolerte miljø endrer tillitsmodellen: Agenten kan kjøre tester, endre filer, generere commits uten å forurense ditt lokale arbeidsområde. Du får sikkerhetsgrenser (og ofte konservative standarder) som gjør det lettere å la det bare gjøre det. 3) Sammenslåbarhet er det faktiske målmålet. Claude Code føles flott fordi løkken konvergerer. Mens Codex eksplisitt optimaliserer for når du kommer tilbake med noe du kan slå sammen. Slik blir formen på sammenligningen tydeligere: Claude Code = best når oppgaven krever vurderinger midt i strømmen, raske avbrudd og menneskelig styring. Det er «den trange cockpit-løkken». Codex = best når oppgaven kan delegeres, paralleliseres og returneres som sammenflettbare artefakter. Det er «kollega med eget arbeidsområde». Den dypere grensen er ikke autofullføringskvalitet. Det er ende-til-ende kontrollsløyfer med verifikasjon: kontekst -> plan -> redigeringer -> gjennomføring -> verifisering -> gjennomgåelig artefakt Og den virkelige vollgraven bygges ved verifisering og smak: - Kjører den de riktige testene? - tolker den CI-feil korrekt? - Gir det små differensialer som matcher repoets idiomer? - Returnerer den pålitelig noe du kan slå sammen uten barnepass? Mitt tips er at vi konvergerer mot en hybrid arbeidsflyt: interaktiv Claude Code-løkke for tvetydig arbeid + sandkassede parallelle Codex-jobber for gjennomstrømning. Vinneren er den som bygger den beste ruteren på tvers av disse modusene og får delegering til å føles like pålitelig som git-status.

Tinker fra Thinking Machines som GA er en av de første lanseringene på en stund som faktisk føles som trening som et produkt. De fleste hostede finjusterings-API-er (inkludert OpenAI-stil) er fantastiske når alt du trenger er en ren SFT-gjennomspilling, men i det øyeblikket du vil gjøre noe som helst litt spennende: egendefinerte læreplaner, nettevaluering, belønningsformet ettertrening, RL-aktige looper, rare batching-/pakkingstriks: du treffer taket raskt og ender opp med å bygge opp halve treningsstabelen på nytt. Tinker snur det egentlig på hodet: det gir deg et trenings-API med lavnivå-primitiver (sample / forward_backward / optim_step / save_state), så du skriver løkken du faktisk vil ha, og de tar seg av delene som vanligvis blir til en måneds infrastrukturarbeid (planlegging, skalering, preemptions, feilgjenoppretting, hvorfor døde denne jobben på 93 %-greiene). Det er også LoRA-først, som er akkurat riktig standard for tilpasning: du itererer raskere, kostnadene holder seg stabile, du kan beholde flere varianter uten å duplisere gigantiske sjekkpunkter, og servering blir mye mer praktisk. Jeg liker også at historien ikke er uklar: LoRA kan virkelig matche full finjustering på mange datasett etter trening når du setter det opp riktig, men hvis du prøver å presse inn en massiv atferdsendring i en liten adapter (eller datasettet ditt bare overskygger adapterens effektive kapasitet), vil du kjenne den flaskehalsen og den vil ikke forsvinne magisk. Den eneste reelle ulempen jeg ser er gulvet for små modeller: hvis målet ditt er små edge SLM-er, er dette sannsynligvis ikke verktøyet. Likevel er jeg spent på det. Gleder meg til å se hva folk bygger.

Etter tre år i CRV trer jeg inn i Striker Venture Partners' grunnleggerteam, hvor jeg leder firmaets AI-investeringer. Takk til @BusinessInsider for at du dekket flyttingen.