📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Your Apps Don't Need an API Anymore. Codex Just Proved It.

AI News & Strategy Daily | Nate B Jones21:00

Transcription

OpenAI a complètement remanié Codeex et je suis époustouflé par l'utilité de cette nouvelle application. Le 16 avril, OpenAI a transformé Codeex en un agent de bureau qui contrôle chaque application de votre Mac. Clics, frappes, fonctionnement en arrière-plan pendant que vous travaillez. C'est plus rapide et plus fiable que la version de Claw de l'utilisation de l'ordinateur, et ce, avec une marge beaucoup plus grande que ce que j'attendais. Cela importe car la plupart des logiciels d'entreprise ne disposent pas d'API modernes, et Codeex n'en a pas besoin. Je vais vous expliquer ce qu'est Codeex maintenant, comment il est devenu si bon, ce qu'OpenAI construit réellement, et où les deux laboratoires vont, et bien sûr, ce que vous devriez faire à ce sujet. La raison de prêter attention va plus loin que l'écart de capacité. Dans une récente interview avec Ashley Vance, Greg Brockman a déclaré : « Les modèles sont passés d'être le produit à faire partie du produit. » Je pense qu'il a raison. Le cerveau est effectivement construit. Le travail actuel des hyperscalers porte sur le corps. Les deux laboratoires ont décidé que le corps est la priorité numéro un, mais ils construisent des approches très différentes. Et la sortie d'avril de Codex montre cette scission très clairement. Laissez-moi commencer par ce qu'est Codex maintenant. Lorsque OpenAI a lancé l'outil original en ligne de commande Codeex en avril 2025, c'était un outil en ligne de commande pour les développeurs. Vous tapiez des invites. Il écrivait du code. C'était essentiellement tout le produit. Un an plus tard, Codeex est devenu une application de bureau complète qui peut voir votre écran, cliquer et taper sur le Mac, générer des images, naviguer sur le web dans son propre navigateur intégré, se souvenir de ce sur quoi vous avez travaillé, se programmer pour se réveiller sur des tâches de longue durée, et exécuter plusieurs agents en parallèle sans détourner ce que vous faites. La transformation s'est déroulée par étapes, mais vous pouvez voir la direction. Le 2 février, l'application de bureau Mac OS a été lancée. Le 4 mars, prise en charge de Windows. Le 5 mars, GPT 5.4 pour intégrer la capacité de codage de Codeex dans la ligne de modèles à usage général. Le 19 mars, OpenAI a confirmé le plan de consolidation de la super application. Le 16 avril, la sortie qui a fait de Codex ce qu'il est aujourd'hui était entièrement axée sur l'utilisation de l'ordinateur, le navigateur intégré, la génération d'images, la mémoire, et plus de 90 nouveaux plugins dans une seule application. Le cœur de cette transformation est l'utilisation de l'ordinateur. Codex peut utiliser n'importe quelle application Mac OS en voyant simplement votre écran et en cliquant et en tapant comme une personne. Il le fait en arrière-plan, ce qui signifie que plusieurs agents peuvent fonctionner en parallèle pendant que vous travaillez sur autre chose. Ce n'est pas une mise à jour de fonctionnalité. C'est en fait Codeex qui déplace la catégorie. Codeex n'est plus vraiment un outil de codage. C'est un agent de bureau qui peut faire tout ce qu'une personne peut faire via une interface graphique. Et oui, il code toujours aussi. Est-ce que ça marche vraiment ? Oui, et de deux manières spécifiques qui comptent. J'ai fait fonctionner Codeex et Claude côte à côte sur les mêmes flux de travail depuis environ une semaine. Et voici ce que je vois. Codeex est rapide. Il parcourt un flux de travail à une vitesse proche de celle d'une personne qui connaît déjà ce logiciel. La version de Claude est plus lente, comme si le curseur hésitait, l'agent réfléchissait et parfois réessayait. Les tâches qui se terminent en 2 minutes sur Codeex peuvent prendre cinq ou six sur Claude. Et Claude est limité dans ses déplacements. Claude préfère Chrome. Codeex peut toucher n'importe quoi sur le bureau. L'écart n'est donc pas subtil. Codeex est également fiable. Le mode d'échec des produits d'utilisation d'ordinateur depuis plus d'un an a été très spécifique. L'agent parcourt une partie de la tâche, rencontre une boîte de dialogue modale inattendue ou un autre problème, trébuche, et vous devez prendre le relais et redémarrer, et alors pourquoi le faire du tout ? L'implémentation de Codeex, en général, ne trébuche pas. Il fait marche arrière quand il le faut. Il termine, et il le fait rapidement. C'est ce qui fait passer la capacité de démonstration impressionnante à « je pourrais vraiment utiliser ça ». Sam a dit quelque chose dans une récente interview d'Ashley Vance qui correspond à ce que j'ai vu. Interrogé sur Codeex par rapport à Claude aujourd'hui, sa lecture était : « Notre produit a de l'avance à bien des égards. » Bien sûr, il a dit ça. Mais sur l'utilisation de l'ordinateur spécifiquement, je suis d'accord avec lui. Une partie de cet écart provient du modèle. GPT 5.4 est le premier modèle à usage général qu'OpenAI a lancé avec des capacités d'utilisation d'ordinateur natives intégrées. Il obtient des benchmarks dans les mid-70 sur OS World, ce qui le place au-dessus de la base humaine pour le contrôle de l'interface utilisateur graphique. C'est exact, meilleur que les humains. Mais le modèle n'est pas toute l'histoire. Alexander Emiricos, qui travaille sur l'équipe Codeex chez OpenAI, a qualifié l'implémentation de l'utilisation d'ordinateur en arrière-plan de « sorcellerie profonde au niveau du système d'exploitation ». Je le ressens quand je l'utilise. Le choix architectural spécifique auquel il faisait référence est que les agents en arrière-plan ne détournent pas votre curseur et ne volent pas le focus de l'application sur laquelle vous travaillez. Vous pouvez continuer à taper dans une fenêtre pendant qu'un agent clique dans une autre. C'est ce qui rend les agents parallèles réellement utilisables au lieu d'être théoriques. Trois agents Codeex sur trois tâches sans rapport. Vous pouvez vous éloigner. Vous pouvez revenir 20 minutes plus tard. Les trois tâches sont terminées. Et cela a changé ma façon de planifier ma journée. Ce n'est pas seulement moi. Depuis la sortie, les premiers utilisateurs sur X publient leurs premiers vrais flux de travail avec Codeex. Et la gamme de ce qui fonctionne est plus large que ce à quoi je m'attendais. Des choses comme le nettoyage de masse de Slack, n'est-ce pas ? Lire et trier des centaines de messages de bots non lus et des digests quotidiens pour que la boîte de réception soit propre. Ou construire une playlist Spotify en pilotant l'application de bureau à partir d'une description verbale. Ou parcourir une application front-end pour détecter les régressions visuelles pendant que le développeur continue d'expédier la prochaine fonctionnalité. ou reproduire un bug de navigateur, capturer une capture d'écran de la reproduction, coller les images directement dans la description d'une pull request, ou exécuter des tests de bout en bout sur l'application que vous venez de construire, puis auto-corriger les problèmes qu'elle trouve, ou piloter un tableau de bord interne hérité qui n'a jamais eu d'API, exactement la catégorie logicielle que l'automatisation a abandonnée depuis des années. Une personne a mis en place un récapitulatif quotidien qui extrait les commits git, les mises à jour du tracker d'incidents et les événements du calendrier, écrit les minutes de réunion dans Notion, puis dépose des tâches prioritaires dans les rappels Apple. Une autre personne a fait jouer à Codex des routines de connexion quotidiennes en arrière-plan pour ne pas avoir à le faire. Une autre détecte quand l'utilisateur se tient mal devant sa webcam et ouvre une vidéo d'étirement. Aucune de ces choses n'est une démo. Ce sont de vrais flux de travail que les gens ont exécutés et ont ensuite décidé de continuer à exécuter. Et c'est le signe révélateur. L'utilisation de l'ordinateur cesse d'être une nouveauté lorsque vous y revenez une deuxième fois. Et c'est vraiment la ligne que Codeex a franchie. Un agent de bureau qui peut piloter n'importe quelle application Mac fonctionne en arrière-plan et termine réellement le travail est le rêve. Ce qui nous amène à la suite. Qu'est-ce qu'OpenAI construit réellement avec ce lancement ? Et pourquoi cela semble-t-il si différent de ce que fait Enthropic ? Enthropic a pivoté hors de la boîte de codage en premier. En janvier, ils ont lancé co-work dans l'application de bureau Claw existante. Co-work est du code pour les personnes qui n'écrivent pas de code. Vous pointez l'agent vers un dossier sur votre Mac, décrivez ce que vous voulez faire, et il effectue un travail de connaissance en plusieurs étapes pour vous. À partir de là, ce furent des mouvements composés, n'est-ce pas ? ajout de plugins, tâches planifiées, utilisation de l'ordinateur et aperçu de recherche sur Mac. Et puis sous Windows, dispatch qui vous permet d'assigner des tâches depuis votre téléphone. Et en avril, l'application Claw Desktop contient trois modes sur une seule surface, n'est-ce pas ? Elle a le chat pour la discussion, le travail de connaissance co-work, et le code pour le logiciel, plus une couche de plugins pour des capacités spécialisées comme Claw Design. Les deux laboratoires ont fait le même mouvement de haut niveau. Tous deux sont sortis de la boîte de codage. Tous deux ont construit des applications de bureau, mais ils n'ont pas bougé dans la même direction. Anthropic a pivoté vers le travail de connaissance, vers la synthèse, la recherche, l'écriture, l'analyse, le type de travail où vous définissez un résultat et l'agent effectue le travail intellectuel. OpenAI a pivoté vers quelque chose de plus large. Sam Alman a admis dans l'interview Vance qu'OpenAI avait commencé l'année derrière Anthropic sur les données de codage du monde réel. Il a accordé à Anthropic un vrai crédit pour avoir été plus tôt et a dit qu'OpenAI n'avait apprécié l'écart qu'avec le recul. Mais quand OpenAI a fait son mouvement, ils ont élargi. Dans la même interview, Brockman a décrit les vecteurs stratégiques d'OpenAI, la plateforme Agentic, le travail informatique spécifiquement, et l'AGI personnelle qui fait des choses pour vous dans le monde réel. Et il a tracé une ligne entre le travail de connaissance et le travail informatique. Le travail informatique est plus large. C'est tout ce qui se passe sur un ordinateur, qu'il nécessite ou non une connaissance approfondie. Travail d'exploitation, travail créatif, recherche, automatisation. Le travail de connaissance se situe à l'intérieur de cette surface, mais la surface est en fait plus grande. Cette différence d'ouverture se reflète directement dans le mécanisme que chaque laboratoire a choisi. Si le modèle est le cerveau et le travail est le corps, de quoi est fait le corps est la question ici. Pour Enthropic, il s'agit d'interfaces structurées, d'opérations de fichiers et de co-work, de serveurs MCPU, de connecteurs, des plus de 30 000 intégrations déjà dans l'écosystème cloud. Et Conway, l'environnement d'agent toujours actif qui a fuité début avril avec sa propre interface utilisateur latérale, son propre format d'extension, des déclencheurs webhook, le contrôle du navigateur, etc. Tout cela est une excellente architecture. Vraiment. Mais cela dépend aussi de la coopération de l'écosystème. Chaque serveur MCP doit être construit par quelqu'un. Chaque connecteur doit être entretenu. Chaque webhook doit être configuré. La portée du corps dépend entièrement de la rapidité avec laquelle le monde expédie des interfaces prêtes pour les agents. OpenAI construit un corps différent. Le corps d'OpenAI est l'utilisation de l'ordinateur. L'agent pilote la même interface graphique que vous pilotez. Et cela change complètement les calculs car la portée du corps est maintenant limitée par la quantité de logiciels qui ont une interface graphique, ce qui est effectivement tout. Les logiciels d'entreprise hérités fonctionnent. Les outils internes fonctionnent. Le SaaS qui ne construira jamais de serveur MCP fonctionne. Le portail vendeur que votre équipe d'exploitation tolère fonctionne. L'application que votre entreprise a construite en 2019 et n'a plus jamais touchée fonctionne. OpenAI n'a pas besoin que l'industrie du logiciel construise pour les agents. Le corps utilise simplement ce qui est déjà là. Les deux produits se ressemblent sur une matrice de fonctionnalités, mais les corps sous-jacents, la façon dont les agents sont connectés aux harnais. Ce n'est pas la même chose. Et vous pouvez le voir dans la façon dont les deux applications sont façonnées. L'application Claude d'Anthropic est construite comme un outil qui suppose que vous connaissez le travail que vous faites. Chaque mode a un modèle d'autorisation de portée et lorsque vous ouvrez co-work, il vous demande de pointer vers un dossier avant de faire quoi que ce soit. Cette friction est le choix du produit. Elle communique ce qui va se passer afin que vous puissiez être délibéré. L'ensemble de l'application est explicite de la manière dont l'est le reste de la stratégie d'Anthropic. Portées explicites, autorisations explicites, interfaces explicites. L'application Codeex d'OpenAI est le contraire. Elle est construite comme un outil qui suppose que vous ne voulez pas penser aux modes. Vous décrivez le résultat. L'agent décide s'il faut ouvrir des fichiers, s'il faut piloter une interface utilisateur graphique, exécuter un plugin, naviguer sur le web ou écrire du code. L'utilisation de l'ordinateur est la sortie de secours lorsque rien d'autre ne fonctionne. Les plugins sont des bundles opinionnés invoqués sans sélection explicite. La mémoire maintient le contexte entre les tâches, et l'application est implicite de la même manière que le reste de Codeex. L'agent détermine quoi faire car vous ne devriez pas avoir à lui dire quelle interface utiliser. C'est ce qu'OpenAI construit réellement. Un corps qui n'a pas besoin que le monde coopère. Un produit qui ne vous demande pas de penser en modes. Une feuille de route où le modèle est l'entrée et le corps est l'ensemble du produit. Ce qui laisse la question, comment Codeex en est-il arrivé là ? L'utilisation de l'ordinateur par Codeex ne vient de nulle part. Elle provient d'une équipe qu'OpenAI a achetée 6 mois avant la sortie d'avril. En octobre 2025, OpenAI a acquis une entreprise de 12 personnes appelée Software Applications Incorporated. L'entreprise était l'équipe derrière Sky, une interface IA native Mac OS non publiée qui faisait essentiellement ce que fait maintenant l'utilisation de l'ordinateur par Codeex. Les 12 membres ont rejoint OpenAI. L'un des cofondateurs, Ariestein, est maintenant designer chez OpenAI. Et lorsque Codeex a été lancé, il a publiquement crédité son équipe par son nom pour le travail sur le mouvement du curseur. Le détail spécifique qui fait que l'utilisation de l'ordinateur en arrière-plan ressemble à un co-travail plutôt qu'à un logiciel malveillant. Qu'est-ce qui rend cette équipe unique ? Weinstein et son cofondateur Conrad Kramer ont précédemment créé Workflow, l'application d'automatisation iOS qu'Apple a acquise en 2017 et transformée en Raccourcis. Raccourcis est maintenant la couche d'automatisation au niveau du système sur iOS, iPad OS et Mac OS. Le troisième cofondateur de Skye, Kim Bever, a passé 10 ans chez Apple en tant que chef de projet senior travaillant sur Safari, WebKit, Confidentialité, Messages, Mail, Téléphone, FaceTime et SharePlay. C'est plus d'une décennie de construction de l'ensemble des compétences qui fait que l'utilisation de l'ordinateur par Codeex fonctionne comme elle le fait. Intégration profonde de Mac OS, accessibilité et enregistrement d'écran, gestion des autorisations, trajectoires de mouvement qui ne semblent pas robotiques, le type de travail au niveau du système d'exploitation qui demande des années d'expérience Apple pour être bien fait. La ligne de Workflow à Raccourcis à Sky à Codeex, elle n'existe qu'à un seul endroit avec cette équipe. OpenAI l'a payée et le retour sur investissement est dans la sortie du 16 avril. La sorcellerie profonde au niveau du système d'exploitation qu'Embaros a décrite n'est pas une métaphore. C'est la connaissance spécifique accumulée d'une équipe spécifique appliquée maintenant à un produit où cela compte commercialement. Le même schéma se retrouve ailleurs. L'acquisition de Recept par Anthropic plus tôt cette année, l'équipe qui a lancé le contrôle de bureau Windows de Claude dans les 4 semaines suivant son arrivée. C'est un mouvement parallèle de leur côté. Ensuite, il y a IO Johnny Ives, la startup matérielle qu'OpenAI a achetée pour plusieurs milliards de dollars, qui est la version plus grande de la même chose. Les laboratoires dépensent essentiellement en expertise humaine étroite et difficile à reproduire, pas pour la propriété intellectuelle, souvent pas pour le produit, pour l'équipe. C'est un schéma cohérent. Les modèles commencent à converger. Les capacités qui prenaient auparavant 2 ans peuvent maintenant être reproduites en 6 mois ou moins. Ce qui n'est pas en train d'être commoditisé, c'est une équipe spécifique avec une histoire spécifique. Ces équipes sont une ressource très rare dans la vallée en ce moment. Si vous observez la compétition entre laboratoires, le schéma d'acquisition vous en dit autant sur l'endroit où l'avantage résidera que les scores de benchmark. Donc, nous savons ce qu'est Codeex. Nous savons ce qu'OpenAI construit réellement et nous savons comment Codeex est devenu si bon. La dernière grande question est la suivante. Où vont les deux laboratoires à partir d'ici ? Les deux laboratoires convergent vers la même destination : un agent persistant, ambiant, piloté par événements, et qui fonctionne sur toutes vos surfaces, et qui fait des choses en votre nom sans que vous ayez à le solliciter à chaque fois. Les deux signaux les plus clairs sur la façon dont chaque laboratoire prévoit d'y parvenir sont Chronicle et Conway. Chronicle est la dernière étape d'OpenAI. Ils l'ont lancé le 20 avril, 4 jours après la sortie principale, en avant-première de recherche pour les utilisateurs de Chat GPT Pro sur Mac OS. Chronicle capture votre écran périodiquement et traite les images sur les serveurs OpenAI et écrit des fichiers de mémoire locaux en markdown que Codex tire dans les sessions futures comme contexte. Tibo, qui dirige Codex, l'a qualifié de précoce et gourmand en tokens, mais a déclaré qu'il avait changé sa façon de travailler et celle de nombreuses personnes chez OpenAI. Altman l'a décrit comme télépathique, qu'est-ce que Chronicle fait réellement ici ? La lecture superficielle est qu'il s'agit d'une fonctionnalité de mémoire ambiante. La lecture plus profonde est qu'il s'agit du signal d'entraînement pour l'utilisation de l'ordinateur. Si votre agent doit piloter la même interface graphique que vous, il bénéficie énormément de regarder comment vous la pilotez. Chronicle est la couche qui rend la conduite de votre logiciel plus intelligente au fil du temps. Ainsi, vos flux de travail, vos préférences d'application, vos modèles de mémoire musculaire, tout cela devient le contexte dont l'agent hérite. Le compromis en matière de confidentialité est que les captures d'écran sont envoyées aux serveurs OpenAI. Ils ont des mémoires locales non chiffrées et ne sont donc pas disponibles dans l'UE, au Royaume-Uni ou en Suisse. Et c'est un coût qu'OpenAI a accepté car la fonctionnalité fonctionne mieux avec, et parce que les données rendent l'agent meilleur pour piloter votre logiciel au fil du temps. Conway est un type de signal différent. Le 1er avril, Anthropic a accidentellement publié le code source de Clawed Code, environ 500 000 lignes de TypeScript, lorsqu'une erreur d'empaquetage l'a poussé vers un registre public. Enfoui à l'intérieur se trouvait Conway, un environnement d'agent toujours actif et piloté par événements avec sa propre interface utilisateur latérale, trois panneaux appelés recherche, chat et système, déclenchement par webhook, un format d'extension propriétaire, contrôle du navigateur via cloud et Chrome, et intégration profonde de connecteurs. J'en ai écrit longuement séparément, donc je vais faire court ici. Conway suppose que le monde va construire pour les agents avec des déclencheurs structurés, des extensions explicites, une exécution pilotée par événements. Il est conçu pour se connecter à des interfaces natives d'agents que d'autres entreprises construiront au cours des un ou deux prochaines années. Cette hypothèse est-elle valable ? Anthropic gagne ce pari si l'adoption de MCP s'accélère, si les logiciels d'entreprise expédient des intégrations propres, si les normes mûrissent assez rapidement pour que Conway ait un substrat riche sur lequel agir. C'est un bon pari à bien des égards. MCP se propage déjà très rapidement. Il est devenu un standard de facto. Anthropic est l'entreprise qui le pousse le plus fort. L'écosystème des développeurs autour du code cloud a un élan énorme, mais il nécessite que l'écosystème bouge et les écosystèmes de logiciels d'entreprise ont tendance à bouger lentement. La longue traîne des outils internes n'obtient pas d'interfaces d'agent dans un délai qui compte. OpenAI n'a pas besoin de cela. L'agent pilote tous les logiciels que vous utilisez vous-même. Aucun fournisseur n'a à coopérer. Aucune intégration n'a à être construite. Anthropic a besoin que toute l'industrie du logiciel se manifeste et construise, et OpenAI non. Donc, ma lecture est que le deuxième scénario est plus probable dans le délai qui compte. Mais c'est une hypothèse. Si les logiciels d'entreprise évoluent plus rapidement que je ne le pense, cette image pourrait changer en faveur de Claude. Une pièce de plus qui vaut la peine d'être présentée car elle indique à quel point OpenAI est sérieux dans cette direction spécifique. Dans l'interview Vance, Brockman et Altman ont décrit trois vecteurs stratégiques. La plateforme Agentic elle-même, le travail informatique spécifiquement, et l'AGI personnelle qui fait des choses pour vous dans le monde réel. C'est ce qu'ils disent être leur feuille de route complète, ces trois choses. Le signal le plus clair de leur sérieux est dans ce qu'ils ont coupé. Sora a été arrêté. Un effort de découverte de médicaments a été abandonné. Pas parce que le travail n'était pas intéressant ou important, mais parce que les cas d'utilisation ne correspondaient pas à ces trois vecteurs. C'est une coupe inhabituellement disciplinée pour une entreprise qui a été accusée de dispersion pendant un certain temps, et cela montre que la direction est prête à tuer des produits populaires pour rester concentrée. Une autre pépite ici. Le calcul est explicitement un centre de profit maintenant, pas seulement une contrainte. OpenAI monétise la rareté, ce qui signifie le plan de consolidation de la super application. Chad GPT est un hub de conversation. Codeex est un agent. Atlas est un navigateur. Ce n'est pas seulement un pari sur le produit. C'est un pari sur le routage des utilisateurs vers une plateforme où le calcul est construit avec des marges qu'OpenAI choisit. Et cela change la forme financière de ce qu'ils construisent. Voilà donc où vont les deux laboratoires. Deux chemins, deux paris, et deux feuilles de route qui sont vraiment assez différentes. Ce qui laisse la dernière question. Que faites-vous de tout cela si vous utilisez ces outils ou si vous prenez des décisions à leur sujet ? L'utilisation de l'ordinateur est la seule capacité où l'écart entre Codeex et Claude est suffisamment large pour changer ce que vous utilisez réellement. Si votre travail implique de piloter des logiciels qui n'ont pas de bonnes API, et pour la plupart des opérateurs, beaucoup d'entre eux en ont, Codeex est un produit prêt aujourd'hui. Claude y arrivera probablement. L'aperçu de recherche s'améliore visiblement, et je sais qu'ils aiment combler ces écarts concurrentiels. Mais aujourd'hui, Codex gagne sur cette capacité spécifique avec une marge suffisamment large pour être significative. Si vous vous attaquez à des tableaux de bord, si vous vous attaquez aux tests visuels front-end, si vous traitez de Slack et d'e-mail en même temps, avec la reproduction de bugs, avec des flux de travail inter-applications que vous copieriez et colleriez autrement entre les outils, tout ce où le goulot d'étranglement est la friction de l'interface plutôt que le raisonnement, Codeex semble être un bon choix. Maintenant, pour le travail délimité et circonscrit, Claude est souvent encore plus précis et efficace. L'ergonomie de co-work qui pointe vers un dossier et décrit le résultat est plus propre que celle de Codeex où un agent trouve la solution pour les tâches où vous souhaitez ce contrôle explicite sur ce que l'agent touche. Claude Code reste à juste titre apprécié pour son ergonomie conviviale pour les développeurs et son récent accent sur le déploiement de flux de travail multi-agents pour le codage. Codex conserve un avantage dans le refactoring de bases de code très complexes et dans la poursuite de tâches de longue durée. Bien que cet écart se soit réduit avec la sortie d'Opus 4.7, ces paramètres sont en quelque sorte définis et ne changent pas très rapidement. La différence pour moi se résume toujours à la valeur pour l'utilisation de l'ordinateur et à la philosophie de conception différente de Codeex par rapport à Claude sur le triage inter-outils, sur les agents parallèles de longue durée, sur le travail ambiant qui ne rentre pas dans un seul mode. Codeex est le défaut maintenant. Chronicle accélère en fait cet écart pour quiconque utilise Pro et est prêt à l'activer. Les agents parallèles en arrière-plan fonctionnent de manière suffisamment fiable pour que la mise en file d'attente de trois ou quatre tâches dans Codeex avant de partir soit devenue un vrai flux de travail au lieu d'un tour de passe-passe. Alors utilisez les deux. Sur lequel devriez-vous vous appuyer ? Cela dépend de l'endroit où vit votre travail. S'il vit dans le travail de connaissance qui bénéficiera d'intégrations d'agents appropriées au cours de la prochaine année environ ou en a déjà, l'architecture de Claude deviendra plus propre et plus fiable. S'il vit dans le travail informatique plus largement, la longue traîne, les outils hérités, les systèmes internes que personne ne maintient, Codeex est celui qui atteint cette longue traîne. Alors, que faut-il surveiller dans les prochains mois pour voir dans quelle direction tout cela évolue ? Deux choses. Premièrement, Conway. Si Enthropic l'annonce publiquement, les agents pilotés par événements deviendront une véritable catégorie aux côtés des agents de contexte ambiant et le cadre des deux chemins commencera à vraiment se cristalliser. Si Enthropic le retarde ou peut-être même l'annule, cela vous indique qu'ils ont perdu confiance dans la coopération de l'écosystème sur un calendrier qui compte et qu'une plus grande partie de la catégorie convergera par défaut vers l'utilisation de l'ordinateur plus le contexte ambiant. Deuxièmement, surveillez la vitesse d'adoption de MCP. Le pari d'Anthropic sur l'écosystème ne paie que si MCP se propage plus rapidement qu'il ne le fait actuellement. Si une vague majeure de fournisseurs d'entreprise expédie sur des serveurs MCP au second semestre de l'année et que Salesforce a été un bon indice dans cette direction, l'architecture d'Anthropic semble de mieux en mieux. S'ils ne le font pas ou s'ils expédient des wrappers minces qui ne fonctionnent pas aussi bien que les interfaces utilisateur réelles, piloter l'interface utilisateur directement reste le meilleur chemin. Quelle est la seule chose à retenir de tout cela ? Écoutez, je vais faire simple. Il y a 6 mois, tout logiciel qui n'avait pas d'API était effectivement en dehors de la conversation sur l'automatisation. Vous ne pouviez pas y faire entrer un agent. Vous deviez attendre que le fournisseur expédie des hooks ou que vous construisiez vous-même l'intégration. Ce n'est plus le cas. L'utilisation de l'ordinateur par Codeex signifie que si le logiciel a un écran, un agent peut effectivement le piloter. Cela élargit ce qui est automatisable par une marge beaucoup, beaucoup plus grande que ce que la plupart des gens prévoient réellement. Pour quiconque envisage d'automatiser les opérations, la surface de ce qui est possible est tellement plus grande aujourd'hui qu'elle ne l'était à la fin de l'année dernière ou même il y a un mois. Et la raison pour laquelle c'est possible, la raison pour laquelle Codeex peut réellement piloter votre logiciel suffisamment bien pour être déployé, ce n'est pas le modèle en soi. Le modèle est le cerveau. Codex est le harnais autour. C'est le corps. Et OpenAI a construit ce corps spécifiquement en achetant une équipe avec une histoire d'expertise très claire et spécifique. Gardez un œil sur ce schéma d'acquisition. Il vous en dira autant sur qui gagnera la prochaine phase que n'importe quel tableau de benchmark. Maintenant, si vous voulez tout exposer et entrer dans les détails de la façon d'utiliser Codeex aujourd'hui pour piloter vos flux de travail, si vous voulez approfondir les détails de la fuite de Conway, sur la comparaison complète avec Claude, j'ai tout écrit sur Substack, le lien est dans la description. Abonnez-vous si vous voulez les recevoir dès qu'ils sortent.