Si vous vivez déjà à l'intérieur de Claude Code, vous connaissez les choses évidentes (natif du terminal, boucle serrée, regardez-le fonctionner, grep logs, patch, relancez, commit). Alors voici la question plus intéressante : pourquoi Codex a-t-il l'impression de rattraper son retard sans simplement cloner l'ambiance de l'agent terminal interactif ? Codex est axé sur la délégation, pas sur le pair-programming. Le superpouvoir de Claude Code est la boucle de contrôle interactive serrée : vous et l'agent partagez un seul cockpit. C'est regardable. Vous intervenez en plein vol. Vous dirigez avant qu'il ne perde du temps sur un mauvais chemin. C'est essentiellement l'agent comme une extension de votre shell. Le pari de Codex est différent : l'agent comme un collègue parallèle qui travaille sur son propre ordinateur. Cette approche implique un certain nombre de conséquences produit qui sont faciles à manquer si vous ne comparez que les sorties des modèles : 1) L'asynchronie comme une fonctionnalité (et non un effet secondaire) Codex est conçu pour que vous puissiez déléguer une tâche, faire autre chose, puis revenir à un artefact révisable. Le centre de gravité devient les PRs/diff. C'est pourquoi vous voyez des termes comme "déléguer", "mentalité d'abondance", "mettre en file d'attente un tas de tâches". Le flux de travail est : lancer N jobs, puis réviser/fusionner. 2) L'isolation et le sandboxing ne sont pas seulement une infrastructure, c'est une expérience utilisateur. Chaque tâche exécutée dans son propre environnement isolé change le modèle de confiance : L'agent peut exécuter des tests, modifier des fichiers, générer des commits sans contaminer votre espace de travail local. Vous obtenez des limites de sécurité (et souvent des valeurs par défaut conservatrices) qui facilitent le fait de le laisser faire. 3) La fusion est la véritable métrique cible. Claude Code est agréable parce que la boucle converge. Alors que Codex optimise explicitement pour revenir avec quelque chose que vous pouvez fusionner. Ainsi, la forme de la comparaison devient plus claire : Claude Code = meilleur lorsque la tâche nécessite des jugements en cours de route, des interruptions rapides et une direction humaine. C'est la "boucle de cockpit serrée". Codex = meilleur lorsque la tâche peut être déléguée, parallélisée et retournée sous forme d'artefacts fusionnables. C'est "un collègue avec son propre espace de travail". La véritable frontière n'est pas la qualité de l'autocomplétion. C'est des boucles de contrôle de bout en bout avec vérification : contexte -> plan -> modifications -> exécution -> vérification -> artefact révisable. Et le véritable rempart se construit à la vérification et au goût : - exécute-t-il les bons tests ? - interprète-t-il correctement les échecs CI ? - produit-il de petits diffs qui correspondent aux idiomes de votre dépôt ? - renvoie-t-il de manière fiable quelque chose que vous pouvez fusionner sans surveillance ? Je parie que nous convergerons vers un flux de travail hybride : boucle interactive de Claude Code pour un travail ambigu + jobs Codex parallèles en sandbox pour le débit. Le gagnant est celui qui construit le meilleur routeur entre ces modes et rend la délégation aussi fiable que git status.

Tinker de Thinking Machines étant en GA est l'un des premiers lancements depuis un certain temps qui ressemble réellement à un produit de formation. La plupart des API de fine-tuning hébergées (y compris celles de style OpenAI) sont géniales quand tout ce dont vous avez besoin est un SFT propre, mais dès que vous voulez faire quoi que ce soit d'un peu épicé : des programmes personnalisés, une évaluation en ligne, un post-entraînement basé sur des récompenses, des boucles de type RL, des astuces de batching/packing étranges : vous atteignez rapidement le plafond et vous finissez par reconstruire la moitié d'une pile de formation. Tinker renverse essentiellement cela : il vous fournit une API de formation avec des primitives de bas niveau (échantillon / forward_backward / optim_step / save_state), vous permettant d'écrire la boucle que vous souhaitez réellement, et ils s'occupent des parties qui se transforment normalement en un mois de travail d'infrastructure (planification, mise à l'échelle, préemptions, récupération après échec, le pourquoi ce travail est mort à 93 %). C'est aussi LoRA-first, ce qui est exactement le bon défaut pour la personnalisation : vous itérez plus rapidement, les coûts restent raisonnables, vous pouvez garder plusieurs variantes sans dupliquer d'énormes points de contrôle, et le service devient beaucoup plus pratique. J'aime aussi que l'histoire ne soit pas floue : LoRA peut vraiment égaler le fine-tuning complet sur de nombreux ensembles de données post-entraînement lorsque vous le configurez correctement, mais si vous essayez de faire entrer un changement de comportement massif dans un petit adaptateur (ou si votre ensemble de données dépasse simplement la capacité effective de l'adaptateur), vous ressentirez ce goulet d'étranglement et il ne disparaîtra pas magiquement. Le seul véritable inconvénient que je vois est le seuil des petits modèles : si votre objectif est de petits SLMs de périphérie, ce n'est probablement pas l'outil. Néanmoins, je suis enthousiaste à ce sujet. J'ai hâte de voir ce que les gens vont construire.

Après trois ans chez CRV, je rejoins l'équipe fondatrice de Striker Venture Partners, en dirigeant les investissements de la société dans l'IA. Merci à @BusinessInsider pour avoir couvert ce changement.