Le responsable de Codex : « Tout le monde est un constructeur » est une très mauvaise idée.

Andrew Ambrosino est le responsable de l'équipe OpenAI Codex. Designer de formation, il a été ingénieur, chef de produit, entrepreneur, et supervise désormais Codex qui compte plus de 5 millions d'utilisateurs actifs par semaine. Il est probablement l'une des personnes les mieux placées pour répondre à la question « Comment faire un produit à l'ère de l'IA ? ».

À ses yeux, lorsque presque tout le monde dans une entreprise peut rapidement créer un prototype fonctionnel, le vrai défi n'est plus « peut-on le faire ? » mais « devrait-on le faire ? ».

Dans son entretien avec Lenny, Andrew Ambrosino détaille le processus de développement interne d'OpenAI : maintenant que le coût de réalisation est considérablement réduit par l'IA, chaque étape du développement produit — de la conception, documentation, prototype, design, à la répartition des rôles, collaboration en équipe et planification — est en train de changer. Quelles sont les anciennes règles qui deviennent obsolètes ? Quelles nouvelles normes émergent ? Quand la réalisation n'est plus rare, qu'est-ce qui devient vraiment la ressource rare ?

Quelques idées clés :

Quand 90 personnes peuvent produire 90 prototypes qui semblent prêts à être lancés, ce qu'il y a de plus précieux, c'est le goût.

L'un des critères d'embauche de l'équipe Codex est le goût : la capacité à distinguer le signal du bruit dans une masse de contenu. Dans un monde de « tokens infinis », ils ne veulent pas produire du contenu médiocre.

Si Codex avait été lancé trois mois plus tôt, il aurait complètement échoué. La seule variable a été l'amélioration du modèle. Ne jugez pas trop vite une fonctionnalité comme mauvaise ; elle n'est peut-être tout simplement pas encore arrivée à son heure.

Qu'une fonctionnalité soit finalement assez bonne dépend souvent moins de sa forme que de l'intelligence suffisante du modèle.

Tout comme Codex a révolutionné ChatGPT, Codex pourrait lui-même être révolutionné par une nouvelle tentative. Il faut préserver une culture d'exploration ascendante, sans attendre que la même équipe peaufine les détails et se réinvente en même temps.

Voici l'essentiel de l'échange.

Quand le coût de réalisation baisse, le goût devient plus important

Lenny : Vous avez dit que l'IA change la forme du travail produit. Vous travaillez aujourd'hui dans l'une des équipes produit les plus en pointe au monde. Concrètement, en quoi le travail de l'équipe produit a-t-il changé par rapport à il y a deux ans ?

Andrew Ambrosino : Maintenant, en tant que responsable d'équipe, le plus difficile, c'est que le processus s'est inversé.

Avant, tout le monde connaissait la manière de faire un produit : d'abord des recherches, des idées, des prototypes. Même après l'ère du développement en cascade, la logique sous-jacente restait la même : la réalisation était coûteuse. Il fallait donc éliminer tous les risques avant la réalisation via des documents, des recherches et des prototypes. Parce que le prototype et le design coûtent moins cher que le développement, c'était l'hypothèse de base.

Cette hypothèse a complètement changé. N'importe qui peut faire n'importe quoi. Je crois vraiment que, en commençant de zéro et en dialoguant avec ces modèles – qu'ils soient les nôtres ou ceux d'autres entreprises – vous pouvez construire toutes les fonctionnalités que vous voulez. Ce n'est peut-être pas la partie la plus difficile du développement logiciel, mais c'est quand même cool.

Vous offrez des tokens infinis aux gens ; chez OpenAI, tout le monde est proactif et a de bonnes idées. Donc chacun fabrique toutes sortes de choses. Maintenant, pour une fonctionnalité que nous devons absolument réaliser, je suis sûr qu'il y a 90 petites équipes non coordonnées qui la construisent et l'expérimentent chacune de leur côté. Parmi ces 90 tentatives, lesquelles sont bonnes ? Quelles parties faut-il intégrer ailleurs ? Comment la définir ? Doit-elle faire partie d'une autre fonctionnalité ? Combien d'options dans le paramètre ? Ce sont ces questions.

Donc, la réponse courte : c'est inversé. Ce n'est pas que les gens jouent des rôles radicalement différents, ni que les compétences disparaissent ou que les rôles n'existent plus. La réalisation n'est plus la partie la plus coûteuse ; je dirais même, la plus coûteuse est le goût.

Lenny : Avant, on écrivait des PRD, des documents stratégiques ; maintenant, on fait directement des prototypes. Beaucoup de gens dans l'entreprise ont des idées similaires, donc apparaissent 90 choses différentes, puis on choisit une direction ?

Andrew Ambrosino : Oui, cela arrive énormément. Non seulement chez OpenAI, mais on voit déjà beaucoup de responsables produit dire « le PRD est mort, vive le prototype », mais je ne suis absolument pas d'accord avec cela.

Parce que la réalisation est devenue bon marché sur tous les médias, il devient très tentant de sauter la réflexion et de passer directement au prototype. Surtout si vous n'êtes pas ingénieur, si vous n'avez jamais écrit de code, que vous n'en avez pas l'intérêt ou le temps, vous avez envie de dire : « Le PRD est mort, laissez-moi vous montrer directement ce que je veux. »

Mais j'ai aussi observé le phénomène inverse. Pour les ingénieurs, écrire beaucoup de documentation devient très tentant, mais beaucoup de documents ne valent pas la peine d'être lus. Ce n'est pas que les auteurs soient mauvais, mais quand la réalisation devient abondante, il devient vraiment important de choisir le bon format pour exprimer son point de vue.

Si vous voulez clarifier un produit dans un domaine flou, il est probablement préférable d'écrire un document. Si vous voulez que les gens testent une interaction, faites un prototype. L'essentiel est de choisir le bon média.

Lenny : Il y a un concept de « primal mark » (marque primaire), le premier coup de pinceau du peintre sur la toile, à partir duquel tout le reste se développe. Voulez-vous dire que parfois le prototype est la première marque erronée ? Parce que les gens s'ancreront dessus au lieu de penser à une solution plus large ?

Andrew Ambrosino : Oui. Avant, il y avait un signal implicite : l'apparence d'une chose indiquait à quelle étape du processus elle se trouvait. Si quelque chose ressemblait à un produit prêt à être lancé, cela signifiait qu'il était en phase avancée, que les risques étaient écartés, que le design avait été vu, que les objectifs commerciaux étaient raisonnables.

Maintenant, ces choses sont découplées. La raison est qu'avant, pour obtenir des ressources pour construire, il fallait d'abord réduire suffisamment les risques ; cette barrière a disparu. Ainsi, quelque chose qui n'était qu'une exploration peut déjà sembler prêt à être lancé, visuellement prêt. Mais il n'est peut-être pas du tout la bonne direction, ne correspond pas aux résultats de recherche, n'est pas ce dont les utilisateurs ont vraiment besoin, ni le meilleur choix pour l'entreprise.

Ce n'est pas pour insister excessivement sur le goût. Mais encore une fois, savoir ce qu'il faut faire, comment le présenter, comment atteindre l'objectif, quel média utiliser, devient la compétence la plus importante dans tous les domaines.

Lenny : Le mot « goût » est à la mode. Concrètement, que voulez-vous dire par « bon goût » ?

Andrew Ambrosino : Il faut décomposer le goût.

Il y a une part esthétique, mais aussi une part de pensée systémique : comment cette chose s'insère-t-elle dans l'ensemble ? Une part directionnelle : où allons-nous, de quel thème cela fait-il partie ? Une part d'expression : comment présenter cette information ? Et une part interactive : cette animation ne correspond pas au sens qu'elle veut transmettre, elle est trop rapide, elle ne correspond pas à l'intention.

Ces choses sont vraiment importantes, mais le vrai problème du goût est : si nous pouvons tout faire, quel est l'objectif ? Comment y arriver ?

Lenny : Alors que l'IA devient de plus en plus puissante et fait de plus en plus de choses, dans quels domaines le cerveau humain continuera-t-il à avoir de la valeur ? Le goût semble en être un. Mais les designs de l'IA ne sont toujours pas très bons. Pourquoi les meilleurs modèles ne font-ils pas du bon design ?

Andrew Ambrosino : Il y a des raisons pratiques et d'autres plus difficiles à résoudre. Le design est plus difficile à noter que le logiciel ; créer une boucle de rétroaction pour entraîner le modèle à reconnaître un bon design est beaucoup plus fastidieux que d'entraîner un code à compiler, car le goût humain fait partie du mécanisme de feedback.

De plus, historiquement, les laboratoires ont donné la priorité à ce qui accélère la recherche en IA. Un modèle capable d'écrire du code correct accélère évidemment la recherche ; le design ne peut pas faire la même démonstration. Ce n'est pas que le design ne soit pas important, mais il n'est pas dans ce cercle vertueux.

Ce sont des raisons pratiques qui disparaîtront. Les modèles deviendront assez bons en design, mais il y a des choses plus difficiles.

Premièrement, le design a une dimension culturelle. Vous vous souvenez que l'année dernière, chaque nouveau site web copiait le design de Linear. Si le modèle sort toujours le site de Linear, ce n'est pas le défi. L'importance de la nouveauté dans le design est bien plus élevée que dans le génie logiciel. En génie logiciel, on souhaite que le modèle suive complètement les schémas connus, mais le design a besoin d'une certaine imprévisibilité et nouveauté.

Deuxièmement, c'est l'interaction entre le design visuel et le code. Si demain l'entreprise change de marque, l'approche superficielle consiste à mettre à jour un par un les 263 composants. L'approche profonde est de comprendre que deux choses qui semblent différentes appartiennent en fait à un même style de liste et transmettent le même motif d'interaction. Cette couche d'abstraction, la technologie actuelle ne l'atteint pas encore.

Lenny : Jenny Wen (responsable design de Claude Code chez Anthropic) a dit que le processus de design est mort, qu'il suffit de construire directement. Qu'en pensez-vous ?

Andrew Ambrosino : Sur beaucoup de choses, Jenny et moi sommes probablement d'accord. Quant au processus de design formel, je suis d'accord avec elle : il est mort. Et je n'étais déjà pas fan de ce processus avant l'IA.

Il y a des années, quand je dirigeais ma startup, il y avait un article intitulé « L'usine à études de cas », qui disait que les designers étaient formés à suivre un processus fixe et qu'ils finissaient par considérer le processus comme plus important que le résultat. Si quelque chose passait par ce processus, on en déduisait automatiquement deux choses : premièrement, ce serait bon, le processus garantit la qualité ; deuxièmement, même si personne ne l'utilisait, c'était bon parce qu'il avait suivi le processus.

La recherche utilisateur, la divergence, la convergence, le cadre est bon, mais il a toujours été un peu académique. La prémisse de ce processus était que la réalisation est chère, on ne peut se permettre de construire qu'une seule fois, donc il faut explorer tout l'espace des problèmes et des solutions avant d'agir.

Puis Figma et Origami sont apparus, et nous avons intégré les prototypes interactifs dans le processus. Maintenant, le problème est que vous pouvez amener toute la réalisation au début du processus. Un prototype entièrement raffiné a l'air prêt à être lancé. Assez de gens dans l'entreprise le voient et demandent : « Peut-on le publier maintenant ? » Mais en réalité, vous en êtes encore à la phase d'exploration préliminaire du design, mais personne ne le dit.

Donc dire que le processus de design est mort est à la fois vrai et faux. Si vous êtes attaché à des outils spécifiques et à des opérations quotidiennes spécifiques, alors oui, il est mort. Mais la conscience de « à quelle étape du processus sommes-nous maintenant » est plus importante que jamais.

Ce qui est dangereux, c'est de lier le processus de design à un média spécifique. Les designers ont maintenant plus d'outils : vous pouvez placer des choses directement dans le produit existant, faire des tests A/B. Beaucoup d'entreprises ont une version bébé de leur produit, un baby Cursor, un baby Codex, un codebase fortement simplifié qui simule toutes les interactions du produit final. Vous pouvez l'utiliser pour du « vibe code » (codage d'ambiance) en disant : « Et si la barre latérale devenait comme ceci ? Et si un panneau apparaissait ? » C'est un nouvel outil pour les designers, mais il nécessite l'ancienne conscience : où êtes-vous dans le processus.

Les postes et les rôles fusionnent, mais le PM ne disparaîtra pas

Lenny : Beaucoup d'entreprises parlent de « disparition des rôles ». Pensez-vous que la division entre PM, ingénieur et designer disparaîtra complètement ?

Andrew Ambrosino : Certaines entreprises aiment suivre les tendances et aller à l'extrême. Le danger d'éliminer le concept de rôle est qu'il pourrait éliminer en même temps la reconnaissance que ces domaines sont des disciplines avec des bonnes pratiques et des leçons apprises.

J'entends beaucoup d'entreprises dire « nous allons supprimer le rôle produit », je pense que c'est une très mauvaise idée, puis dire « tout le monde est builder ». Le résultat est que la gestion de produit, une discipline qui a accumulé de véritables meilleures pratiques et a appris de vraies erreurs, est simplement abandonnée. Parce que quelqu'un a écrit quelques lignes de code, il se sent tout-puissant, ce n'est pas un bon état.

Je suis favorable à la disparition des barrières du genre « ce n'est pas ton domaine, tu ne peux pas y toucher », mais il faut un équilibre. Tout le monde ne peut pas tout faire, ni en largeur ni en profondeur, c'est aussi pourquoi les managers ne disparaîtront pas.

Et chaque discipline a une composante de compétence. Beaucoup d'ingénieurs ne l'admettent pas, pensant que l'ingénierie a des compétences tandis que les autres rôles ne sont que de « l'ambiance ». Ce n'est pas vrai : savoir utiliser Excel ne signifie pas que vous pouvez travailler dans une équipe financière.

Je pense que ce qui se passe plutôt maintenant, c'est qu'il est devenu plus facile de collaborer entre rôles, et plus facile d'apprendre les meilleures pratiques d'autres domaines, sans lier votre efficacité dans un rôle à la maîtrise d'un outil spécifique.

J'ai longtemps pensé que je ne devrais pas être ingénieur logiciel parce que je ne m'intéressais pas au langage assembleur et que je ne voulais pas mémoriser le système de types de TypeScript. Ces rôles ont toujours eu certaines barrières, comme si « bien faire ce rôle = maîtriser cet outil ». Je pense que cela commence à se dissoudre, mais les gens exagèrent.

Lenny : Dans votre équipe Codex, il y a effectivement plus de fusion de rôles. De quoi s'agit-il concrètement ?

Andrew Ambrosino : Dans l'équipe Codex, nous observons effectivement plus de fusion de rôles que dans d'autres équipes de l'entreprise ou d'autres secteurs. Cela vient en partie du fait qu'il s'agit d'un produit technique destiné aux ingénieurs. Ainsi, nos designers parlent le langage des ingénieurs, nos chefs de produit parlent technique et savent coder.

En interne, nous avons une façon de décrire la collaboration : aujourd'hui, les chevauchements entre rôles sont beaucoup plus grands qu'avant. Définir une personne ne consiste plus à regarder les frontières de responsabilité du type « là où le design s'arrête et où l'ingénierie commence », mais à considérer la répartition moyenne de toutes ses tâches.

Si vous étalez toutes les choses que fait une personne de l'équipe design, il peut y avoir beaucoup de codage et beaucoup de travail produit. Mais en faisant la moyenne, elle se situe toujours dans une zone plus proche du design.

Lenny : Vous avez dit que le travail d'un chef de produit ressemble plus à une défense de zone. Qu'entendez-vous par là ?

Andrew Ambrosino : Si deux chefs de produit collaborent trop étroitement, ce n'est généralement pas bon signe. Il faut plutôt regarder l'équipe comme un graphique orienté par forces : où sont les lacunes, qu'est-ce qui n'est pas encore couvert ?

Dans le monde d'aujourd'hui, la curation, l'orientation et l'alignement sont devenus les tâches les plus importantes. Tout le monde lance constamment des idées, l'environnement est bruyant ; la méthode descendante de planification annuelle ne fonctionne plus. Nous avons besoin de quelqu'un qui serve de gardien du goût, qui guide une idée du concept au produit, ce qui signifie couvrir tous les coins de l'entreprise.

Donc, vous devez déployer l'équipe, voir qui est bon dans quoi, maintenir une certaine distance entre eux pour assurer une couverture complète. Ensuite, combler les lacunes, par exemple : « Nous voulons embaucher un ingénieur avec une forte pensée produit. » Nous ne voulons pas qu'un groupe écrive d'abord une grande quantité de code, puis que toute l'équipe produit doive vérifier et calibrer la cohérence produit. Nous voulons que chacun ait ces capacités, mais avec des orientations d'approfondissement différentes.

Lenny : Donc la personne la plus précieuse aujourd'hui est celle qui peut mener une idée de la conception à l'achèvement et qui a le goût de savoir que « c'est super » ?

Andrew Ambrosino : Oui, je pense que c'est le changement central actuel. Cela reflète aussi ma compréhension de la relation entre contributeur individuel (IC) et manager. Pas que le management disparaisse, ni que tout le monde soit IC, mais chacun joue désormais un peu les deux rôles en même temps.

Si vous êtes IC, vous ne codez plus caractère par caractère. Vous gérez en fait certaines choses, des agents, le travail organisé collectivement. Si vous êtes manager, vous faites fondamentalement la même chose, mais à une granularité différente.

En général, je cherche des personnes qui, en plus de compétences solides dans leur domaine, ont du goût. Parce que dans un monde de « tokens infinis », nous ne pouvons pas produire du contenu médiocre. Vous devez être capable de distinguer le signal du bruit dans une masse de contenu.

Quand on me demande combien de personnes compte l'équipe Codex, je réponds : « Entre 10 et plusieurs milliers. » Cela ressemble à une blague, mais en réalité, le travail de tout le monde converge dans ce produit : recherche sur les modèles, utilisation du navigateur, personnalité du modèle, infrastructure frontend, expérience utilisateur, tout cela fait partie du produit.

Mais en même temps, nous ne recevons pas chaque jour les PR de milliers de personnes. L'équipe compte des dizaines d'ingénieurs, les designers sont environ la moitié des ingénieurs, plus quelques chefs de produit ; la grande majorité sont des IC. L'impact de l'équipe est large, mais la hiérarchie n'est pas épaisse. Il y a ici beaucoup d'anciens entrepreneurs, beaucoup de personnes qui travaillent avec un « état d'esprit de fondateur » dans une grande entreprise, et beaucoup de personnes avec un excellent goût.

L'ensemble de l'application Codex est façonné par une boucle de dogfooding. Nous partageons tous le même désir de réaliser notre travail dans l'application autant que possible, même si ce n'est pas encore le meilleur outil, car c'est ainsi qu'elle a finalement une chance de le devenir. Nous évitons souvent délibérément d'améliorer certains processus internes, et préférons laisser le produit lui-même s'améliorer pour soutenir ces processus. C'est un état très inconfortable. Mais de semaine en semaine, cela change continuellement.

Lancer Codex trois mois plus tôt l'aurait tué, la seule différence était l'amélioration du modèle

Lenny : Dans un rythme de changements aussi rapide, comment faites-vous la planification ? Jusqu'à quelle distance voyez-vous ?

Andrew Ambrosino : Nous n'avons rien de révolutionnaire en matière de planification. Le principe de base est que plus une chose est proche dans le temps, plus la planification doit être spécifique. Ce n'est pas qu'on ne fait pas de plans sur neuf mois, mais ces plans doivent rester très vagues. Parce que toute précision ajoutée à un plan sur neuf mois est une fausse précision, qui ne fait que perdre du temps.

Du côté des applications, ce que vous planifiez en novembre peut encore être valable en décembre, mais totalement différent en février.

Dans ma précédente entreprise, quand nous avons commencé à baser le développement de fonctionnalités sur les capacités des modèles, le processus produit existant s'est en gros effondré. Ensuite, nous avons listé toutes les directions intéressantes, en avons fait des prototypes, jugé lesquelles étaient maintenant réalisables, et mis les autres de côté. À chaque saut de capacité du modèle, nous ressortions ces fonctionnalités mises de côté pour les tester à nouveau. Parce que la qualité finale d'une fonctionnalité dépend souvent moins de sa forme que de l'intelligence suffisante du modèle. Beaucoup de gens ont toujours été mécontents de ma façon de planifier. Mais c'est vraiment très difficile.

Lenny : Y a-t-il un exemple concret de l'importance du timing ?

Andrew Ambrosino : Il y a une bonne histoire avec Codex. Je suis très sûr que l'application Codex que nous avons lancée en février, si elle avait été prête en novembre et lancée à ce moment-là, aurait complètement échoué sur le marché. La seule différence est que le modèle a progressé entre novembre et février. Même produit, exactement la même forme, résultat complètement différent, juste quelques mois de différence.

Lenny : Donc ce qui ne marche pas maintenant pourrait marcher plus tard ? Il faut garder de plus grandes ambitions ?

Andrew Ambrosino : Oui. Je recommande aux gens de ne pas conclure trop vite que « cette fonctionnalité ne marche pas maintenant, donc c'est une mauvaise fonctionnalité ». Elle n'est peut-être tout simplement pas encore arrivée à son heure.

Revenons au lancement initial de Codex, Codex web. En gros, vous donniez une tâche au modèle, il l'exécutait et revenait avec le résultat. Cela ne semble pas radical, mais le problème est qu'il ne le faisait pas assez bien ; cette forme était trop en avance.

Ensuite, Claude Code est sorti, entièrement local, non connecté au cloud, ne prétendait pas être super AGI. Il posait des questions, attendait, vous ne pouviez pas lui confier toute votre vie. Il était bien plus utilisable car il correspondait au niveau de capacité du modèle de l'époque.

Nous étions trop « AGI » à l'époque, je repense souvent à cette leçon. Autrefois, l'échec d'un produit sur le marché vous en apprenait beaucoup sur sa forme ou sa communication. Maintenant, c'est différent : vous devrez peut-être lancer la même chose six fois jusqu'à ce qu'elle réussisse, la forme pouvant rester exactement la même.

Il en va de même pour le navigateur dans l'application. Nous avions déjà une version fonctionnelle à l'époque d'Atlas, avec un agent qui exécutait des tâches dans le navigateur. Avant cela, il y avait Operator dans ChatGPT, qui n'a pas réussi. Mais si vous reliez Operator, Atlas, Codex et ChatGPT, vous pouvez tracer une ligne d'évolution continue. C'est essentiellement la même fonctionnalité, mais avec l'intelligence croissante, elle a été relancée à plusieurs reprises, avec des résultats radicalement différents.

Une fois qu'un produit ou une fonctionnalité existe, les gens ont tendance à se concentrer sur des détails et des micro-optimisations, et ils ont raison de le faire. Mais c'est aussi pourquoi nous conservons une culture d'exploration ascendante. Parce que parfois, tout comme l'application Codex a bouleversé ChatGPT d'une certaine manière, Codex lui-même pourrait être bouleversé par de nouvelles tentatives. On ne peut pas attendre d'une même équipe qu'elle produise constamment des innovations de rupture tout en restant concentrée sur la qualité et le polissage des détails. À un certain stade, il faut concevoir un mécanisme qui permette aux deux capacités de coexister.

Lenny : Quelle est la vision de Codex ? Où voulez-vous l'emmener ?

Andrew Ambrosino : En janvier et février, lors de nos tests internes en utilisation personnelle, nous avons constaté un PMF très clair dans les flux de travail d'ingénierie et de recherche. Mais en même temps, les gens du marketing, de la communication, des finances et du juridique utilisaient aussi Codex, même si l'application n'était pas conçue pour eux : elle leur montrait du code, leur faisait approuver l'exécution de commandes de recherche en ligne de commande.

Nous avons essayé d'ajouter les capacités de Codex dans d'autres produits : l'application de bureau ChatGPT, le navigateur Atlas. Et la chose la plus ennuyeuse s'est produite : personne ne voulait quitter l'application Codex pour utiliser celles soi-disant conçues pour eux.

La leçon que nous en avons tirée est qu'il existe de nombreux points communs subtils entre les outils pour développeurs et les outils pour le travail de connaissance générale. Nous croyons fermement que la forme de produit que nous construisons est la bonne pour accueillir divers scénarios verticaux profonds. Commencer simple, puis ajouter de la complexité selon les besoins.

Ce n'est pas un produit du genre « dessiner un rectangle sur l'écran, et tout doit se faire à l'intérieur ». C'est plutôt un camp de base où vous commencez votre travail, le terminez, gérez des automatisations, et il appelle tous les outils dont vous avez besoin. Certaines personnes appellent cette forme une « super app » ; j'aurais vraiment préféré qu'ils ne le fassent pas, car maintenant je dois entendre ce mot presque tous les jours.

Dan Shipper a une idée intéressante : il pense qu'à l'avenir, nous utiliserons les outils SaaS « de l'intérieur vers l'extérieur » dans Codex. Notion, Linear, Salesforce ne seront pas ouverts dans un navigateur, mais un agent les manipulera dans Codex. Et nous le faisons effectivement : navigateur dans l'application, extension Chrome, computer use – tous ces moyens permettent à Codex d'interagir avec des outils externes.

Un excellent exemple : notre vidéaste interne Brent a utilisé Codex pour monter la vidéo de lancement de Codex. Codex n'est pas un éditeur vidéo, il n'a pas d'interface utilisateur dédiée. Mais il comprend que Brent utilise Premiere Pro, et il peut effectuer des modifications en éditant les fichiers sous-jacents de Premiere Pro. Quand il a découvert qu'il ne pouvait pas tout faire, il a lui-même écrit une extension pour Premiere Pro, l'a installée, et a dialogué avec Premiere Pro via cette extension. Nous étions stupéfaits.

C'est un bon modèle : les outils spécialisés font leur travail. Codex n'a pas besoin de devenir un meilleur éditeur vidéo ; il lui suffit d'interagir de manière transparente avec les outils spécialisés.

Savoir écrire du code n'est plus important, savoir en supprimer l'est

Lenny : Du code écrit à la main au code 100% généré par l'IA, puis maintenant aux agents et aux boucles. Comment travaillent vraiment les équipes les plus avancées aujourd'hui ?

Andrew Ambrosino : Les boucles ? C'était la semaine dernière.

Nous discutons constamment de la question « quelle proportion du code du produit est écrite par l'IA ». Selon les standards de l'année dernière, aujourd'hui 100% de notre code est écrit par l'IA. Donc la question n'est plus « combien est écrit par l'IA », mais « le code est-il écrit sous supervision ou sans supervision », une dimension complètement différente. Je salue le fait que ces standards soient constamment mis à jour, car cela signifie que nous progressons sur le produit.

Nous explorons beaucoup le développement autonome de logiciels, par exemple l'ingénierie de harnais, comme « et si le modèle faisait automatiquement du garbage collection et du nettoyage du codebase pendant la nuit ? »

Mais tous les modèles actuels ont un problème : ils ajoutent toujours de la complexité. Si les chercheurs écoutent : s'il vous plaît, apprenez aux modèles à supprimer du code. Quand vous essayez de confier entièrement le développement au pilote automatique, cela devient un problème sérieux, à la fois au niveau humain et au niveau du codebase.

Les demandes de fonctionnalités (feature requests) aussi. Comment apprendre au modèle à juger quelles fonctionnalités méritent d'être réalisées, lesquelles doivent être ignorées, lesquelles doivent être fusionnées puis redéfinies ? Et comment lui apprendre à construire la bonne abstraction ?

Ces capacités progressent constamment. Mais je ne pense pas que nous en soyons au stade de mettre en place une boucle où le modèle « améliore automatiquement l'application », écoute constamment Twitter, Slack et les emails, et itère de manière autonome. Bien que nous essayions effectivement de rendre cela réalité.

Lenny : Pensez-vous que nous y arriverons ? C'est-à-dire définir un objectif : « gagner » ?

Andrew Ambrosino : « /goal gagne-moi un milliard de dollars. » Je ne sais pas. Je ne dirai jamais que c'est impossible ou que ce le sera toujours.

Lenny : En tant que responsable produit et ingénierie, comment utilisez-vous l'IA dans votre travail ?

Andrew Ambrosino : Je pense que j'ai peut-être le meilleur travail du monde en ce moment.

Au début de Codex, mon objectif personnel était de le rendre assez bon pour que je puisse l'utiliser pour coder Codex. C'était une boucle produit d'autoutilisation très serrée : je ne pouvais pas faire quelque chose, donc je le réparais, puis je pouvais le faire, puis je pouvais faire davantage.

Ensuite, mon rôle a changé. J'ai eu besoin de faire plus de découverte produit, de comprendre ce que l'équipe faisait, de corriger les déviations. Codex est devenu mon outil pour ces tâches. « Aide-moi à créer un tableur pour organiser ces données. » « Fais une recherche interne approfondie sur ce qui a été exploré dans cette direction par le passé. »

Les séries de lancements de mai — navigateur dans l'application, utilisation de l'ordinateur, création d'artefacts — ont été notre première gestion de lancement via une « coordination d'ambiance » (vibe coordination). J'avais un document Notion listant toutes les tâches à faire, puis Codex collectait automatiquement l'avancement dans les PR, les canaux Slack, et mettait à jour le suivi d'état. À l'époque, je pensais que c'était la façon la plus avancée de gérer un lancement produit.

Maintenant, chaque matin, je consulte le rapport quotidien généré par Codex, qui filtre les 3000 canaux Slack dont je fais partie pour ne retenir que ce qui mérite mon attention. Je peux répondre : « Donne-moi cinq questions, je réponds. » Il s'ajuste : je dis « la prochaine fois, accorde moins d'attention à ce flux de travail » ou « ceci s'est produit mais n'est pas dans le rapport, assure-toi de le capter à l'avenir », et il met à jour ses notifications, ajuste son focus.

Lenny : Comment cela est-il configuré ? Quel est le flux de travail ?

Andrew Ambrosino : Nous en sommes encore au stade de la découverte. Il s'agit simplement de créer une tâche planifiée : « Parcours mes canaux Slack, voici les sujets qui m'intéressent, organise-les selon ces catégories, voici du contexte. » Les premières exécutions nécessitent des indications. Heureusement, je n'ai pas besoin de chercher comment éditer les instructions ; je dialogue : « La prochaine fois, modifie ceci pour moi », et il met à jour.

Mais je pense que c'est aussi le problème central de la forme chatbot : je sais comment configurer parce que pour moi, c'est de la découverte produit. Mais si vous ne travaillez pas chez OpenAI et ne développez pas ce produit, vous ne voulez pas vous donner la peine de comprendre cela. Nous devons réfléchir à comment rendre cela accessible aux gens ordinaires.

Lenny : J'utilise aussi Codex pour automatiser le filtrage des spams. Une des étapes nécessite d'aller dans la console Google Cloud pour configurer une série de déclencheurs API, et l'interface était vraiment pénible. J'ai donc demandé à Codex de le faire pour moi, et il a directement pris le contrôle de mon ordinateur en utilisant la fonction de computer use.

Andrew Ambrosino : C'est : « Je me fiche que tu aies un connecteur ou pas, mon vieux, je commence à cliquer. »

Définir les frontières entre les connecteurs, le navigateur dans l'application, l'extension Chrome et l'utilisation de l'ordinateur est une chose très intéressante. Souvent, ces frontières sont déterminées par l'intuition.

Je trouve ces flux de travail personnels particulièrement intéressants. Tout le monde essaie toutes sortes de choses, et chacun construit un système complètement différent. Mais progressivement, des modèles communs émergent. Puis nous réalisons : « Cela devrait devenir une expérience de première classe dans le produit. »

Par exemple, la mémoire. Beaucoup configurent des bases Obsidian ou des espaces Notion pour construire leur palais mental. Vous ne devriez pas avoir à le faire vous-même ; il devrait y avoir une fonction mémoire assez générique pour le faire à votre place. Nous filtrons constamment ce qui est efficace au niveau personnel mais devrait rester personnel, et ce qui devrait entrer dans le produit en tant que composant de base.

Lenny : Les gens de l'extérieur ne voient que vous gagnez. Mais il y a forcéments des choses qui n'ont pas marché, non ?

Andrew Ambrosino : C'est drôle de t'entendre décrire cela. C'est en fait la première fois que j'ai l'impression de ne pas échouer.

J'ai été entrepreneur pendant de nombreuses années, et j'ai fini par démanteler et vendre ma société. Travailler dans un secteur hautement réglementé était une série d'échecs continus. Ensuite, je suis allé dans une autre startup, dans un autre secteur réglementé fermé, pour faire des outils d'IA, et encore une fois, ça n'a pas marché. En réalité, j'ai beaucoup échoué. Parfois, ce n'est qu'une question de moment où les compétences, la passion et l'opportunité du marché s'alignent.

Même dans le projet actuel qui combine Codex et ChatGPT, il y a d'innombrables petits échecs. Nous disons « cela devrait ressembler à ceci », on le met sur Slack, et en dessous, 2000 messages disent à quel point nous sommes stupides. C'est ce que j'aime chez OpenAI : les gens nous le disent directement, ils sont impitoyables envers les échecs des produits internes, c'est pourquoi les produits externes sont bons. Avant d'arriver là où je suis, j'ai échoué pendant environ 10 à 15 ans. Donc chaque jour, je suis encore un peu étonné que les choses se passent bien.

Lenny : Quel dernier conseil donneriez-vous aux lecteurs ?

Andrew Ambrosino : Ne vous « mariez pas » avec votre flux de travail actuel. Ce à quoi vous devez vraiment vous accrocher, ce sont les résultats uniques que vous seul pouvez produire. Ensuite, essayez continuellement de changer votre processus. Si la compétence dont vous êtes le plus fier est « je suis le meilleur en auto layout Figma », qu'êtes-vous en train de faire ? L'IA deviendra meilleure que vous là-dedans. Trouvez ce qui vaut la peine d'être fait, puis trouvez le moyen de le faire.