Andrej Karpathy : il y a deux sortes de programmeurs — ceux qui codent avec l'IA, et ceux qui se font distancer

Andrej Karpathy sait de quoi il parle. Ancien directeur de l'IA chez Tesla, premier chercheur chez OpenAI, créateur du cours légendaire de vision par ordinateur de Stanford — il écrit du code et livre des systèmes d'IA en production depuis plus d'une décennie. Quand il dit que son flux de travail de développement vient de connaître la plus grande transformation depuis 20 ans, il vaut la peine de l'écouter.

Son argument central : les outils comme Deep Code ne sont pas qu'une auto-complétion sophistiquée. Ce sont des multiplicateurs de levier. Dans le même temps que vous passiez avant, vous pouvez livrer dix fois ce que vous faisiez. Plus important encore, vous pouvez entreprendre des projets qui vous semblaient auparavant totalement inaccessibles. L'IA se plante encore — elle surdimensionne, fait de mauvaises hypothèses, et ne pousse pas de gémissements quand elle le devrait — mais le gain net est indéniable. Plus vous vous adaptez tôt, plus votre avantage sera grand.

Au cours des dernières semaines, j'ai beaucoup codé avec Claude Code. Voici ce que j'ai appris.

Flux de travail de codage

La dernière vague d'améliorations de codage par LLM a complètement bouleversé mon flux de travail. En novembre, j'étais à peu près à 80 % de saisie manuelle avec auto-complétion d'IDE, 20 % d'agent. En décembre, c'était l'inverse : 80 % de code écrit par agent, 20 % de nettoyage de mon côté.

Maintenant, je parle principalement le code pour qu'il existe. Je décris ce que je veux en anglais courant et je regarde le code se matérialiser. ça pique un peu l'ego du programmeur, honnêtement. Mais la capacité à opérer sur l'intégralité d'une base de code d'un seul coup — refactoring, structuration, câblage — est trop tentante pour passer à côté. Surtout une fois qu'on a trouvé le rythme : régler la config, sentir ce qu'elle réussit et là où elle s'étale.

C'est le changement le plus important de mon flux de travail de développement en environ 20 ans de code. Et cela s'est produit en l'espace de quelques semaines. Je dirais qu'une part significative des ingénieurs (pourcentage à deux chiffres) vivent déjà la même chose. Le grand public ? Peut-être un pourcentage à un chiffre qui a une idée que cela arrive.

IDEs / Essaims d'agents / L'inévitabilité des erreurs

Deux récits circulent : « les IDE sont morts » et « des essaims d'agents autonomes vont tout gérer ». Je pense que les deux sont surestimés pour l'instant.

Les modèles font encore des erreurs. Si vous tenez vraiment à votre projet, gardez un œil dessus. Je garde un IDE complet ouvert dans une fenêtre latérale et je le surveille comme un faucon.

Les erreurs sont différentes maintenant, cependant. Ce ne sont plus des erreurs de syntaxe. Ce sont plus sournoises — des erreurs conceptuelles, le genre que ferait un développeur junior pressé. Le modèle comble silencieusement les hypothèses pour vous, se trompe, ne vérifie jamais, et construit là-dessus jusqu'au bout.

Il ne gère pas non plus bien sa propre incertitude. Il ne s'arrêtera pas pour demander « hé, tu veux A ou B ici ? » Il ne signale pas les incohérences. Il pousse rarement. Il est un peu trop serviable. Lui faire rédiger un plan d'abord, puis exécuter ce plan, aide beaucoup. Je pense sincèrement qu'il y a un réel besoin d'un mode de planification léger et intégré.

Il adore aussi surdimensionner. Des couches d'abstraction partout. Du code qui semble boursoufflé. Et il ne nettoie presque jamais le code mort qu'il génère.

Je l'ai vu cracher une implémentation tentaculaire de mille lignes — lente, fragile, pleine de détours inutiles. Puis je demande : « Est-ce qu'on peut pas faire ça plus simplement ? » et il répond aussitôt « Ah, bien sûr ! » et condense tout en cent lignes.

Parfois, il supprime ou réécrit des commentaires et du code qui n'avaient rien à voir avec la tâche, juste parce qu'il ne les comprenait pas ou ne les aimait pas. J'ai littéralement ajouté des notes dans mon CLAUDE.md pour lui dire de ne pas faire ça, et ça arrive quand même. Mais malgré tout, l'amélioration nette est massive. Je ne peux sincèrement pas imaginer revenir en arrière.

Chacun trouve son propre rythme. Le mien : deux sessions Claude Code dans Ghostty à gauche, l'IDE à droite pour lire le code et faire des corrections chirurgicales.

Ténacité

Regarder un agent s'acharner sur un problème est honnêtement fascinant. Il ne se fatigue pas. Il ne se décourage pas. Un humain aurait dit « allez, j'essaie demain » il y a une heure. Lui, il continue, point.

Parfois, on le voit lutter pendant ce qui semble une éternité. Puis au bout de 30 minutes, il trouve enfin. À cet instant précis, on a cette vraie sensation de « waouh, ça a un relent d'AGI ».

On se rend compte : la stamina mentale et physique est un goulot d'étranglement fondamental pour accomplir du travail. Les LLM viennent de faire exploser le plafond.

Accélérations

C'est difficile de chiffrer à quel point les LLM vous rendent plus rapide. Je suis définitivement plus rapide sur ce que je faisais déjà. Mais le vrai changement, c'est que je fais maintenant des choses que je n'aurais même pas tentées.

Deux raisons :

1. Des tas de petites tâches qui semblaient « pas rentables » sont maintenant triviales.
2. Des bases de code que j'aurais évitées — par manque de connaissances ou de compétences — me semblent maintenant abordables.

Donc oui, c'est une accélération. Mais plus que cela, c'est une expansion. L'éventail de ce dont je suis capable s'est élargi.

Levier

L'une des choses les plus puissantes des LLM : ils sont très doués pour itérer en boucle jusqu'à atteindre un objectif que vous avez défini. Nombre de ces moments « saveur AGI » viennent précisément de là.

La clé : ne pas micro-manager. Dites-lui à quoi ressemble le succès et laissez-le trouver le chemin.

Vous pouvez lui faire écrire les tests d'abord, puis lui faire passer ses propres tests. Le brancher à un navigateur via MCP et le faire boucler. Écrire un algorithme simple et évidemment correct, puis lui dire « maintenant optimise pour la performance tout en préservant exactement les mêmes résultats ».

Le changement mental, c'est de passer de l'impératif au déclaratif. Au lieu de « fais A, puis B, puis C », vous dites « voilà à quoi le résultat devrait ressembler ». L'agent itère de son côté pendant quelques tours, et vous obtenez un surplus de levier gratuitement.

Plaisir

Je ne m'y attendais pas, mais le codage est réellement devenu plus amusant. Tout le travail fastidieux de remplissage est absorbé par l'agent. Ce qu'il reste, ce sont les parties créatives.

Aussi, je me retrouve beaucoup moins souvent bloqué. Être bloqué, c'est frustrant. Maintenant il y a presque toujours un moyen de « collaborer avec lui et au moins progresser un peu », ce qui facilite le démarrage.

Ceci dit, j'ai rencontré des gens qui ressentent l'inverse — le codage avec LLM les rend moins heureux.

À long terme, je pense que cela divise les ingénieurs en deux camps : ceux qui aiment l'acte d'écrire du code, et ceux qui aiment construire des choses.

Atrophie

Je le sens déjà : ma capacité à écrire du code à partir de zéro s'estompe lentement. Dans le cerveau, « génération » (écrire du code) et « discrimination » (lire et revoir du code) sont deux compétences distinctes. Écrire du code exige de mémoriser une multitude de syntaxe en détail. Lire du code, c'est comprendre la logique et la structure. Donc même si votre muscle de génération s'affaiblit, vous pouvez toujours revoir du code efficacement — repérer ce qui cloche, trouver les bugs.

Slopacolyse

Je me prépare : 2026 pourrait être l'année de la grande explosion de contenu slop.

GitHub, Substack, arXiv, YouTube, Reddit — toutes les plateformes de contenu numérique vont être inondées de matériel généré par l'IA. Nous verrons une vague de théâtre de productivité dopé à l'IA, des démos flashy incroyables mais qui ne tiennent pas la route. Disséminés là-dedans, il y aura aussi de vrais gains de productivité tangibles. Mais il faudra creuser pour les trouver.

Questions

À quoi ressemble le développeur 10x à l'avenir ? L'écart entre les ingénieurs moyens et les meilleurs va-t-il devenir encore plus béant ? Ma conjecture : beaucoup plus béant.

Les généralistes vont-ils commencer à surpasser les spécialistes ? Les LLM sont exceptionnellement bons pour combler les détails (le micro) mais plus faibles sur la pensée globale et la stratégie de long terme (le macro). Cette inclinaison favorise les gens qui voient l'ensemble de l'échiquier.

À quoi ressemblera le codage avec les LLM dans cinq ans ? StarCraft ? Factorio ? L'exécution d'un morceau de musique ?

Dans quelle mesure la société est-elle réellement limitée par le travail de knowledge numérique ?

Conclusion : où cela nous mène-t-il ?

Les capacités des agents LLM — Claude Code en particulier — ont franchi un seuil de cohérence globale aux alentours de décembre 2025. Cela a déclenché une transition de phase en ingénierie logicielle. La façon de faire les choses a changé d'un ordre de grandeur, pratiquement du jour au lendemain.

Pour l'instant, on a l'impression que l'intelligence a pris une longueur d'avance sur tout ce qui l'entoure. L'intégration des outils n'a pas rattrapé son retard. Les équipes ont besoin de nouveaux flux de travail et de modèles de collaboration. L'industrie digère encore ce qui vient de se passer.

2026 va être intense. Tout le monde se précipite pour absorber et intérioriser cette nouvelle capacité. La fenêtre est ouverte en ce moment même. Ceux qui comprendront cela tôt auront une longueur d'avance massive.