Le responsable de Codex : « Tout le monde est un builder » est une très mauvaise idée
TechFlow SélectionTechFlow Sélection
Le responsable de Codex : « Tout le monde est un builder » est une très mauvaise idée
A-t-on encore besoin de PM pour développer des produits d'IA ? Si oui, que doivent faire les PM à l'ère de l'IA ?
Dédié à des analyses Web3 approfondiesAuteur : Founder Park
Andrew Ambrosino est le responsable de l'équipe OpenAI Codex. Issu du design, il a été ingénieur, puis dans le produit, a lancé une startup, et dirige maintenant Codex qui compte plus de 5 millions d'utilisateurs actifs hebdomadaires. Il est probablement l'une des personnes les mieux placées pour répondre à la question « Comment construire un produit à l'ère de l'IA ? ».
Selon lui, lorsque presque tout le monde dans l'entreprise peut rapidement assembler un prototype de fonctionnalité, le vrai défi n'est plus « peut-on le faire ? », mais « faut-il le faire ? ».
Dans son entretien avec Lenny, Andrew Ambrosino détaille le processus de développement interne chez OpenAI : lorsque le coût de mise en œuvre est considérablement réduit par l'IA, chaque étape du développement de produit, de l'initiation, la documentation, le prototype, la conception jusqu'à la répartition des rôles, la collaboration d'équipe et la planification produit, est en train de changer. Quelles anciennes règles deviennent obsolètes ? Quelles nouvelles normes sont en train de se former ? Lorsque la mise en œuvre n'est plus rare, quelle est la ressource vraiment rare ?
Quelques points clés :
- Lorsque 90 personnes peuvent toutes créer 90 prototypes de produits semblant prêts à être lancés, le plus précieux est le taste.
- L'une des normes strictes pour recruter dans l'équipe Codex est le goût, la capacité de distinguer le signal du bruit dans une masse de contenu. Dans un monde où l'on dispose de « tokens infinis », ils ne veulent pas produire de contenu indésirable.
- Si Codex avait été lancé trois mois plus tôt, il aurait été un échec total ; la seule variable est que le modèle s'est amélioré. Ne jugez pas légèrement qu'une fonctionnalité est mauvaise, elle n'est peut-être pas encore prête.
- Qu'une fonctionnalité soit finalement suffisamment bonne ou non dépend souvent moins de la forme de la fonctionnalité elle-même que de l'intelligence du modèle.
- Tout comme Codex a autrefois bouleversé ChatGPT, Codex pourrait lui-même être bouleversé par de nouvelles tentatives. Il faut préserver une culture d'exploration ascendante ; on ne peut pas attendre d'une même équipe qu'elle affine les détails et se bouleverse elle-même.
Voici les points essentiels de l'entretien.
Le coût de la mise en œuvre a baissé, le taste est devenu plus important
Lenny : Vous avez dit que l'IA est en train de changer la nature du travail produit. Vous travaillez maintenant dans l'une des équipes produits IA les plus avancées au monde. Concrètement, comment la façon de travailler de l'équipe produit a-t-elle changé par rapport à il y a deux ans ?
Andrew Ambrosino : Maintenant, en tant que responsable d'équipe, la chose la plus difficile est que le processus s'est inversé.
Comment on faisait du produit avant, tout le monde connaît : d'abord la recherche, puis l'idée, puis le prototype. Même si nous avons depuis longtemps dépassé l'ère du développement en cascade, la logique sous-jacente est la même, la mise en œuvre est coûteuse. Donc, avant la mise en œuvre, il faut exclure tous les risques via la documentation, la recherche et le prototype. Parce que le prototype et le design sont moins chers que le développement, c'était l'hypothèse de base du passé.
Maintenant, cette hypothèse a complètement changé, n'importe qui peut créer n'importe quoi. Je crois vraiment que, en partant de zéro et en dialoguant avec ces modèles, que ce soit les nôtres ou ceux d'autres entreprises, vous pouvez construire n'importe quelle fonctionnalité que vous voulez. Ce n'est pas nécessairement la partie la plus difficile du développement logiciel, mais c'est vraiment cool.
Vous donnez aux gens des tokens infinis, tout le monde chez OpenAI est très proactif, a de bonnes idées. Donc tout le monde fait toutes sortes de choses. Maintenant, il y a une fonctionnalité dont l'entreprise a urgent besoin, je suis sûr qu'en même temps, 90 petites équipes différentes, non coordonnées, sont en train de l'implémenter et de l'essayer chacune de leur côté. Parmi ces 90 tentatives, lesquelles sont bonnes ? Quelles parties doivent être repliées vers d'autres aspects ? Comment doit-on la définir ? Devrait-elle faire partie d'une autre fonctionnalité ? Combien d'options devrait-il y avoir dans les paramètres ? Ce sont ce genre de choses.
Donc la réponse courte est : c'est inversé. Ce n'est pas que les gens jouent des rôles fondamentalement différents, ni que les compétences ont disparu ou que les rôles n'existent plus. La mise en œuvre n'est plus la partie la plus chère, je me permets de le dire, le plus cher est le taste.
Lenny : Donc avant, tout le monde écrivait des PRD, des documents de stratégie, maintenant tout le monde fait directement des prototypes. Beaucoup de gens dans l'entreprise ont des idées similaires, donc 90 choses différentes apparaissent, et on choisit la direction parmi elles ?
Andrew Ambrosino : Oui, ce genre de chose se produit massivement. Pas seulement chez OpenAI, vous avez déjà vu beaucoup de responsables produit dire « La PRD est morte, vive le prototype », mais en réalité, je ne suis pas du tout d'accord avec ce point de vue.
Parce que la mise en œuvre est devenue bon marché sur chaque support, sauter la réflexion pour faire directement un prototype devient très tentant. Surtout si vous n'êtes pas ingénieur, si vous n'avez jamais écrit de code, n'avez pas d'intérêt ou pas de temps, vous serez tenté de dire : « La PRD est morte, laissez-moi vous montrer directement ce que je veux. »
Mais j'ai aussi remarqué un phénomène inverse. Pour les ingénieurs, écrire beaucoup de documentation devient très tentant, beaucoup de documentation qui ne vaut pas la peine d'être lue. Ce n'est pas pour dire que les gens qui écrivent la documentation sont mauvais, mais pour dire que lorsque la mise en œuvre devient abondante, choisir le bon format pour exprimer votre point de vue devient vraiment important.
Si vous voulez exprimer une clarté produit dans un domaine flou, alors il faut probablement écrire de la documentation. Si vous voulez que les gens essaient, testent sous pression un mode d'interaction, alors faites un prototype. La clé est de choisir le bon support.
Lenny : Il y a un concept appelé primal mark (marque primitive), le premier coup de pinceau du peintre sur la toile, tout le reste s'étend à partir de ce trait. Vous voulez dire que parfois le prototype est le premier trait erroné ? Parce que les gens s'y ancreront, au lieu de penser à un方案 plus large ?
Andrew Ambrosino : Oui. Auparavant, il y avait un signal implicite, à quoi ressemble une chose, signifie à quelle étape du processus elle se trouve. Si vous voyez quelque chose qui ressemble à un produit officiellement lancé, cela signifie qu'il est déjà en phase tardive, les risques ont été exclus, le design a été vu, les objectifs commerciaux sont raisonnables.
Maintenant, ces choses sont découplées. La raison est que pour obtenir des ressources pour construire, vous deviez d'abord réduire suffisamment les risques, maintenant ce seuil n'existe plus. Donc quelque chose qui n'est qu'en phase d'exploration, ressemble déjà à quelque chose qui peut être lancé, visuellement il est prêt. Mais ce n'est peut-être pas du tout la bonne direction, ne correspond pas aux conclusions de la recherche, n'est pas ce dont les utilisateurs ont vraiment besoin, ni le choix optimal pour l'activité.
Il ne s'agit pas de trop insister sur cette histoire de goût. Mais encore une fois, savoir quoi faire, comment le présenter, comment atteindre l'objectif, avec quel support, cela est en train de devenir la capacité la plus importante dans chaque domaine.
Lenny : Le mot goût est maintenant un mot à la mode. Concrètement, qu'est-ce que ce « bon goût » dont vous parlez ?
Andrew Ambrosino : Le goût doit être décomposé.
Il y a确实 une partie esthétique, mais il y a aussi une partie pensée systémique, comment cette chose se place dans tout le système ; il y a une partie directionnelle, où allons-nous, de quel thème cette chose fait-elle partie ; il y a une partie expression, comment présenter cette information ; et une partie du goût est au niveau de l'interaction, cette animation ne correspond pas à la sémantique qu'elle doit transmettre, elle est trop précipitée, ne correspond pas au sens qu'elle veut exprimer.
Ces choses sont确实 très importantes, mais la vraie question de 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 forte, fait de plus en plus de choses, où le cerveau humain continuera-t-il à avoir de la valeur ? Le goût semble être l'un d'eux. Mais les résultats de design de l'IA ne sont toujours pas très bons, pourquoi les modèles de pointe ne font-ils pas bien le design ?
Andrew Ambrosino : Il y a des raisons pratiques, et aussi des problèmes 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 sur ce qu'est un bon design est beaucoup plus fastidieux que d'entraîner le code à pouvoir être compilé, parce que le goût humain fait partie du mécanisme de rétroaction.
De plus, historiquement, les laboratoires ont priorisé les choses que les modèles savent faire pour accélérer la recherche en IA. Que le modèle puisse écrire du code correct accélère显然 la recherche, le design ne peut pas faire le même argument. Ce n'est pas que le design n'est pas important, mais il n'est pas dans cette roue d'entraînement.
Ce sont des raisons pratiques, elles disparaîtront. Les modèles deviendront assez bons en design, mais il y a des choses plus difficiles à gérer.
Premièrement, le design a une属性 culturelle. Vous vous souvenez l'année dernière, chaque nouveau site web copiait le design de Linear. Si le modèle sortait à chaque fois un site web Linear, ce n'est pas le défi. Le degré d'importance de la nouveauté dans le design est bien plus élevé que dans l'ingénierie logicielle. En ingénierie logicielle, vous voulez presque que le modèle suive完全 les modèles connus, mais le design nécessite une certaine randomité 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 est de mettre à jour un par un 263 composants. L'approche profonde est de comprendre que ces deux choses qui semblent différentes appartiennent en fait à un style de liste, transmettent le même mode d'interaction. Cette couche d'abstraction, la technologie actuelle ne peut pas encore l'atteindre.
Lenny : Jenny Wen (responsable du design Claude Code chez Anthropic) dit que le processus de design est mort, il suffit de construire directement, qu'en pensez-vous ?
Andrew Ambrosino : Je suis probablement d'accord avec Jenny sur beaucoup de choses. Le processus de design formel, je suis d'accord avec elle, il est mort. Et avant l'IA, je n'étais déjà pas fan de ce processus.
Il y a plusieurs années, quand j'ai lancé une startup, il y avait un article appelé « Usine d'études de cas », qui disait que les designers sont entraînés à suivre un ensemble de processus fixes, et progressivement considèrent ce processus lui-même comme plus important que le résultat. Si une chose passe par ce processus, on en déduit par défaut deux conclusions : premièrement, elle sera bonne, le processus garantit la qualité ; deuxièmement, même si personne ne l'utilise, elle est bonne, parce qu'elle a suivi le processus.
La recherche utilisateur, la divergence, la convergence, le cadre est correct, mais toujours un peu académique. La prémisse de ce processus est que la mise en œuvre est chère, vous ne pouvez vous permettre de construire qu'une fois, donc vous devez épuiser tous les espaces de problèmes et d'options avant de faire.
Plus tard, Figma et Origami sont apparus, nous avons intégré les prototypes d'interaction dans le processus. Maintenant le problème est, vous pouvez tirer toute la mise en œuvre au tout début du processus. Un prototype complètement raffiné, qui semble pouvoir être lancé directement. Assez de gens dans l'entreprise le voient et demandent : « Peut-on le lancer maintenant ? » Mais en réalité, vous êtes toujours en phase d'exploration de design précoce, c'est juste que personne ne le dit explicitement.
Donc dire que le processus de design est mort, c'est à la fois vrai et faux. Si vous êtes lié à des outils spécifiques et des opérations quotidiennes spécifiques, alors oui, il est mort. Mais la cognition « à quelle étape du processus sommes-nous maintenant » est plus importante que jamais.
Lier le processus de design à un support spécifique, c'est là que réside le danger. Les designers ont maintenant plus d'outils, vous pouvez mettre les choses directement dans le produit existant, faire des tests A/B. Beaucoup d'entreprises ont des versions baby de produits, baby Cursor, baby Codex, une base de code grandement simplifiée, capable de simuler toutes les interactions du produit officiel. Vous pouvez l'utiliser pour vibe code, dire « Et si la barre latérale devenait comme ça ? Et si un panneau apparaissait ? » C'est un nouvel outil pour les designers, mais il doit être配合 avec l'ancienne cognition : où êtes-vous dans le processus maintenant.
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 du travail entre PM, ingénieurs et designers disparaîtra complètement ?
Andrew Ambrosino : Certaines entreprises aiment beaucoup suivre la tendance, aller à l'extrême. Le danger d'éliminer le concept de rôle est qu'il peut simultanément éliminer la cognition que « ces domaines sont des professions avec des meilleures pratiques apprenables ».
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 un builder ». Le résultat est que la gestion de produit, cette discipline qui a accumulé de vraies meilleures pratiques, a vraiment trébuché sur des pièges, est directement abandonnée. Parce que quelqu'un a écrit quelques lignes de code, il pense que tout est réglé, ce n'est pas un bon état.
Je welcome la disparition des frontières « ce n'est pas votre domaine, vous ne pouvez pas y toucher », mais il faut un équilibre. Tout le monde ne peut pas tout faire, que ce soit en termes de largeur ou de 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, pensent que l'ingénierie a des compétences, les autres rôles de poste sont juste de l'« ambiance ». Ce n'est pas le cas, savoir utiliser Excel ne signifie pas que vous pouvez travailler dans l'équipe financière.
Je pense que ce qui se passe maintenant est plutôt que la collaboration inter-rôles devient plus facile, apprendre les meilleures pratiques d'autres domaines devient aussi plus facile, vous n'avez plus à lier votre efficacité dans un certain rôle à la capacité d'utiliser des outils spécifiques.
J'ai passé beaucoup de temps à penser que je ne devrais pas être ingénieur logiciel, parce que je ne me soucie pas du langage assembleur, et ne veux pas mémoriser le système de types TypeScript. Ces rôles ont toujours eu des seuils, comme si « bien faire ce rôle égale maîtriser parfaitement cet outil ». Je pense que cela commence à se dissoudre, mais les gens l'exagèrent.
Lenny : Dans votre équipe Codex, il y a确实 plus de fusion de rôles, à quoi cela ressemble-t-il concrètement ?
Andrew Ambrosino : Dans l'équipe Codex, nous voyons确实 plus de fusion de rôles que dans les autres équipes de l'entreprise et dans les autres industries. Une partie de la raison est que c'est un produit technique destiné aux ingénieurs. Donc nos designers parlent le langage des ingénieurs, nos chefs de produit parlent le langage technique, savent écrire du code.
Nous avons une façon de décrire la collaboration en interne : aujourd'hui, le chevauchement entre les rôles est beaucoup plus grand qu'auparavant. Définir une personne ne consiste plus à regarder les frontières de responsabilités comme « où le design se termine, où l'ingénierie commence », mais à regarder la distribution moyenne de tout son contenu de travail.
Si l'on étale tout ce qu'une personne dans l'équipe de design fait, cela peut contenir beaucoup de travail d'écriture de code, et aussi beaucoup de travail lié au produit. Mais si l'on prend une « moyenne » de ce travail, il finira toujours par tomber dans une zone plus偏向 le design.
Lenny : Vous avez mentionné que le travail du chef de produit ressemble plus à de la zone defense (défense de zone), qu'est-ce que cela signifie concrètement ?
Andrew Ambrosino : Si deux chefs de produit collaborent de trop près, ce n'est généralement pas un bon signal. Vous devriez plutôt déployer l'équipe comme une disposition guidée par la force, où y a-t-il des lacunes, où n'y a-t-il encore personne pour couvrir ?
Dans le monde d'aujourd'hui, le curation, le guidage et l'alignement sont devenus le travail le plus important. Tout le monde lance constamment des idées, tout l'environnement est plein de bruit, l'ancienne méthode descendante, planifier par année, ne fonctionne plus. Nous avons besoin de quelqu'un comme gardien du goût, pour guider une chose du concept au produit, et cela signifie que vous devez couvrir tous les coins de l'entreprise.
Donc, vous devez déployer l'équipe pour voir, qui est bon dans quoi ? Gardez une certaine distance les uns des autres, assurez-vous que la couverture est suffisamment complète. Puis allez combler les lacunes, par exemple : « Nous voulons recruter un ingénieur avec une forte pensée produit. » Nous ne voulons pas qu'une situation se produise où un groupe de gens écrit d'abord beaucoup de code, et qu'enfin toute l'équipe produit doit examiner et calibrer la cohérence du produit. Nous voulons que tout le monde possède ces capacités, c'est juste que la direction dans laquelle chacun creuse profondément doit changer.
Lenny : Donc maintenant, les personnes les plus précieuses sont celles qui peuvent promouvoir de l'idée à la complétion tout au long du processus, et ont le goût de savoir « c'est génial » ?
Andrew Ambrosino : Oui, je pense que c'est le changement le plus central actuellement. Cela reflète aussi ma compréhension de la relation entre IC (contributeur individuel) et manager. Ce n'est pas que le management disparaîtra, ni que tout le monde est juste IC, mais maintenant tout le monde assume en quelque sorte ces deux rôles simultanément.
Si vous êtes IC, vous ne tapez plus code caractère par caractère. Vous gérez en fait quelque chose, gérez des agents, gérez ce travail organisé pour accomplir des tâches ensemble. Si vous êtes manager d'équipe, vous faites essentiellement la même chose, c'est juste que la granularité de la gestion est différente.
Les personnes que je cherche généralement, en plus d'avoir des compétences professionnelles solides, doivent avoir du goût. Parce que dans un monde où l'on dispose de « tokens infinis », nous ne pouvons pas produire de contenu indésirable. Vous devez avoir la capacité de distinguer le signal du bruit dans une masse de contenu.
Chaque fois que quelqu'un demande combien de personnes il y a dans l'équipe Codex, ma réponse est : « Environ entre 10 et plusieurs milliers de personnes. » Cela ressemble à une blague, mais en réalité, le travail de tout le monde converge dans ce produit, la recherche de modèle, l'utilisation du navigateur, la personnalité du modèle, l'infrastructure frontend, l'expérience utilisateur, tout cela fait partie du produit.
Mais en même temps, nous ne recevons pas non plus plusieurs milliers de PR (demandes de submission de code) soumises par des personnes chaque jour. L'équipe a des ingénieurs à deux chiffres, le nombre de designers est environ la moitié de celui des ingénieurs, plus quelques chefs de produit, la majorité sont des IC. La portée d'influence de l'équipe est grande, mais les niveaux de management ne sont pas épais. Il y a beaucoup de gens qui ont fondé des entreprises auparavant, et aussi beaucoup de gens qui travaillent avec un « état d'esprit de fondateur » dans de grandes entreprises, et encore beaucoup de personnes avec un goût excellent.
Toute l'application Codex est façonnée par le cycle de dogfooding. Nous avons tous un désir commun, accomplir autant de notre travail que possible dans l'application, même si ce n'est pas encore le meilleur outil temporairement, parce que seulement ainsi, elle aura finalement la chance de devenir le meilleur outil. Nous omettons souvent délibérément d'améliorer certains processus internes, mais laissons le produit lui-même devenir meilleur, afin de pouvoir supporter ces processus. C'est en fait un état très inconfortable. Mais semaine après semaine, cela change确实 continuellement.
Codex serait mort s'il était lancé trois mois plus tôt, la seule différence est que le modèle s'est amélioré
Lenny : Dans un rythme où les choses changent si vite, comment faites-vous la planification ? Jusqu'où regardez-vous ?
Andrew Ambrosino : Nous n'avons rien de révolutionnaire dans la planification. Le principe de base est que, plus les choses sont proches du présent, plus la planification doit être spécifique. Ce n'est pas que nous ne faisons pas de plan de neuf mois, mais ce plan doit rester très flou. Parce que toute précision que vous ajoutez maintenant au plan de neuf mois est une fausse précision, cela ne fait que perdre du temps.
Du côté du produit application, ce que vous pouvez planifier en novembre, peut encore être correct en décembre, mais en février, ce n'est plus du tout la même chose.
Dans ma précédente entreprise, lorsque nous avons commencé à piloter le développement de fonctionnalités basé sur les capacités du modèle, le processus produit original s'est essentiellement effondré. Plus tard, c'est devenu lister toutes les directions intéressantes, faire des prototypes pour elles, juger lesquelles sont maintenant faisables, et mettre les autres temporairement de côté. Chaque fois que la capacité du modèle fait un nouveau bond, on reprend ces choses mises de côté pour les réessayer. Parce que qu'une fonctionnalité soit finalement suffisamment bonne ou non, la prémisse est souvent moins la forme de la fonctionnalité elle-même que l'intelligence du modèle. Beaucoup de gens ont toujours été mécontents de ma façon de planifier. Mais cette chose est确实 très difficile.
Lenny : Y a-t-il un exemple concret qui montre à quel point le timing est important ?
Andrew Ambrosino : Il y a une très bonne histoire à propos de 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 à être lancée en novembre, elle aurait été un échec total sur le marché. La seule différence est que le modèle s'est amélioré entre novembre et février. Le même produit, exactement la même forme, des résultats complètement différents, juste quelques mois de différence.
Lenny : Donc ce qui ne marche pas maintenant pourrait marcher plus tard ? Il faut garder une plus grande ambition ?
Andrew Ambrosino : Oui. Je recommande aux gens de ne pas facilement déterminer « cette chose ne marche pas maintenant, donc c'est une mauvaise fonctionnalité », elle n'est peut-être pas encore prête.
Revenons au lancement initial de Codex, Codex web. Basically vous donnez une tâche au modèle, il la fait, revient vous donner le résultat. Cela ne semble pas radical, mais le problème est qu'il ne le fait pas assez bien, cette forme était trop en avance.
Puis Claude Code est sorti, complètement local, pas de cloud, ne fait pas semblant d'être trop AGI. Il vous pose des questions, attend là, vous ne pouvez pas lui confier toute votre vie. Il est beaucoup plus utile, parce qu'il correspondait au niveau de capacité du modèle à l'époque.
Nous étions trop « AGI » à l'époque, je pense souvent à cette leçon. Auparavant, l'échec d'un produit sur le marché pouvait souvent vous en dire beaucoup sur la forme du produit ou la manière de communiquer. Maintenant c'est différent, vous pourriez avoir besoin de publier la même chose six fois jusqu'à ce qu'elle réussisse, la forme peut rester complètement inchangée.
Le navigateur dans l'application est aussi dans cette situation. Nous avions une version fonctionnelle auparavant,回到 l'époque d'Atlas, nous avions déjà des agents exécutant des tâches dans le navigateur. Encore avant c'était Operator dans ChatGPT, cela n'a pas réussi. Mais si vous reliez Operator, Atlas, Codex et ChatGPT, vous découvrirez qu'en fait une ligne d'évolution continue peut être tracée entre eux. Essentiellement la même fonctionnalité, juste avec le changement du niveau d'intelligence, elle est continuellement republiée, et le résultat change donc complètement.
Une fois qu'un produit ou une fonctionnalité existe déjà, les gens ont tendance à facilement focaliser leur attention sur divers problèmes de détails et micro-optimisations, et ils devraient确实 le faire. Mais c'est aussi pourquoi nous préservons toujours 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 à l'avenir. Vous ne pouvez pas attendre d'une même équipe qu'elle produise continuellement des innovations disruptives et se concentre toujours sur la qualité du produit et l'affinage des détails. À un certain stade, vous devez concevoir un mécanisme pour que ces deux capacités puissent exister simultanément.
Lenny : Quelle est la vision de Codex ? Où voulez-vous l'emmener ?
Andrew Ambrosino : En janvier et février de cette année, lors de nos tests internes en auto-utilisation, nous avons découvert qu'une PMF très claire s'était formée sur les flux de travail d'ingénierie et de recherche. Mais en même temps, les gens du marketing, de la communication, des finances, des affaires juridiques utilisaient aussi Codex, même si cette application n'était pas conviviale pour eux, elle leur montrerait du code, leur demanderait d'approuver l'exécution d'outils de recherche en ligne de commande.
Nous avons essayé d'ajouter les capacités de Codex à d'autres produits, l'application de bureau ChatGPT, le navigateur Atlas. Le résultat le plus ennuyeux est arrivé, personne ne voulait quitter l'application Codex, pour utiliser ces produits dits spécialement créés pour eux.
Cela nous a inspiré que entre les outils de développement et les outils de travail de connaissance générale, il existe en fait beaucoup de nuances communes. Nous croyons确实 que la forme de produit que nous sommes en train de construire est la forme correcte pour porter divers scénarios verticaux profonds. Commencer simple, puis augmenter progressivement la complexité selon les besoins.
Ce n'est pas le genre de produit « dessinez un rectangle sur l'écran, puis tout doit être accompli à l'intérieur ». Plus comme un camp de base, vous commencez le travail ici, terminez le travail, gérez les processus d'automatisation, et il appellera tous les outils dont vous avez besoin. Quelqu'un a appelé cette forme « super app », j'espère vraiment qu'ils ne l'ont pas appelée ainsi à l'époque, parce que maintenant je dois presque entendre ce mot chaque jour.
Dan Shipper a une idée très intéressante, il pense qu'à l'avenir nous utiliserons des outils SaaS « de l'intérieur vers l'extérieur » dans Codex, Notion, Linear, Salesforce ne sont pas ce que vous ouvrez dans le navigateur, mais l'agent les opère pour vous dans Codex. Nous faisons确实 ces choses, navigateur dans l'application, extension Chrome, computer use, tout cela sont des façons de permettre à Codex d'interagir avec des outils externes.
Un meilleur exemple, notre producteur vidéo interne Brent a utilisé Codex pour monter la vidéo de lancement de Codex. Codex n'est pas un éditeur vidéo, n'a pas ces UI. Mais il comprend que Brent utilise Premiere Pro, peut faire quelques modifications en éditant les fichiers derrière Premiere Pro. Quand il a découvert qu'il ne pouvait pas tout faire, il a écrit lui-même une extension plugin Premiere Pro, l'a installée dans Premiere Pro, puis a dialogué avec Premiere Pro via ce plugin. Quand nous avons vu cela, nous étions tous choqués.
C'est un très bon modèle, des outils professionnels font des choses professionnelles. Codex n'a pas besoin de devenir un meilleur éditeur vidéo, il lui suffit de pouvoir interagir de manière transparente avec des outils professionnels.
Savoir écrire du code n'est plus important, savoir supprimer du code est important
Lenny : De l'écriture de code à la main à l'IA écrivant 100 % du code, puis aux agents et loops actuels. Comment travaillent exactement les équipes les plus à la pointe maintenant ?
Andrew Ambrosino : Loops (boucles) ? C'était la semaine dernière.
Nous discutons toujours de la question « quelle proportion du produit est du code écrit par l'IA ». Selon les standards de l'année dernière, maintenant 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 », c'est une dimension complètement différente. Je welcome le fait que ce standard soit continuellement rafraîchi, parce que cela signifie que nous faisons des progrès produit.
Nous avons fait beaucoup d'exploration dans le développement logiciel autonome, comme beaucoup de harness engineering, comme « et si le modèle faisait automatiquement le garbage collection et le nettoyage de la base de code la nuit ? »
Mais actuellement tous les modèles ont un problème, ils augmentent toujours la complexité. Si des gens faisant de la recherche écoutent : s'il vous plaît, faites apprendre aux modèles à supprimer du code. Lorsque vous essayez de confier complètement le développement à la conduite automatique, cela devient un problème sérieux, que ce soit au niveau humain ou au niveau de la base de code.
Les Feature requests (demandes de fonctionnalités) sont aussi ainsi. Comment enseignez-vous au modèle à juger quelles fonctionnalités valent la peine d'être faites, lesquelles doivent être ignorées, lesquelles doivent être fusionnées et redéfinies ? Et comment enseignez-vous au modèle à construire les bonnes abstractions ?
Ces capacités continuent de progresser. Mais je ne pense pas que nous soyons arrivés à une étape où,设置 une boucle, laisser le modèle automatiquement « améliorer l'application », écouter continuellement Twitter, Slack et les emails, puis accomplir l'itération de manière autonome. Bien que, nous essayons确实 de rendre cette chose réalité.
Lenny : Pensez-vous que nous arriverons à cette étape ? C'est-à-dire设置 un objectif : « Gagner » ?
Andrew Ambrosino : « /goal gagnez-moi un milliard de dollars. » Je ne sais pas. Je ne dirai jamais jamais ou toujours comment.
Lenny : En tant que responsable produit et ingénierie, comment utilisez-vous l'IA pour travailler vous-même ?
Andrew Ambrosino : Je pense que j'ai peut-être maintenant le meilleur travail au monde.
Au début quand je faisais Codex, mon objectif personnel était de le rendre assez bon pour que je puisse l'utiliser pour écrire le code de Codex. C'était un cycle de produit d'auto-utilisation super serré, je ne pouvais pas faire une certaine chose, alors réparez-la, puis je peux la faire, puis je peux faire plus de choses.
Plus tard mon rôle a changé. Je devais faire plus de découverte produit, comprendre ce que l'équipe fait, corriger les choses qui dévient. Alors Codex est devenu l'outil pour que je fasse ces choses. « Aidez-moi à construire un tableur pour organiser ces données. » « Aidez-moi à faire une recherche interne approfondie, voir quelles explorations ont été faites dans cette direction auparavant. »
La série de lancements en mai, navigateur dans l'application, computer use, artifact creation, c'était la première fois que nous gérions un lancement avec vibe coordination. J'avais un document Notion enregistrant toutes les choses à faire, puis j'utilisais Codex pour automatiquement collecter les progrès dans les PR, les canaux Slack, mettre à jour le tracker de statut, à l'époque je pensais que c'était le plus à la pointe de la manière de gérer les lancements de produits.
Maintenant chaque matin je me lève, je regarde le rapport quotidien que Codex m'aide à générer, filtrant des 3000 canaux Slack auxquels j'ai rejoint les choses qui nécessitent mon attention. Je peux répondre « donnez-moi cinq questions, je vais y répondre ». Il s'auto-ajuste, je dis « la prochaine fois que vous courez, faites moins attention à ce flux de travail » ou « cette chose s'est produite mais n'est pas apparue dans le rapport quotidien, assurez-vous de l'attraper à l'avenir », il mettra à jour la méthode de notification, ajustera les points d'attention.
Lenny : Comment est-ce配置 ? Quel est le flux de travail ?
Andrew Ambrosino : C'est encore en phase de découverte. C'est juste faire une tâche planifiée : « Parcourez mes canaux Slack, voici les choses qui m'intéressent, organisez selon ces catégories, voici un peu de contexte. » Les premières fois que cela tourne peuvent nécessiter un guidage. Heureusement je n'ai pas besoin de chercher comment éditer les instructions, je dialogue directement « la prochaine fois aidez-moi à modifier ceci », et il met à jour.
Mais je pense que c'est aussi le problème central de la forme chatbot, je sais comment配置, parce que pour moi c'est de la découverte produit. Mais si vous ne travaillez pas chez OpenAI, ne développez pas cette chose, vous ne voudrez pas chercher à comprendre ces choses. Nous devons réfléchir à comment rendre ces formes utilisables pour les gens ordinaires.
Lenny : J'ai aussi utilisé Codex pour faire une automatisation de filtrage de spam. Une étape doit aller dans la console Google Cloud pour设置 un tas de déclencheurs API, cette interface est特别 ennuyeuse. J'ai laissé Codex m'aider à le faire, il a directement pris le contrôle de mon ordinateur, utilisant la fonction computer use pour opérer.
Andrew Ambrosino : C'est juste : « Je me fiche que vous ayez un connecteur ou non, mon vieux, je commence directement à cliquer. »
Comment diviser les frontières entre connecteurs, navigateur dans l'application, extension Chrome et computer use, est une chose très intéressante. Souvent, ces frontières sont en fait explorées au feeling.
Je pense que ces flux de travail personnels sont特别 intéressants. Tout le monde essaie toutes sortes de choses, tout le monde construira des systèmes complètement différents. Mais lentement, certains modèles communs émergeront. Puis nous réaliserons : « Cela devrait devenir une expérience de premier niveau dans le produit. »
Par exemple la mémoire (memory), beaucoup de gens configurent une base de connaissances Obsidian ou un espace Notion pour construire leur propre palais mental. Vous ne devriez pas avoir besoin de faire cela vous-même, il devrait y avoir une fonction de mémoire suffisamment générique pour le faire pour vous. Nous filtrons continuellement, ce qui est efficace pour les individus mais devrait rester au niveau individuel, ce qui devrait entrer dans le produit pour devenir un composant de base.
Lenny : Les gens dehors voient seulement que vous gagnez. Mais il y a肯定 des choses qui n'ont pas réussi ?
Andrew Ambrosino : Vous entendre décrire c'est assez drôle. C'est en fait la première fois que je sens que je ne suis pas en échec.
J'ai fait beaucoup d'années de startup auparavant, finalement基本 c'était démonter l'entreprise et la vendre. Faire dans des industries hautement régulées, tout le processus comme un échec continu. Plus tard je suis allé dans une autre startup, faire des outils IA dans une autre industrie fermée et régulée, aussi encore et encore ça ne marchait pas. J'ai en fait échoué beaucoup. Parfois c'est juste un point dans le temps, les compétences, la passion et la fenêtre de marché s'alignent恰好.
Même dans ce projet qui combine Codex et ChatGPT maintenant, il y a d'innombrables petits échecs. Nous disons « cela devrait ressembler à ça », envoyons dans Slack, en dessous il y a 2000 messages disant combien nous sommes stupides. C'est ce que j'aime chez OpenAI, les gens nous le disent directement, sans pitié pour les échecs des produits internes, c'est aussi pourquoi les produits externes sont bien faits. Avant d'arriver à cette position maintenant, j'ai échoué environ 10 à 15 ans. Donc chaque jour je me sens encore un peu surpris, que les choses se passent en fait smoothly.
Lenny : Avez-vous des derniers conseils pour les lecteurs ?
Andrew Ambrosino : Ne vous « liez à vie » avec votre flux de travail actuel. Ce qui devrait vraiment être persisté, ce sont ces résultats que vous seul pouvez livrer de manière unique. Puis, essayez continuellement de changer votre flux. Si la compétence dont vous êtes le plus fier est « je connais le mieux l'auto layout de Figma », alors que faites-vous ? L'IA deviendra aussi meilleure que vous. Trouvez des choses qui valent la peine d'être faites, puis trouvez des moyens de faire ces choses.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
