Veuillez accueillir l'ancien directeur de l'IA chez Tesla, Andrej Karpathy.

Wow, il y a beaucoup de monde ici. Bonjour.

D'accord. Je suis ravi d'être ici aujourd'hui pour vous parler des logiciels à l'ère de l'IA.

On m'a dit que beaucoup d'entre vous sont des étudiants — licence, master, doctorat, etc. — et que vous êtes sur le point d'entrer dans le secteur. Je pense que c'est un moment extrêmement unique et très intéressant pour intégrer l'industrie en ce moment.

Je pense que fondamentalement, la raison en est que le logiciel est en train de changer à nouveau.

Je dis à nouveau parce que j'ai en fait déjà donné cette conférence. Mais le problème est que le logiciel continue de changer, j'ai donc en fait beaucoup de matière pour créer de nouvelles conférences. Je pense qu'il change de manière assez fondamentale. En gros, le logiciel n'a pas beaucoup changé à un niveau aussi fondamental pendant 70 ans, puis il a changé environ deux fois assez rapidement au cours des dernières années. Il y a tout simplement une quantité énorme de travail à faire, une quantité énorme de logiciels à écrire et à réécrire.

Jetons un coup d'œil au domaine du logiciel. Si nous considérons cela comme la carte du logiciel, c'est un outil vraiment cool appelé Map of GitHub. C'est tout le logiciel qui est écrit : des instructions à l'ordinateur pour effectuer des tâches dans l'espace numérique. Si vous zoomez ici, ce sont tous des types de dépôts différents, et c'est tout le code qui a été écrit.

Il y a quelques années, j'ai observé que le logiciel changeait et qu'il y avait un nouveau type de logiciel, que j'ai appelé Software 2.0 à l'époque. L'idée ici était que le Software 1.0 est le code que vous écrivez pour l'ordinateur. Le Software 2.0, ce sont essentiellement des réseaux de neurones, et en particulier, les poids d'un réseau de neurones. Vous n'écrivez pas ce code directement ; vous ajustez plutôt les ensembles de données, puis vous lancez un optimiseur pour créer les paramètres de ce réseau de neurones.

À l'époque, les réseaux de neurones étaient un peu perçus comme un simple type de classificateur différent, comme un arbre de décision ou quelque chose du genre. Je pense que ce cadre était beaucoup plus approprié.

Maintenant, nous avons en fait un équivalent de GitHub dans le domaine du Software 2.0. Hugging Face est essentiellement l'équivalent de GitHub pour le Software 2.0. Il y a aussi Model Atlas où vous pouvez visualiser tout le code qui y est écrit. Au cas où vous seriez curieux, le cercle géant au milieu représente les paramètres de Flux, le générateur d'images. Chaque fois que quelqu'un ajuste un LoRA par-dessus un modèle Flux, vous créez essentiellement un commit Git dans cet espace et créez un type différent de générateur d'images.

En gros, nous avons le Software 1.0, le code informatique qui programme un ordinateur, et le Software 2.0, les poids qui programment les réseaux de neurones. Voici un exemple du réseau de neurones de reconnaissance d'images AlexNet.

Jusqu'à présent, tous les réseaux de neurones que nous connaissions jusqu'à récemment étaient des ordinateurs à fonction fixe, comme le passage d'une image à des catégories. Ce qui a changé, et je pense que c'est un changement assez fondamental, c'est que les réseaux de neurones sont devenus programmables grâce aux grands modèles de langage (LLM).

Je vois cela comme quelque chose d'assez nouveau et unique ; c'est un nouveau type d'ordinateur. Dans mon esprit, cela vaut la peine de lui donner une nouvelle désignation : Software 3.0. Fondamentalement, vos prompts sont maintenant des programmes qui programment le LLM. Remarquablement, ces prompts sont écrits en anglais, c'est donc un langage de programmation très intéressant.

Pour résumer la différence, si vous faites de la classification de sentiments, par exemple, vous pouvez imaginer écrire une certaine quantité de Python pour faire de la classification de sentiments, ou vous pouvez entraîner un réseau de neurones, ou vous pouvez prompter un grand modèle de langage. Voici un prompt à quelques exemples (few-shot), et vous pouvez imaginer le modifier et programmer l'ordinateur d'une manière légèrement différente.

Fondamentalement, nous avons le Software 1.0 et le Software 2.0, et je pense que nous voyons une catégorie croissante d'un nouveau type de code. Vous avez peut-être remarqué que beaucoup de code sur GitHub n'est plus seulement du code ; il y a un tas d'anglais intercalé avec le code.

Non seulement c'est un nouveau paradigme de programmation, mais il est aussi remarquable pour moi que ce soit dans notre langue maternelle, l'anglais. Quand cela m'a époustouflé il y a quelques années, j'ai tweeté ceci et cela a capté l'attention de beaucoup de gens. C'est mon tweet actuellement épinglé : remarquablement, nous programmons maintenant les ordinateurs en anglais.

Quand j'étais chez Tesla, nous travaillions sur l'Autopilot et essayions de faire conduire la voiture. J'ai montré cette diapositive à l'époque où vous pouvez imaginer que les entrées de la voiture sont en bas et qu'elles passent par une pile logicielle pour produire la direction et l'accélération.

J'ai fait l'observation à l'époque qu'il y avait une tonne de code C++ dans l'Autopilot, qui était le code Software 1.0, et puis il y avait quelques réseaux de neurones à l'intérieur qui faisaient de la reconnaissance d'images.

J'ai observé qu'au fil du temps, à mesure que nous améliorions l'Autopilot, le réseau de neurones gagnait en capacité et en taille. De plus, tout le code C++ était en train d'être supprimé, et une grande partie de la fonctionnalité qui était initialement écrite en 1.0 a été migrée vers le 2.0.

Par exemple, une grande partie de l'assemblage des informations provenant des images des différentes caméras et au fil du temps était effectuée par un réseau de neurones, et nous avons pu supprimer beaucoup de code. La pile Software 2.0 a littéralement dévoré la pile logicielle de l'Autopilot. Je pensais que c'était vraiment remarquable à l'époque.

Je pense que nous voyons la même chose se reproduire, où un nouveau type de logiciel dévore la pile. Nous avons trois paradigmes de programmation complètement différents. Si vous entrez dans l'industrie, c'est une très bonne idée de les maîtriser tous car ils ont tous de légers avantages et inconvénients. Vous voudrez peut-être programmer certaines fonctionnalités en 1.0, 2.0 ou 3.0. Allez-vous entraîner un réseau de neurones ? Allez-vous simplement prompter un LLM ? Cela devrait-il être un morceau de code explicite ? Nous devons prendre ces décisions et potentiellement passer de manière fluide entre ces paradigmes.

Ce que je voulais aborder en premier, c'est de parler des LLM et de la façon de penser à ce nouveau paradigme et à son écosystème. Qu'est-ce que ce nouvel ordinateur ? À quoi ressemble-t-il, et à quoi ressemble l'écosystème ?

J'ai été frappé par cette citation d'Andrew Ng il y a plusieurs années. Je pense qu'Andrew va prendre la parole juste après moi. Il a dit à l'époque : « L'IA est la nouvelle électricité. » Je pense que cela a capturé quelque chose de très intéressant dans le fait que les LLM ont certainement les propriétés de services publics en ce moment.

Les laboratoires de LLM comme OpenAI, Gemini, Anthropic, etc., dépensent du CAPEX pour entraîner les LLM, ce qui équivaut à construire un réseau électrique. Ensuite, il y a de l'OPEX pour servir cette intelligence via des API à nous tous. Cela se fait via un accès mesuré où nous payons par million de tokens. Nous avons des exigences de type service public pour cette API : faible latence, haute disponibilité, qualité constante, etc.

Pour l'électricité, vous auriez un commutateur de transfert pour transférer votre source d'électricité du réseau vers le solaire, une batterie ou un générateur. Pour les LLM, nous avons OpenRouter pour passer facilement entre les différents types de LLM qui existent.

Parce que les LLM sont des logiciels, ils ne se font pas concurrence pour l'espace physique. Il est donc normal d'avoir six fournisseurs d'électricité et de passer de l'un à l'autre parce qu'ils ne se font pas concurrence de manière aussi directe.

Ce qui est aussi vraiment fascinant — et nous l'avons vu ces derniers jours — c'est que lorsque les LLM sont tombés en panne, les gens étaient bloqués et incapables de travailler. Il est fascinant pour moi que lorsque les LLM de pointe tombent en panne, c'est comme une baisse de tension de l'intelligence dans le monde, similaire au moment où la tension est instable dans le réseau. La planète devient plus bête à mesure que nous dépendons de ces modèles, ce qui est déjà spectaculaire et continuera de croître.

Mais les LLM n'ont pas seulement des propriétés de services publics ; ils ont aussi certaines propriétés de fonderies (fabs). La raison en est que le CAPEX requis pour construire des LLM est assez important. Vous investissez une quantité énorme d'argent, et l'arbre technologique croît assez rapidement.

Nous sommes dans un monde où nous avons des arbres technologiques profonds, de la recherche et développement, et des secrets qui se centralisent à l'intérieur des laboratoires de LLM. Mais je pense que l'analogie se brouille parce qu'il s'agit de logiciel. Le logiciel est moins défendable parce qu'il est très malléable. C'est juste une chose intéressante à laquelle réfléchir.

Il y a de nombreuses analogies que vous pouvez faire. Un nœud de processus de 4 nanomètres pourrait être comme un cluster avec certains FLOPS max. Lorsque vous utilisez des GPU NVIDIA et que vous ne faites que le logiciel, c'est comme le modèle sans usine (fabless). Mais si vous construisez votre propre matériel et que vous vous entraînez sur des TPU, comme Google, c'est comme le modèle Intel où vous possédez votre fonderie.

En fait, l'analogie qui a le plus de sens est que les LLM ont des analogies très fortes avec les systèmes d'exploitation. Il ne s'agit pas seulement d'électricité ou d'eau sortant d'un robinet comme une commodité ; ce sont des écosystèmes logiciels de plus en plus complexes.

Il est intéressant pour moi que l'écosystème se façonne d'une manière très similaire où vous avez quelques fournisseurs de sources fermées comme Windows ou macOS, et ensuite vous avez une alternative open-source comme Linux. Pour les LLM également, nous avons quelques fournisseurs de sources fermées concurrents, et l'écosystème Llama est actuellement une approximation proche de quelque chose qui pourrait devenir comme Linux.

C'est encore très tôt car ce ne sont que des LLM simples, mais nous commençons à voir que cela va devenir beaucoup plus compliqué. Il ne s'agit pas seulement du LLM lui-même ; il s'agit de toute l'utilisation d'outils et de la multimodalité et de la façon dont tout cela fonctionne.

Quand j'ai eu cette prise de conscience il y a quelque temps, j'ai essayé de l'esquisser. Il m'a semblé que les LLM sont un nouveau système d'exploitation. Le LLM est un nouveau genre d'ordinateur agissant comme l'équivalent du CPU. Les fenêtres de contexte sont comme la mémoire. Le LLM orchestre la mémoire et le calcul pour la résolution de problèmes. Cela ressemble beaucoup à un système d'exploitation de ce point de vue.

Pour ajouter quelques analogies supplémentaires, si vous allez télécharger VS Code, vous pouvez l'exécuter sur Windows, Linux ou Mac. De la même manière, vous pouvez prendre une application LLM comme Cursor et l'exécuter sur les séries GPT, Claude ou Gemini via un menu déroulant.

D'autres analogies qui me frappent sont que nous sommes dans cette ère des années 1960 où le calcul des LLM est encore très coûteux pour ce nouveau type d'ordinateur. Cela oblige les LLM à être centralisés dans le cloud alors que nous ne sommes que des clients légers interagissant via le réseau. Aucun d'entre nous n'a l'utilisation complète de ces ordinateurs, il est donc logique d'utiliser le partage de temps dans le cloud.

C'est tout à fait ce à quoi ressemblaient les ordinateurs autrefois. Les systèmes d'exploitation étaient dans le cloud, tout circulait en streaming, et il y avait du traitement par lots. La révolution de l'informatique personnelle n'a pas encore eu lieu parce que cela n'a pas de sens économique, mais certaines personnes essaient. Il s'avère que les Mac Mini conviennent très bien à certains LLM parce que l'inférence par lots de un est extrêmement limitée par la mémoire.

Ce sont quelques premières indications de l'informatique personnelle, mais cela n'a pas encore vraiment eu lieu. On ne sait pas à quoi cela ressemble ; peut-être que certains d'entre vous pourront inventer ce que c'est ou comment cela fonctionne.

Chaque fois que je parle à ChatGPT ou à un LLM directement par texte, j'ai l'impression de parler à un système d'exploitation via le terminal. C'est juste du texte, un accès direct au système d'exploitation. Une interface graphique n'a pas encore vraiment été inventée de manière générale. ChatGPT devrait-il avoir une interface graphique différente de simples bulles de texte ? Certes, certaines des applications dont nous discuterons ont des interfaces graphiques, mais il n'y a pas d'interface graphique universelle pour toutes les tâches.

Il y a certaines façons dont les LLM sont différents des systèmes d'exploitation et de l'informatique ancienne. J'ai écrit sur une propriété particulière qui me semble très différente : les LLM inversent la direction de la diffusion technologique qui est habituellement présente.

Par exemple, avec l'électricité, la cryptographie, l'informatique, le vol, l'internet et le GPS — des technologies transformatrices — généralement le gouvernement et les entreprises sont les premiers utilisateurs parce que c'est nouveau et coûteux, et ce n'est que plus tard que cela se diffuse aux consommateurs. Mais j'ai l'impression que c'est l'inverse pour les LLM. Avec les premiers ordinateurs, tout tournait autour de la balistique et de l'usage militaire, mais avec les LLM, il s'agit de savoir comment faire cuire un œuf à la coque. C'est certainement une grande partie de mon utilisation.

Il est fascinant de voir qu'un nouvel ordinateur magique m'aide à faire bouillir un œuf plutôt que d'aider le gouvernement à faire quelque chose comme de la balistique militaire. En effet, les entreprises ou les gouvernements sont en retard sur notre adoption de ces technologies. C'est à l'envers, et je pense que cela informe certaines des premières applications et la façon dont nous voulons utiliser cette technologie.

En résumé, les laboratoires de LLM « fabriquent » des LLM, mais les LLM sont des systèmes d'exploitation compliqués. Ils en sont aux années 1960 de l'informatique et nous refaisons l'informatique à nouveau, actuellement disponible via le partage de temps et distribué comme un service public.

Ce qui est nouveau et sans précédent, c'est qu'ils sont entre les mains de nous tous parce que nous avons tous un ordinateur et que tout n'est que logiciel. ChatGPT a été diffusé instantanément et du jour au lendemain à des milliards de personnes. C'est insensé, et c'est maintenant à notre tour d'entrer dans l'industrie et de programmer ces ordinateurs. C'est tout à fait remarquable.

Avant de programmer les LLM, nous devons passer un peu de temps à réfléchir à ce que sont ces choses, en particulier leur psychologie. J'aime penser aux LLM comme à des « esprits de personnes ». Ce sont des simulations stochastiques de personnes, et le simulateur dans ce cas est un Transformer autorégressif.

Un Transformer est un réseau de neurones qui travaille sur des tokens. Il y a une quantité presque égale de calcul pour chaque morceau. Ce simulateur implique des poids, ajustés à tout le texte que nous avons sur Internet. Vous vous retrouvez avec ce genre de simulateur, et parce qu'il est entraîné sur des humains, il possède une psychologie émergente qui ressemble à celle des humains.

La première chose que vous remarquerez est que les LLM ont des connaissances et une mémoire encyclopédiques. Ils peuvent se souvenir de bien plus que n'importe quel être humain individuel parce qu'ils ont lu tellement de choses. Cela me rappelle le film Rain Man ; Dustin Hoffman joue un savant autiste qui a une mémoire presque parfaite et peut lire un annuaire téléphonique et se souvenir de tous les noms et numéros. Les LLM sont très similaires ; ils peuvent se souvenir des hachages SHA et de tas de types de choses différentes très facilement.

Ils ont certainement des superpouvoirs à certains égards, mais ils ont aussi des déficits cognitifs. Ils hallucinent pas mal, inventant des choses et manquant d'un modèle interne suffisant de connaissance de soi. Cela s'est amélioré mais n'est pas parfait.

Ils font preuve d'une intelligence irrégulière. Ils sont surhumains dans certains domaines de résolution de problèmes, puis commettent des erreurs qu'aucun humain ne ferait — comme insister sur le fait que 9.11 est plus grand que 9.9 ou qu'il y a deux « r » dans « strawberry ». Il y a des aspérités sur lesquelles on peut trébucher.

Ils souffrent également d'amnésie antérograde. Si un collègue rejoint votre organisation, il apprendra et gagnera une énorme quantité de contexte au fil du temps, puis rentrera chez lui et dormira pour consolider ces connaissances. Les LLM ne font pas cela nativement, et cela n'a pas encore été résolu par la recherche.

Les fenêtres de contexte sont comme la mémoire de travail, et vous devez programmer la mémoire de travail de manière assez directe car ils ne deviennent pas plus intelligents par défaut. Beaucoup de gens se laissent piéger par les analogies de cette façon.

Dans la culture populaire, je recommande de regarder Memento et Amour et Amnésie (50 First Dates). Dans les deux films, les poids des protagonistes sont fixes et leurs fenêtres de contexte sont effacées chaque matin. C'est problématique pour le travail ou les relations, et cela arrive tout le temps aux LLM.

Une chose de plus que je voudrais souligner est les limites de sécurité. Les LLM sont assez crédules et sensibles aux risques d'injection de prompts, et ils pourraient divulguer vos données. Il existe de nombreuses autres considérations liées à la sécurité.

Pour faire court, vous devez simultanément penser à travers cette chose surhumaine qui a des déficits cognitifs. Comment les programmons-nous pour contourner leurs déficits et profiter de leurs pouvoirs surhumains ?

Je veux passer aux opportunités de la façon dont nous utilisons ces modèles. Ce n'est pas une liste exhaustive, juste quelques choses que j'ai trouvées intéressantes pour cette conférence.

La première chose qui m'enthousiasme, ce sont les applications à autonomie partielle. Prenons le codage comme exemple. Vous pouvez aller directement sur ChatGPT et copier-coller du code et des rapports de bugs, mais pourquoi iriez-vous directement au système d'exploitation ?

Il est beaucoup plus logique d'avoir une application dédiée à cela. Beaucoup d'entre vous utilisent Cursor, tout comme moi. Cursor est ce que vous voulez au lieu d'aller directement sur ChatGPT.

Cursor est un très bon exemple d'une application LLM précoce avec des propriétés utiles dans toutes les applications LLM. Elle dispose d'une interface traditionnelle pour le travail manuel, mais aussi d'une intégration LLM qui nous permet de travailler par morceaux plus importants.

Certaines propriétés partagées des applications LLM sont : premièrement, les LLM gèrent la gestion du contexte. Deuxièmement, ils orchestrent plusieurs appels aux LLM. Dans le cas de Cursor, il y a sous le capot des modèles d'intégration (embeddings) pour vos fichiers, des modèles de chat et des modèles qui appliquent des différences (diffs) au code.

Une chose très importante qui n'est pas toujours pleinement appréciée est l'interface graphique spécifique à l'application. Vous ne voulez pas parler directement au système d'exploitation en texte. Le texte est difficile à lire et à comprendre, et vous ne voulez pas effectuer certaines actions nativement en texte.

Il est bien préférable de voir un diff sous forme de changements rouges et verts où vous pouvez voir ce qui est ajouté ou soustrait. Il est beaucoup plus facile d'utiliser commande-Y pour accepter ou commande-N pour rejeter plutôt que de le taper en texte. Une interface graphique permet à un humain d'auditer le travail de ces systèmes faillibles et d'aller plus vite.

La dernière fonctionnalité que je veux souligner est le curseur d'autonomie. Dans Cursor, vous pouvez utiliser la complétion par tabulation, sélectionner du code et faire commande-K pour modifier un bloc, commande-L pour modifier un fichier, ou commande-I pour une autonomie agentique complète sur l'ensemble du dépôt.

Vous êtes responsable du curseur d'autonomie et pouvez ajuster le degré d'autonomie que vous êtes prêt à accorder en fonction de la complexité de la tâche.

Une autre application LLM réussie, Perplexity, présente des fonctionnalités très similaires. Elle regroupe les informations, orchestre plusieurs LLM, dispose d'une interface graphique pour auditer le travail — comme citer les sources — et d'un curseur d'autonomie. Vous pouvez faire une recherche rapide ou une recherche approfondie, en faisant varier l'autonomie que vous donnez à l'outil.

J'ai l'impression que beaucoup de logiciels vont devenir partiellement autonomes. Comment allez-vous rendre vos produits et services partiellement autonomes ? Un LLM peut-il voir et agir de toutes les manières possibles pour un humain ? Les humains peuvent-ils superviser et rester dans la boucle ? À quoi ressemble un diff dans Photoshop ?

Les logiciels traditionnels ont des commutateurs et des interfaces conçus pour les humains. Tout cela doit changer pour devenir accessible aux LLM.

Une chose sur laquelle je veux insister est que nous coopérons maintenant avec des IA ; elles s'occupent de la génération et nous nous occupons de la vérification. Il est dans notre intérêt de rendre cette boucle aussi rapide que possible.

Il y a deux façons majeures de le faire. Premièrement, accélérer la vérification. Les interfaces graphiques sont extrêmement importantes pour cela car elles utilisent notre « GPU de vision par ordinateur » interne. Lire du texte est laborieux, mais regarder des représentations visuelles est une autoroute rapide vers votre cerveau.

Deuxièmement, nous devons garder l'IA en laisse. Les gens s'excitent trop avec les agents d'IA, mais il n'est pas utile d'obtenir un diff de 1 000 lignes instantanément si je suis toujours le goulot d'étranglement pour m'assurer qu'il n'introduit pas de bugs ou de problèmes de sécurité.

Nous devons rendre le flux rapide tout en gardant l'IA en laisse car elle peut être trop réactive. C'est ce que je ressens en faisant du codage assisté par IA ; le « vibe coding » c'est génial, mais accomplir un travail sérieux avec un agent trop réactif est difficile.

J'essaie de développer des façons d'utiliser ces agents dans mon flux de travail de codage. J'ai peur de recevoir des diffs trop volumineux, donc je travaille par petits morceaux incrémentiels. Je veux faire tourner la boucle très rapidement sur des choses concrètes et uniques. Beaucoup d'entre vous développent probablement des façons similaires de travailler avec les LLM.

J'ai récemment lu un article de blog discutant des meilleures pratiques, notamment celle de garder l'IA en laisse. Si votre prompt est vague, l'IA pourrait ne pas faire exactement ce que vous voulez, la vérification échouera et vous perdrez du temps. Il est plus logique de passer du temps à être concret dans vos prompts pour augmenter la probabilité d'une vérification réussie.

Dans mon propre travail, je m'intéresse à ce à quoi ressemble l'éducation avec l'IA. Je réfléchis beaucoup à la façon de garder l'IA en laisse. Cela ne fonctionne pas de simplement demander à ChatGPT de « m'enseigner la physique » car l'IA se perd en chemin.

Je vois cela comme deux applications distinctes : une pour qu'un enseignant crée des cours et une pour les servir aux étudiants. Cela crée un artefact intermédiaire auditable d'un cours qui est cohérent, gardant l'IA en laisse par rapport à un programme et une progression spécifiques. Cela a une probabilité de réussite beaucoup plus élevée.

Je ne suis pas étranger à l'autonomie partielle, ayant travaillé sur l'Autopilot chez Tesla pendant cinq ans. L'Autopilot est un produit à autonomie partielle avec une interface graphique montrant ce que le réseau de neurones voit et un curseur d'autonomie qui a ajouté des tâches plus autonomes au cours de mon mandat.

La première fois que j'ai conduit un véhicule autonome, c'était en 2013. Un ami de Waymo m'a proposé un tour dans Palo Alto. J'ai pris une photo avec des Google Glass, qui étaient très à la mode à l'époque.

Nous avons fait un tour de 30 minutes sur les autoroutes et les rues. La conduite était parfaite, avec zéro intervention. C'était il y a 12 ans.

À l'époque, je pensais que la conduite autonome était imminente parce que cela fonctionnait si bien. Mais 12 ans plus tard, nous travaillons toujours sur l'autonomie et les agents de conduite. Nous n'avons pas encore totalement résolu le problème ; même les Waymo sans conducteur impliquent toujours de la téléopération et des humains dans la boucle. Cela finira par réussir, mais cela a pris beaucoup de temps.

Ce logiciel est délicat de la même manière que la conduite est délicate. Quand je vois des gens dire que 2025 est « l'année des agents », je pense qu'il s'agira en fait de la « décennie des agents ». Nous avons besoin d'humains dans la boucle et devons procéder avec prudence ; il s'agit de logiciel.

Une autre analogie à laquelle je réfléchis est l'armure d'Iron Man. J'adore l'armure d'Iron Man parce qu'elle est à la fois une augmentation que Tony Stark pilote et un agent autonome qui peut voler partout et le retrouver.

Avec un curseur d'autonomie, nous pouvons construire des augmentations ou des agents. À ce stade, en travaillant avec des LLM faillibles, nous devrions construire des armures d'Iron Man plutôt que des robots Iron Man. Nous devrions nous concentrer sur la construction de produits à autonomie partielle avec des interfaces graphiques personnalisées afin que la boucle génération-vérification soit rapide.

Il est en principe possible d'automatiser ce travail. Votre produit devrait avoir un curseur d'autonomie que le rend plus autonome au fil du temps. Je pense qu'il y a de nombreuses opportunités dans ce type de produits.

Il y a une autre dimension unique : ce nouveau langage de programmation utilise l'anglais. Soudain, tout le monde est programmeur parce que tout le monde parle anglais. C'est extrêmement encourageant et sans précédent ; vous n'avez plus besoin d'années d'études pour travailler dans le logiciel.

Vous avez peut-être entendu parler du « vibe coding ». J'ai tweeté à ce sujet et c'est devenu un mème majeur. Après 15 ans sur Twitter, je ne peux toujours pas prédire ce qui deviendra viral. Je pensais que ce tweet tomberait à plat, mais il a touché une corde sensible et a nommé un sentiment que tout le monde partageait.

Maintenant, il y a une page Wikipédia pour cela. C'est considéré comme une contribution majeure maintenant.

Thomas Wolf de Hugging Face a partagé une magnifique vidéo d'enfants faisant du « vibe coding ». C'est une vidéo réconfortante ; l'avenir est génial. Je pense que ce sera une drogue d'initiation au développement de logiciels. Je ne suis pas pessimiste concernant cette génération.

J'ai essayé le « vibe coding » moi-même parce que c'est tellement amusant de construire quelque chose de personnalisé et d'improviser un samedi. J'ai construit une application iOS sans savoir programmer en Swift. J'ai été choqué de pouvoir construire une application de base en une journée et de la faire fonctionner sur mon téléphone sans avoir étudié le Swift pendant des jours.

J'ai aussi « vibe codé » une application appelée MenuGen, qui est en ligne sur menugen.app. J'ai un problème : je lis les menus de restaurants et je ne sais pas ce que sont les plats, j'ai donc besoin de photos. Vous prenez une photo d'un menu, et MenuGen génère les images. Tout le monde reçoit 5 $ de crédits, ce qui en fait une application à revenus négatifs pour moi en ce moment.

Ce qui était fascinant avec MenuGen, c'était que la partie « vibe coding » était la partie facile. La rendre « réelle » avec l'authentification, les paiements et le déploiement a été la partie difficile. Ce calvaire DevOps consistant à cliquer dans des navigateurs a pris une semaine. La démo fonctionnait en quelques heures, mais le lancement a pris une semaine.

C'était ennuyeux. Ajouter la connexion Google impliquait des instructions me disant exactement où cliquer. Pourquoi est-ce que je fais ça ? L'ordinateur devrait le faire pour moi. J'ai dû suivre toutes ces instructions moi-même.

La dernière partie de ma conférence porte sur la construction pour les agents. Je ne veux pas faire ce travail ; les agents devraient le faire.

Il existe une nouvelle catégorie de consommateurs et de manipulateurs d'informations numériques. Au-delà des humains et des API, nous avons maintenant des agents — des « esprits de personnes » de type humain sur Internet — qui doivent interagir avec notre infrastructure logicielle. Nous devrions construire pour eux.

Par exemple, tout comme robots.txt conseille les robots d'indexation du web, un fichier llms.txt en markdown peut indiquer aux LLM de quoi parle un domaine. C'est très lisible pour un LLM par rapport à l'analyse d'un code HTML sujet aux erreurs. Cela vaut la peine de leur parler directement.

La documentation est actuellement écrite pour les gens avec des listes et des images, ce qui n'est pas directement accessible par un LLM. Des services comme Vercel et Stripe sont des pionniers en proposant une documentation spécifiquement en markdown pour les LLM. C'est génial.

Grant Sanderson de 3Blue1Brown réalise de magnifiques vidéos d'animation à l'aide de sa bibliothèque Manim. Je voulais l'utiliser mais je ne voulais pas lire la vaste documentation. Je l'ai copiée-collée dans un LLM et j'ai décrit ce que je voulais, et le LLM a « vibe codé » l'animation parfaitement. Rendre les documents lisibles par les LLM débloquera une quantité énorme d'utilisations.

Nous devons également modifier les documents car chaque fois qu'ils disent « cliquez », un LLM ne peut pas le suivre nativement. Vercel remplace « cliquez » par des commandes curl pour les agents. Le Model Context Protocol d'Anthropic est un autre moyen de s'adresser directement aux agents en tant que nouveaux consommateurs d'informations numériques. Je suis très convaincu par ces idées.

J'aime aussi les outils qui aident à ingérer des données dans des formats adaptés aux LLM. Pour un dépôt GitHub comme nanoGPT, vous ne pouvez pas fournir l'interface humaine à un LLM. En changeant l'URL par GitIngest, les fichiers sont concaténés en un seul texte avec une structure de répertoires, prêt pour un LLM.

Un exemple plus frappant est DeepWiki by Devin, qui analyse un dépôt GitHub et construit une page de documentation complète pour celui-ci. C'est très utile à copier-coller dans un LLM. J'adore les outils où il suffit de changer l'URL pour rendre quelque chose accessible à un LLM.

Les LLM peuvent déjà cliquer sur les choses, mais cela vaut la peine de faire un pas vers eux pour rendre l'accès à l'information plus facile et moins coûteux. Beaucoup de logiciels ne s'adapteront pas, nous aurons donc besoin de ces outils, mais pour l'infrastructure active, faire un compromis en vaut la peine.

En résumé, c'est un moment extraordinaire pour entrer dans l'industrie. Nous devons réécrire une tonne de code en utilisant à la fois des professionnels et des « vibe coders ». Les LLM sont comme des services publics, des fonderies, et surtout des systèmes d'exploitation, mais nous en sommes encore à l'ère des années 1960. Nous devons adapter notre infrastructure pour travailler avec ces « esprits de personnes » faillibles. Lors de la création d'applications LLM, concentrez-vous sur des produits à autonomie partielle qui permettent une vérification humaine rapide. Nous devrions également écrire du code directement pour les agents. Au cours de la prochaine décennie, nous ferons glisser le curseur d'autonomie de gauche à droite, et j'ai hâte de le construire avec vous. Merci.