traduction
This commit is contained in:
File diff suppressed because one or more lines are too long
@@ -0,0 +1,159 @@
|
||||
# Du Vibe Coding à l'Agentic Engineering — Andrej Karpathy
|
||||
|
||||
Transcript du fireside chat de conférence avec Andrej Karpathy ([@karpathy](https://x.com/karpathy)), chercheur en IA et membre fondateur d'OpenAI, publié le 2 mai 2026.
|
||||
|
||||
<table width="100%">
|
||||
<tr>
|
||||
<td><a href="../">← Retour à Claude Code Best Practice</a></td>
|
||||
<td align="right"><img src="../../!/claude-jumping.svg" alt="Claude" width="60" /></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
---
|
||||
|
||||
## Détails de la vidéo
|
||||
|
||||
- **Intervenant :** Andrej Karpathy (chercheur en IA, membre fondateur d'OpenAI, ex-directeur IA de Tesla)
|
||||
- **Format :** Fireside chat de conférence
|
||||
- **Publié :** 2 mai 2026
|
||||
- **YouTube :** [Regarder sur YouTube](https://www.youtube.com/watch?v=96jN2OCOfLs)
|
||||
|
||||
---
|
||||
|
||||
## Transcript
|
||||
|
||||
### Introduction
|
||||
|
||||
Nous sommes très enthousiastes pour notre tout premier invité spécial. Il a aidé à construire l'IA moderne, puis à expliquer l'IA moderne, et puis occasionnellement à renommer l'IA moderne. Il a en fait co-fondé OpenAI ici même, dans ces bureaux. C'est lui qui a fait fonctionner l'Autopilot chez Tesla à l'époque, et il a le don rare de rendre les bascules techniques les plus complexes à la fois accessibles et inévitables. Vous le connaissez tous pour avoir inventé le terme vibe coding l'an dernier, mais ces derniers mois, il a dit quelque chose d'encore plus saisissant : qu'il ne s'était jamais senti aussi à la traîne en tant que programmeur. C'est par là qu'on commence aujourd'hui. Merci, Andrej, de te joindre à nous.
|
||||
|
||||
Oui. Bonjour. Ravi d'être ici et de lancer les choses.
|
||||
|
||||
### « Jamais senti aussi à la traîne en tant que programmeur »
|
||||
|
||||
Bon. Il y a quelques mois, tu as dit que tu ne t'étais jamais senti aussi à la traîne en tant que programmeur. C'est saisissant à entendre, de ta part en plus. Peux-tu nous aider à décortiquer ça ? Ce sentiment était-il exaltant ou déstabilisant ?
|
||||
|
||||
Oui, un mélange des deux à coup sûr. D'abord, comme beaucoup d'entre vous, j'utilise des outils agentiques comme Claude Code, et des choses voisines, depuis un moment, peut-être sur la dernière année à mesure que c'est sorti, et c'était très bon sur des bouts de code et parfois ça se plantait et il fallait les éditer et c'était plutôt utile. Et puis je dirais que décembre a été ce point clair où, pour moi — j'étais en pause donc j'avais un peu plus de temps. Je pense que beaucoup d'autres gens étaient pareils — et j'ai juste commencé à remarquer qu'avec les derniers modèles les bouts sortaient tout simplement nickel, puis j'en demandais davantage et ça sortait nickel, et puis je ne me souviens plus de la dernière fois où j'ai corrigé quoi que ce soit. Et alors j'ai juste fait de plus en plus confiance au système et je faisais du vibe coding.
|
||||
|
||||
C'était donc une transition très nette. Je pense que beaucoup de gens en fait — j'ai essayé d'insister là-dessus sur Twitter, ou X — parce que je pense que beaucoup de gens ont vécu l'IA l'an dernier comme un truc proche de ChatGPT. Mais il fallait vraiment regarder à nouveau, et regarder à partir de décembre, parce que les choses ont changé fondamentalement — surtout sur ce workflow agentique cohérent qui a vraiment commencé à fonctionner. Et donc je dirais que c'est juste cette prise de conscience qui m'a fait plonger dans tout ce terrier de projets parallèles à l'infini. Mon dossier de projets parallèles est extrêmement plein de plein de trucs au hasard, et juste à faire du vibe coding tout le temps. Donc ça s'est passé en décembre, je dirais, et j'observe les répercussions de ça depuis.
|
||||
|
||||
### Software 3.0 : le nouveau paradigme informatique
|
||||
|
||||
Tu as beaucoup parlé de cette idée des LLM comme un nouvel ordinateur. Que ce n'est pas juste un meilleur logiciel, c'est tout un nouveau paradigme informatique. Software 1.0, c'étaient des règles explicites, Software 2.0, des poids appris, Software 3.0, c'est ça. Si c'est vraiment vrai, qu'est-ce qu'une équipe construit différemment le jour où elle y croit vraiment ?
|
||||
|
||||
Exact. Donc Software 1.0, j'écris du code, Software 2.0, je programme en réalité en créant des jeux de données et en entraînant des réseaux de neurones. Donc la programmation revient à arranger des jeux de données et peut-être quelques objectifs et architectures de réseau de neurones. Et puis ce qui s'est passé, c'est que si tu entraînes un de ces modèles GPT ou LLM sur un ensemble suffisamment large de tâches — implicitement, parce qu'en t'entraînant sur Internet tu dois multitâcher toutes les choses qui sont dans le jeu de données — ceux-ci deviennent en réalité une sorte d'ordinateur programmable dans un certain sens.
|
||||
|
||||
Donc Software 3.0, c'est en gros que ta programmation se transforme maintenant en prompting, et ce qui est dans la fenêtre de contexte est ton levier sur l'interpréteur qu'est le LLM qui interprète ton contexte et effectue du calcul dans l'espace de l'information numérique.
|
||||
|
||||
Je pense qu'il y a quelques exemples qui m'ont vraiment fait toucher ça du doigt. Par exemple, quand OpenClaw est sorti, quand tu veux installer OpenClaw tu t'attendrais normalement à ce que ce soit un script bash, genre un script shell. Donc lance le script shell pour installer OpenClaw. Mais le truc, c'est que pour cibler plein de plateformes différentes et plein de types d'ordinateurs sur lesquels tu pourrais faire tourner OpenClaw, ces scripts shell enflent généralement et deviennent extrêmement complexes. Sauf que tu es toujours coincé dans un univers Software 1.0 où tu veux écrire le code. Et en réalité l'installation d'OpenClaw est un copier-coller d'un paquet de texte que tu es censé donner à ton agent. Donc c'est en gros un petit skill « copie-colle ceci et donne-le à ton agent et il installera OpenClaw ». Et la raison pour laquelle c'est beaucoup plus puissant, c'est que tu travailles maintenant dans le paradigme Software 3.0 où tu n'as pas à épeler précisément tous les détails individuels de cette installation. L'agent a sa propre intelligence qu'il empaquette et il suit en quelque sorte les instructions et il regarde ton environnement, ton ordinateur, et il effectue des actions intelligentes pour faire marcher les choses et il débogue les trucs dans la boucle. C'est juste tellement plus puissant. Donc c'est une façon très différente d'y penser — quel est le morceau de texte à copier-coller à ton agent ? Ça, c'est le paradigme de programmation.
|
||||
|
||||
### MenuGen et « l'app qui ne devrait pas exister »
|
||||
|
||||
Maintenant un autre exemple qui me vient à l'esprit, encore plus extrême, c'est quand je construisais MenuGen. MenuGen, c'est cette idée où tu viens dans un restaurant, on te donne un menu. Il n'y a généralement pas de photos. Donc je ne sais pas ce que sont tous ces trucs — d'habitude genre 30% des choses je n'ai aucune idée de ce que c'est, 50%. Donc je voulais prendre une photo du menu du restaurant et obtenir des images de ce à quoi ces choses pourraient ressembler dans un sens générique.
|
||||
|
||||
J'ai vibe-codé cette app qui te laisse en gros uploader une photo et fait tout ce truc et tourne sur Vercel et re-rend en gros le menu et te donne tous les items et te donne une image — elle utilise un générateur d'images pour OCR tous les différents titres, utilise le générateur d'images pour en obtenir des photos, puis te les montre.
|
||||
|
||||
Et puis j'ai vu la version Software 3.0 de ça — qui m'a bluffé — qui consiste littéralement à juste prendre ta photo, la donner à Gemini et dire « utilise Nanobanana pour superposer les choses sur le menu ». Et Nanobanana a en gros renvoyé une image qui est exactement la photo du menu que j'ai prise, mais qui a en réalité mis dans les pixels — a rendu les différentes choses du menu. Et ça m'a bluffé parce qu'en réalité tout mon MenuGen est superflu. Il travaille dans l'ancien paradigme. Cette app ne devrait pas exister.
|
||||
|
||||
Le paradigme Software 3.0 est bien plus brut. Ton réseau de neurones fait de plus en plus le travail et ton prompt ou contexte n'est que l'image et la sortie est une image et il n'y a pas besoin d'avoir toute l'app entre les deux. Donc les gens doivent recadrer — ne pas travailler dans le paradigme existant de ce qui existait et juste le voir comme une accélération de ce qui existe. De nouvelles choses sont disponibles maintenant.
|
||||
|
||||
Et pour revenir à ta question sur la programmation, ce n'est même pas — je pense que c'est aussi un exemple de travailler dans l'ancien état d'esprit, parce que ce n'est pas juste que la programmation devient plus rapide. C'est du traitement de l'information plus général qui est automatisable maintenant. Donc ce n'est même pas juste du code. Le code précédent travaillait sur des données structurées, non ? Tu écris du code sur des données structurées. Mais par exemple, avec mon projet de bases de connaissances LLM — en gros tu fais créer aux LLM des wikis pour ton organisation ou pour toi personnellement — ce n'est même pas un programme. Ce n'est pas quelque chose qui pouvait exister avant parce qu'il n'y avait pas de code qui créerait une base de connaissances à partir d'un tas de faits. Mais maintenant tu peux juste prendre ces documents et en gros les recompiler d'une façon différente et les réordonner et créer quelque chose de nouveau et d'intéressant comme recadrage des données. Ce sont de nouvelles choses qui n'étaient pas possibles. Donc je pense que c'est quelque chose sur lequel je reviens sans cesse : non seulement ce qu'on peut faire qui existait et qui est plus rapide maintenant, mais je pense qu'il y a de nouvelles opportunités de choses qui ne pouvaient pas être possibles avant, et je trouve presque que c'est plus excitant.
|
||||
|
||||
### Extrapoler vers 2026 et au-delà
|
||||
|
||||
J'adore la progression et la dichotomie de MenuGen que tu as exposées. Si tu extrapoles davantage, quel est l'équivalent 2026 de construire des sites web dans les années 90, des apps mobiles dans les années 2010, du SaaS dans la dernière ère du cloud ? Qu'est-ce qui paraîtra complètement évident avec le recul mais qui reste largement non construit aujourd'hui ?
|
||||
|
||||
En reprenant l'exemple du menu, beaucoup de ce code ne devrait pas exister et c'est juste le réseau de neurones qui fait l'essentiel du travail. Je pense que l'extrapolation a l'air très bizarre, parce que tu pourrais en gros imaginer des ordinateurs entièrement neuronaux dans un certain sens. Tu alimentes des vidéos brutes — imagine un appareil qui prend des vidéos ou de l'audio brut dans ce qui est en gros un réseau de neurones — et qui utilise la diffusion pour rendre une UI unique pour ce moment dans un certain sens.
|
||||
|
||||
J'ai un peu l'impression qu'aux débuts de l'informatique, les gens étaient un peu confus quant à savoir si les ordinateurs ressembleraient à des calculatrices ou à des réseaux de neurones. Et dans les années 50 et 60, ce n'était pas vraiment évident dans quelle direction ça irait. Et bien sûr on a pris la voie de la calculatrice et on a fini par construire l'informatique classique, et les réseaux de neurones tournent actuellement virtualisés sur des ordinateurs existants. Mais je pense que beaucoup de ça va basculer et que le réseau de neurones devienne le processus hôte et que les CPU deviennent le coprocesseur. Donc on a vu le diagramme du calcul d'intelligence : les réseaux de neurones vont prendre le dessus et devenir la dépense dominante de FLOPs. Donc tu pourrais imaginer quelque chose de vraiment bizarre et étranger où les réseaux de neurones font l'essentiel du gros travail. Ils utilisent l'usage d'outils comme cet appendice historique pour certains types de tâches déterministes. Mais ce qui mène vraiment la danse, ce sont ces réseaux de neurones. Donc tu peux imaginer quelque chose d'extrêmement étranger comme extrapolation, mais je pense qu'on va probablement y arriver pièce par pièce.
|
||||
|
||||
### Vérifiabilité et intelligence en dents de scie
|
||||
|
||||
J'aimerais parler un peu de ce concept de vérifiabilité — le fait que l'IA automatisera plus vite et plus facilement les domaines où la sortie peut être vérifiée. Si ce cadre est juste, quel travail est sur le point d'aller bien plus vite que les gens ne le réalisent, et quelles professions croit-on à l'abri alors qu'elles sont en réalité hautement vérifiables ?
|
||||
|
||||
J'ai passé du temps à écrire sur la vérifiabilité. En gros, les ordinateurs traditionnels peuvent facilement automatiser ce que tu peux spécifier en code, et cette dernière vague de LLM peut facilement automatiser ce que tu peux vérifier, dans un certain sens, parce que la façon dont ça marche, c'est que quand les labos de pointe entraînent ces LLM, ce sont des environnements géants d'apprentissage par renforcement. Donc on leur donne des récompenses de vérification et, à cause de la façon dont ces modèles sont entraînés, ils finissent en gros par progresser et créer ces entités en dents de scie qui culminent vraiment en capacité dans des domaines vérifiables comme les maths, le code et voisins — et stagnent et sont un peu rugueuses sur les bords quand les choses ne sont pas dans cet espace.
|
||||
|
||||
Donc la raison pour laquelle j'ai écrit sur la vérifiabilité, c'est que j'essaie de comprendre pourquoi ces trucs sont si en dents de scie. Une partie tient à la façon dont les labos entraînent les modèles, mais je pense qu'une partie tient aussi à l'attention des labos et à ce qu'ils mettent dans la distribution de données. Parce que certaines choses sont nettement plus précieuses dans l'économie et finissent par créer plus d'environnements parce que les labos voulaient travailler dans ces contextes. Donc je pense que le code en est un bon exemple. Il y a probablement plein d'environnements vérifiables auxquels ils pourraient penser et qui n'entrent pas dans le mélange parce qu'ils ne sont juste pas si utiles à avoir comme capacité.
|
||||
|
||||
Le grand mystère — l'exemple favori pendant un temps était « combien de lettres y a-t-il dans strawberry », et les modèles se trompaient fameusement, et c'est un exemple de dents de scie. Les modèles patchent ça maintenant, je crois. Mais le nouveau, c'est : « je veux aller à un lave-auto pour laver ma voiture et c'est à 50 mètres. Devrais-je conduire ou marcher ? » Et les modèles de pointe aujourd'hui te diront de marcher parce que c'est si proche. Comment est-ce possible qu'Opus 4.7, à la pointe, refactore simultanément un codebase de 100 000 lignes, ou trouve des vulnérabilités zero-day, et pourtant me dise de marcher jusqu'à ce lave-auto ? C'est dingue.
|
||||
|
||||
Dans la mesure où ces modèles restent en dents de scie, c'est une indication que, un, peut-être que quelque chose cloche légèrement, ou deux, tu dois en fait être un peu dans la boucle et les traiter comme des outils et tu dois rester en contact avec ce qu'ils font. Donc toute mon écriture, en bref, sur la vérifiabilité, c'est juste essayer de comprendre pourquoi ces trucs sont en dents de scie. Y a-t-il un motif ? Et je pense que c'est une sorte de combinaison de vérifiable plus « les labos s'en soucient ».
|
||||
|
||||
Peut-être une anecdote de plus, instructive : de GPT-3.5 à GPT-4, les gens ont remarqué que les échecs s'étaient beaucoup améliorés, et beaucoup de gens ont pensé « oh, c'est juste une progression des capacités » — mais en réalité c'est plutôt qu'une énorme quantité de données d'échecs est entrée dans le pré-entraînement, et juste parce que c'est dans une distribution de données, le modèle s'est bien plus amélioré qu'il ne l'aurait fait par défaut. Donc quelqu'un chez OpenAI a décidé d'ajouter ces données et maintenant tu as une capacité qui a beaucoup plus culminé.
|
||||
|
||||
Donc c'est pour ça que j'insiste sur cette dimension : nous sommes un peu à la merci de ce que font les labos, de ce qu'ils mettent dans le mélange. Et tu dois en fait explorer ce truc qu'ils te donnent et qui n'a pas de manuel. Ça marche dans certains contextes, mais peut-être pas dans d'autres. Si tu es dans les circuits qui faisaient partie du RL, tu voles. Et si tu es dans les circuits hors de la distribution de données, tu vas galérer et tu dois trouver dans quels circuits tu es dans ton application. Et si tu n'es pas dans les circuits, alors tu dois vraiment regarder le fine-tuning et faire une partie de ton propre travail parce que ça ne va pas nécessairement sortir du LLM d'origine.
|
||||
|
||||
### Conseils aux fondateurs
|
||||
|
||||
Si tu es fondateur aujourd'hui et que tu penses à construire une entreprise, tu essaies de résoudre un problème que tu juges traitable, un domaine vérifiable, mais tu regardes autour de toi et tu te dis « oh mon dieu, les labos ont vraiment commencé à atteindre la vitesse de libération sur ceux qui semblent les plus évidents — maths, code, et autres ». Quel serait ton conseil aux fondateurs dans l'audience ?
|
||||
|
||||
Je pense que la vérifiabilité rend quelque chose traitable dans le paradigme actuel parce que tu peux lui balancer une énorme quantité de RL. Donc une façon de le voir, c'est que ça reste vrai même si les labos ne s'y concentrent pas directement. Donc si tu es dans un contexte vérifiable où tu pourrais créer ces environnements ou exemples de RL, alors ça te met en position de potentiellement faire ton propre fine-tuning et tu pourrais en bénéficier. C'est fondamentalement une technologie qui marche juste. Tu peux actionner un levier si tu as une énorme quantité de jeux de données diversifiés d'environnements de RL, tu peux utiliser ton framework de fine-tuning favori et actionner le levier et obtenir quelque chose qui marche plutôt bien.
|
||||
|
||||
Je pense qu'il y a des environnements d'apprentissage par renforcement très précieux auxquels les gens pourraient penser et qui, je pense, ne font pas partie de [l'attention des labos]. Je ne veux pas dévoiler la réponse, mais il y a un domaine que je trouve très [précieux]. Désolé, je ne veux pas faire du vague-posting sur scène, mais il y a des exemples de ça.
|
||||
|
||||
À l'inverse, qu'est-ce qui, selon toi, ne semble encore automatisable que de loin ?
|
||||
|
||||
Je pense qu'au final presque tout peut être rendu vérifiable dans une certaine mesure — certaines choses plus facilement que d'autres. Parce que même pour des choses comme l'écriture, tu peux imaginer avoir un conseil de juges LLM et arriver probablement à quelque chose de raisonnable avec ce type d'approche. Donc c'est plutôt une question de ce qui est facile ou difficile. Je pense qu'au final tout est automatisable.
|
||||
|
||||
### Vibe Coding vs Agentic Engineering
|
||||
|
||||
L'an dernier tu as inventé le terme vibe coding et aujourd'hui on est dans un monde qui semble un peu plus sérieux — plus de l'agentic engineering. Quelle est selon toi la différence entre les deux et comment appellerais-tu vraiment ce dans quoi on est aujourd'hui ?
|
||||
|
||||
Oui. Je dirais que le vibe coding consiste à relever le plancher pour tout le monde quant à ce qu'on peut faire en logiciel. Donc le plancher monte, tout le monde peut vibe-coder n'importe quoi, et c'est génial, incroyable. Mais je dirais que l'agentic engineering consiste à préserver le niveau de qualité de ce qui existait avant dans le logiciel professionnel. Donc tu n'as pas le droit d'introduire des vulnérabilités à cause du vibe coding. Tu restes responsable de ton logiciel comme avant, mais peux-tu aller plus vite ? Et spoiler : oui. Mais comment le fais-tu correctement ? Et donc pour moi l'agentic engineering — quand je l'appelle ainsi, car je pense que c'est une discipline d'ingénierie — tu as ces agents qui sont ces entités hérissées. Ils sont un peu faillibles, un peu stochastiques, mais ils sont extrêmement puissants. Comment les coordonnes-tu pour aller plus vite sans sacrifier ton niveau de qualité ? Faire ça bien et correctement, c'est le domaine de l'agentic engineering.
|
||||
|
||||
Donc je les vois comme différents — l'un consiste à relever le plancher et l'autre à extrapoler. Et ce que je vois, c'est qu'il y a un plafond très élevé sur la capacité d'un agentic engineer. Les gens parlaient avant de l'ingénieur 10x — je pense que c'est beaucoup plus amplifié. 10x n'est pas l'accélération que tu gagnes. Il me semble que les gens qui sont très bons à ça culminent beaucoup plus que 10x, de mon point de vue actuel.
|
||||
|
||||
### À quoi ressemble le code AI-natif
|
||||
|
||||
Une chose mémorable que Sam Altman a dite quand il est venu à AI Engineer l'an dernier, c'est que les gens de générations différentes utilisent ChatGPT différemment. Si tu as la trentaine, tu l'utilises comme un remplacement de recherche Google. Mais si tu es ado, ChatGPT est ta porte d'entrée vers Internet. Quel est le parallèle ici dans le code aujourd'hui ? Si on regardait deux personnes coder avec OpenClaw, Claude Code, Codex — l'une que tu jugerais médiocre et l'autre que tu jugerais pleinement AI-native — comment décrirais-tu la différence ?
|
||||
|
||||
Je pense que c'est juste essayer de tirer le maximum des outils disponibles — exploiter toutes leurs fonctionnalités, investir dans ta propre configuration. Donc comme avant tous les ingénieurs tiraient en gros le maximum des outils qu'ils utilisent — que ce soit Vim ou VS Code ou maintenant Claude Code ou Codex — investir dans ta configuration et exploiter beaucoup des outils qui te sont disponibles. Je pense que ça ressemble juste à ça.
|
||||
|
||||
Une pensée connexe — beaucoup de gens recrutent peut-être pour ça en ce moment, parce qu'ils veulent embaucher de forts agentic engineers. Je pense que la plupart des gens n'ont toujours pas refactoré leur processus de recrutement pour la capacité d'agentic engineer. Si tu donnes des énigmes à résoudre, c'est encore l'ancien paradigme. Je dirais que le recrutement doit ressembler à : donne-moi un très gros projet et regarde quelqu'un implémenter ce gros projet. Genre écrivons un clone de Twitter pour agents puis rendons-le vraiment bon, vraiment sécurisé, puis ayons des agents qui simulent de l'activité sur ce Twitter, et ensuite je vais utiliser 10 Codex 5.4x for X high pour essayer de casser ton site que tu as déployé, et ils vont essayer de le casser et ils ne devraient pas pouvoir. Donc peut-être que ça ressemble à ça. Regarder les gens dans ce contexte, construire de plus gros projets et exploiter l'outillage, c'est peut-être ce que je regarderais pour l'essentiel.
|
||||
|
||||
### Goût, jugement et l'humain dans la boucle
|
||||
|
||||
À mesure que les agents en font davantage, quelle compétence humaine devient selon toi plus précieuse, pas moins ?
|
||||
|
||||
En ce moment, la réponse, c'est que les agents sont un peu comme ces entités stagiaires. Donc c'est remarquable — tu dois en gros encore être en charge de l'esthétique, du jugement, du goût, et d'un peu de supervision.
|
||||
|
||||
Un de mes exemples favoris de la bizarrerie des agents, c'est — pour MenuGen, tu t'inscris avec un compte Google mais tu achètes des crédits avec un compte Stripe, et les deux ont des adresses e-mail. Mon agent a en fait essayé, à l'achat de crédits, de l'associer en utilisant l'adresse e-mail de Stripe à l'adresse e-mail Google — comme s'il n'y avait pas d'identifiant utilisateur persistant. Pour les gens, il essayait de faire correspondre les adresses e-mail, mais tu pourrais utiliser une adresse e-mail différente pour ton Stripe et ton Google et donc il n'associerait pas les fonds. C'est le genre de chose sur laquelle ces agents se trompent encore — genre pourquoi utiliserais-tu des adresses e-mail pour essayer de corréler les fonds ? Elles peuvent être arbitraires. Tu peux utiliser des e-mails différents. C'est une chose si bizarre à faire.
|
||||
|
||||
Donc je pense que les gens doivent être en charge de cette spec, ce plan. Et en fait je n'aime même pas le mode plan. Évidemment c'est très utile, mais je pense qu'il y a quelque chose de plus général ici où tu dois travailler avec ton agent pour concevoir une spec très détaillée — peut-être en gros les docs — puis faire écrire les agents pendant que tu es en charge de la supervision et des catégories de haut niveau, mais les agents font beaucoup du sous-le-capot. Donc tu ne te soucies pas de certains détails.
|
||||
|
||||
Comme exemple aussi, avec les tableaux ou tenseurs dans les réseaux de neurones. Il y a une tonne de détails entre PyTorch et NumPy et tous les différents — Pandas et ainsi de suite — pour tous les petits détails d'API. Et j'ai déjà oublié le keep_dims versus keep_dim, ou si c'est `dim` ou `axis`, ou reshape ou permute ou transpose. Je ne me souviens plus de ce truc. Parce que tu n'as pas à le faire. C'est le genre de détails gérés par le stagiaire parce qu'il a une très bonne mémoire de rappel. Mais tu dois quand même savoir, par exemple, qu'il y a un tenseur sous-jacent, une vue sous-jacente, et que tu peux manipuler la vue du même stockage ou avoir un stockage différent qui serait moins efficace. Donc tu dois quand même avoir une compréhension de ce que ce truc fait et de certains fondamentaux pour ne pas copier de la mémoire inutilement, etc. Mais les détails des API sont maintenant délégués. Donc tu es en charge du goût, de l'ingénierie, du design — et que ça ait du sens et que tu demandes les bonnes choses. Que, OK, ce doivent être des identifiants utilisateur uniques auxquels on va tout rattacher. Donc tu fais une partie du design et du développement et les ingénieurs font le remplissage des trous. C'est là où on en est actuellement.
|
||||
|
||||
Penses-tu qu'il y a une chance que ce goût et ce jugement comptent moins avec le temps, ou que le plafond continuera juste de monter ?
|
||||
|
||||
J'espère que ça s'améliore. Je pense que la raison pour laquelle ça ne s'améliore pas en ce moment, c'est, encore une fois, que ça ne fait pas partie du RL. Il n'y a probablement pas de coût ou de récompense esthétique, ou ce n'est pas assez bon ou quelque chose comme ça. Je pense que quand tu regardes vraiment le code, parfois j'ai un petit infarctus parce que ce n'est pas nécessairement du code super génial tout le temps. Et c'est très boursouflé et il y a beaucoup de copier-coller et il y a des abstractions maladroites qui sont fragiles et ça marche mais c'est juste vraiment dégueu. J'espère vraiment que ça pourra s'améliorer dans les futurs modèles.
|
||||
|
||||
Un bon exemple aussi, c'est ce projet microGPT où j'essayais de simplifier l'entraînement de LLM pour qu'il soit aussi simple que possible. Les modèles détestent ça. Ils n'y arrivent pas. J'ai essayé de continuer à prompter un LLM pour simplifier plus, simplifier plus, et il n'y arrive juste pas. Tu as l'impression d'être hors des circuits du RL. Tu as l'impression d'arracher des dents. Ce n'est pas la vitesse de la lumière. Donc je pense que les gens restent en charge de ça. Mais il n'y a rien de fondamental qui l'empêche. C'est juste que les labos ne l'ont pas encore fait, presque.
|
||||
|
||||
### Animaux vs fantômes : comprendre ce que sont les LLM
|
||||
|
||||
J'aimerais revenir à cette idée de formes d'intelligence en dents de scie. Tu as écrit un texte stimulant sur les animaux versus les fantômes. L'idée, c'est qu'on ne construit pas des animaux, on invoque des fantômes. Et ce sont des formes d'intelligence en dents de scie façonnées par les données et les fonctions de récompense, mais pas par la motivation intrinsèque ou le plaisir ou la curiosité ou l'autonomisation — des choses apparues via l'évolution. Pourquoi ce cadrage importe-t-il et qu'est-ce qu'il change réellement à la façon dont tu les construis, déploies, évalues, voire leur fais confiance ?
|
||||
|
||||
La raison pour laquelle j'ai écrit là-dessus, c'est que j'essaie de saisir ce que sont ces choses. Parce que si tu as un bon modèle de ce qu'elles sont ou ne sont pas, tu seras plus compétent à les utiliser. Je ne suis pas sûr que ça ait un vrai pouvoir. Je pense que c'est un peu de la philosophie. Mais c'est juste accepter le fait que ces choses ne sont pas des intelligences animales. Genre si tu leur cries dessus, elles ne vont pas mieux ou moins bien travailler — ça n'a aucun impact. Ce ne sont que des circuits de simulation statistique où le substrat est le pré-entraînement (donc des statistiques) et puis il y a du RL boulonné par-dessus, qui augmente en quelque sorte les appendices. Peut-être que c'est juste un état d'esprit avec lequel j'arrive, ou ce qui est susceptible de marcher ou non, ou comment le modifier. Mais je n'ai pas vraiment « voici les cinq résultats évidents pour rendre ton système meilleur ». C'est plutôt juste s'en méfier et comprendre avec le temps. C'est là que ça commence.
|
||||
|
||||
### Infrastructure agent-native
|
||||
|
||||
Bon, donc tu es tellement plongé dans le travail avec des agents qui ne se contentent pas de discuter — ils ont de vraies permissions, du contexte local, ils agissent réellement en ton nom. À quoi ressemble le monde quand on commence tous à vivre dans ce monde ?
|
||||
|
||||
Je pense que beaucoup de gens ici sont sans doute enthousiastes quant à ce à quoi ressemble cet environnement agentique agent-native. Tout doit être réécrit. Tout est encore fondamentalement écrit pour les humains et doit être déplacé. La plupart du temps quand j'utilise différents frameworks ou bibliothèques ou choses comme ça, ils ont encore des docs fondamentalement écrites pour les humains. C'est ma bête noire favorite. Pourquoi les gens me disent-ils encore quoi faire ? Je ne veux rien faire. Quelle est la chose que je devrais copier-coller à mon agent ? Chaque fois qu'on me dit « va à cette URL » ou un truc comme ça, c'est juste genre ahh.
|
||||
|
||||
Tout le monde est enthousiaste à propos de comment décomposer les charges de travail à effectuer en, fondamentalement, des capteurs sur le monde, des actionneurs sur le monde. Comment le rendre agent-native ? En gros le décrire d'abord aux agents. Et puis avoir beaucoup d'automatisation autour de structures de données très lisibles pour les LLM.
|
||||
|
||||
Pour MenuGen, fameusement quand j'ai écrit le billet de blog sur MenuGen — une bonne partie de la difficulté n'était même pas d'écrire le code de MenuGen, c'était de le déployer sur Vercel, parce que je devais travailler avec tous ces différents services et les ficeler ensemble et aller dans leurs réglages et les menus et configurer mon DNS et c'était juste tellement pénible. Donc c'est un bon exemple de : j'aimerais pouvoir donner un prompt à un LLM « construis MenuGen » et ne plus avoir à toucher à rien et que ce soit déployé de la même façon sur Internet. Je pense que ce serait un bon test pour savoir si oui ou non une grande partie de notre infrastructure devient de plus en plus agent-native.
|
||||
|
||||
Au final je pense qu'on va vers un monde où il y a une représentation par agent pour les gens et les organisations. « Je vais faire parler mon agent à ton agent » pour régler une partie des détails de nos réunions ou des choses comme ça. Donc je pense que c'est globalement là où vont les choses.
|
||||
|
||||
### Éducation : externaliser la réflexion, pas la compréhension
|
||||
|
||||
Je pense qu'on doit finir sur une question d'éducation. Parce que tu es probablement l'un des tout meilleurs au monde pour rendre simples des concepts techniques complexes, et profondément réfléchi sur la façon dont on conçoit l'éducation autour. Qu'est-ce qui reste digne d'être appris en profondeur quand l'intelligence devient bon marché à mesure qu'on entre dans la prochaine ère de l'IA ?
|
||||
|
||||
Il y a eu un tweet qui m'a bluffé récemment et auquel je pense genre tous les deux jours. C'était quelque chose comme : **« Tu peux externaliser ta réflexion mais tu ne peux pas externaliser ta compréhension. »**
|
||||
|
||||
Je trouve ça vraiment bien formulé. Parce que je fais encore partie du système et je dois encore d'une façon ou d'une autre — l'information doit encore arriver dans mon cerveau — et j'ai l'impression de devenir un goulot d'étranglement ne serait-ce que pour savoir ce qu'on essaie de construire, pourquoi ça vaut le coup, comment je dirige mes agents, etc. Donc je pense encore qu'au final quelque chose doit diriger la réflexion et le traitement, et c'est encore fondamentalement contraint d'une façon ou d'une autre par la compréhension.
|
||||
|
||||
C'est une des raisons pour lesquelles j'étais aussi très enthousiaste à propos de toutes les bases de connaissances LLM — parce que j'ai l'impression que c'est une façon pour moi de traiter l'information. Chaque fois que je vois une projection différente sur l'information, j'ai toujours l'impression de gagner en compréhension. Donc ce ne sont vraiment que beaucoup de prompts pour faire de la génération de données synthétiques sur des données fixes. J'adore vraiment chaque fois que je lis un article — j'ai mon wiki qui se construit à partir de ces articles et j'adore poser des questions sur les choses. Je pense qu'au final ce sont des outils pour renforcer la compréhension d'une certaine façon. Et c'est encore un peu un goulot d'étranglement, parce qu'ensuite tu ne peux pas diriger, tu ne peux pas être un bon directeur si tu encore — parce que les LLM n'excellent certainement pas dans la compréhension, tu en restes uniquement en charge. Donc des outils à cet effet, je pense, sont incroyablement intéressants et excitants.
|
||||
|
||||
Je suis ravi de revenir ici dans quelques années pour voir si on a été entièrement automatisés hors de la boucle et qu'ils s'occupent aussi de la compréhension. Merci infiniment de t'être joint à nous, Andrej. On apprécie vraiment.
|
||||
Reference in New Issue
Block a user