Wenn du bereits im Claude Code lebst, kennst du die offensichtlichen Dinge (terminal-nativ, enger Loop, beobachte es laufen, Protokolle durchsuchen, patchen, erneut ausführen, committen). Also hier ist die interessantere Frage: Warum fühlt sich Codex so an, als würde es aufholen, ohne einfach die interaktive Terminal-Agenten-Atmosphäre zu klonen? Codex ist delegationsorientiert, nicht pair-programming-orientiert. Die Superkraft von Claude Code ist der enge interaktive Kontrollloop: du und der Agent teilen sich ein Cockpit. Es ist beobachtbar. Du greifst mitten im Flug ein. Du steuerst, bevor es Zeit auf einem schlechten Weg verbrennt. Es ist im Grunde der Agent als Erweiterung deiner Shell. Codex’ Wette ist anders: Agent als paralleler Kollege, der auf seinem eigenen Computer arbeitet. Diese Rahmenbedingungen implizieren eine Reihe von Produktfolgen, die leicht übersehen werden können, wenn man nur die Ausgaben der Modelle vergleicht: 1) Asynchronität als Feature (nicht als Nebenwirkung) Codex ist so konzipiert, dass du eine Aufgabe übergibst, etwas anderes machst und zu einem überprüfbaren Artefakt zurückkommst. Der Schwerpunkt liegt auf PRs/Diffs. Deshalb siehst du Begriffe wie „delegieren“, „Abundanz-Mindset“, „eine Reihe von Aufgaben anstellen“. Der Workflow ist: N Jobs starten, dann überprüfen/zusammenführen. 2) Isolation und Sandboxing sind nicht nur Infrastruktur, sondern UX. Jede Aufgabe, die in ihrer eigenen isolierten Umgebung läuft, verändert das Vertrauensmodell: Der Agent kann Tests ausführen, Dateien ändern, Commits generieren, ohne deinen lokalen Arbeitsbereich zu kontaminieren. Du erhältst Sicherheitsgrenzen (und oft konservative Standards), die es einfacher machen, es einfach zuzulassen. 3) Mergeability ist die tatsächliche Zielmetrik. Claude Code fühlt sich großartig an, weil der Loop konvergiert. Während Codex explizit darauf optimiert, etwas zurückzubringen, das du zusammenführen kannst. Die Form des Vergleichs wird klarer: Claude Code = am besten, wenn die Aufgabe mid-stream Urteilsentscheidungen, schnelle Unterbrechungen und menschliches Steuern benötigt. Es ist der „enge Cockpit-Loop“. Codex = am besten, wenn die Aufgabe delegiert, parallelisiert und als zusammenführbare Artefakte zurückgegeben werden kann. Es ist „Kollege mit eigenem Arbeitsbereich“. Die tiefere Grenze ist nicht die Qualität der Autovervollständigung. Es sind End-to-End-Kontrollloops mit Verifizierung: Kontext -> Plan -> Änderungen -> Ausführung -> Verifizierung -> überprüfbares Artefakt Und der echte Graben wird bei Verifizierung und Geschmack gebaut: - Führt es die richtigen Tests aus? - Interpretiert es CI-Fehler korrekt? - Produziert es kleine Diffs, die den Idiomen deines Repos entsprechen? - Gibt es zuverlässig etwas zurück, das du ohne Aufsicht zusammenführen kannst? Mein Verdacht ist, dass wir zu einem hybriden Workflow konvergieren: interaktiver Claude Code Loop für mehrdeutige Arbeiten + sandboxed parallele Codex-Jobs für Durchsatz. Der Gewinner ist, wer den besten Router über diese Modi baut und die Delegation so zuverlässig macht wie git status.

Tinker von Thinking Machines, das GA ist, gehört zu den ersten Veröffentlichungen seit einiger Zeit, die sich tatsächlich wie Training als Produkt anfühlen. Die meisten gehosteten Fine-Tune-APIs (einschließlich OpenAI-Stil) sind großartig, wenn alles, was Sie brauchen, ein sauberer SFT-Lauf ist, aber sobald Sie auch nur etwas Gewagtes tun möchten: benutzerdefinierte Lehrpläne, Online-Bewertungen, belohnungsgeformtes Post-Training, RL-ähnliche Schleifen, seltsame Batch-/Packtricks: stoßen Sie schnell an die Grenzen und müssen die Hälfte eines Trainingsstacks neu aufbauen. Tinker kehrt das im Grunde um: Es gibt Ihnen eine Trainings-API mit Low-Level-Primitiven (sample / forward_backward / optim_step / save_state), sodass Sie die Schleife schreiben, die Sie tatsächlich wollen, und sie kümmern sich um die Teile, die normalerweise in einen Monat Infrastrukturarbeit umschlagen (Planung, Skalierung, Unterbrechungen, Fehlerbehebung, das Warum ist dieser Job bei 93% gestorben). Es ist auch LoRA-first, was genau das richtige Standard für Anpassungen ist: Sie iterieren schneller, die Kosten bleiben im Rahmen, Sie können mehrere Varianten behalten, ohne riesige Checkpoints zu duplizieren, und das Bereitstellen wird viel praktischer. Ich mag auch, dass die Geschichte nicht vage ist: LoRA kann wirklich mit vollem Fine-Tuning auf vielen Post-Training-Datensätzen mithalten, wenn Sie es richtig einrichten, aber wenn Sie versuchen, einen massiven Verhaltenswechsel in einen kleinen Adapter zu quetschen (oder Ihr Datensatz einfach die effektive Kapazität des Adapters übersteigt), werden Sie diesen Engpass spüren und er wird nicht magisch verschwinden. Der einzige echte Nachteil, den ich sehe, ist die kleine Modellgrenze: Wenn Ihr Ziel winzige Edge-SLMs sind, ist dies wahrscheinlich nicht das richtige Werkzeug. Trotzdem bin ich gespannt darauf. Ich kann es kaum erwarten zu sehen, was die Leute bauen.

Nach drei Jahren bei CRV trete ich dem Gründungsteam von Striker Venture Partners bei und leite die KI-Investitionen der Firma. Danke an @BusinessInsider für die Berichterstattung über den Wechsel.