Réflexions sur l’expérience de codage avec Claude ces dernières semaines par Andrej Karpathy
(x.com/karpathy)Changement de workflow de codage
- En novembre 2024, c’était 80 % manuel + autocomplétion et 20 % de codage par agent, mais en décembre, le ratio s’est inversé : 80 % de codage par agent et 20 % de corrections/retouches
- En pratique, on en est arrivé à programmer en anglais, sous la forme d’instructions verbales données au LLM sur le code à écrire
- C’est un peu vexant pour l’ego, mais la capacité à manipuler le logiciel par grandes unités de « code action » est incroyablement utile
- Plus on s’y adapte, qu’on le configure, qu’on apprend à l’utiliser et qu’on comprend ce qui est possible ou non, plus c’est efficace
- C’est le plus grand changement fondamental de workflow de codage en environ 20 ans de carrière de programmation, et cela s’est produit en seulement quelques semaines
- Il s’attend à ce qu’une part importante des ingénieurs (un pourcentage à deux chiffres) vive quelque chose de similaire, alors que la perception du grand public serait encore plutôt dans les premiers pourcents à un chiffre
IDE / essaims d’agents / risque d’erreur
- Il estime que le battage autour de « plus besoin d’IDE » ou des « essaims d’agents » est, pour l’instant, exagéré
- Les modèles continuent de se tromper et, dès qu’il s’agit de code réellement important, il faut les surveiller avec des yeux de faucon et garder un gros IDE ouvert à côté
- La nature des erreurs change : ce ne sont plus de simples erreurs de syntaxe, mais des erreurs conceptuelles subtiles du type de celles qu’un développeur junior un peu négligent et pressé pourrait commettre
- Le type d’erreur le plus fréquent : formuler de mauvaises hypothèses à la place de l’utilisateur et avancer sans les vérifier
- Autres problèmes supplémentaires :
- incapable de gérer la confusion
- ne demande pas de clarifications
- ne met pas en évidence les incohérences
- ne présente pas les compromis
- ne contredit pas quand il le faudrait
- conserve encore une certaine tendance sycophantique
- Cela s’améliore en mode plan, mais il faudrait un mode plan léger et inline
- Il y a aussi une tendance à surcomplexifier le code et les API, à gonfler les abstractions, et à ne pas nettoyer le code mort après coup
- Il arrive d’implémenter sur 1 000 lignes une structure inefficace, lourde et fragile, puis, si on demande « on ne pourrait pas faire autrement ? », de répondre « bien sûr ! » et de la ramener aussitôt à 100 lignes
- Il arrive encore de modifier/supprimer des commentaires et du code qu’il n’aime pas ou ne comprend pas assez bien, même si cela n’a rien à voir avec la tâche
- Ces problèmes surviennent même après avoir tenté de corriger simplement le tir en mettant des consignes dans CLAUDE.md
- Malgré tout cela, c’est toujours une amélioration purement gigantesque, et revenir au codage manuel est très difficile
- Workflow actuel : à gauche, quelques sessions Claude Code dans une fenêtre / des onglets ghostty ; à droite, l’IDE pour vérifier le code et faire les éditions manuelles
Ténacité
- Il trouve très intéressant de voir un agent s’acharner sans relâche sur quelque chose
- Il ne se fatigue pas, ne se décourage pas, et continue d’essayer là où un humain aurait abandonné depuis longtemps en remettant ça à plus tard
- Le voir lutter longtemps avec un problème puis réussir au bout de 30 minutes donne une impression de « moment AGI »
- Cela fait réaliser que l’endurance est un goulot d’étranglement central du travail, et qu’avoir un LLM sous la main l’augmente de façon spectaculaire
Gain de vitesse
- Il n’est pas clair comment mesurer le « gain de vitesse » de l’assistance par LLM
- Ce qu’il comptait faire lui semble clairement aller beaucoup plus vite, mais l’effet principal est surtout de faire bien plus que ce qu’il avait prévu :
- on peut coder toutes sortes de choses qui, auparavant, ne valaient pas la peine d’être codées
- on peut accéder à du code sur lequel on ne pouvait pas travailler auparavant, faute de connaissances ou de compétences
- Il y a bien un gain de vitesse, mais la plus grande partie est peut-être une expansion
Levier
- Les LLM excellent à boucler jusqu’à satisfaire un objectif donné, et c’est l’essentiel de cette magie qui donne une impression d’« AGI »
- Ne pas leur dire quoi faire précisément ; leur donner des critères de réussite et les regarder faire
- Leur faire écrire les tests d’abord, puis leur faire les passer
- Les mettre dans la boucle avec le MCP navigateur
- Leur faire d’abord écrire un algorithme naïf qui a de fortes chances d’être très exact, puis demander une optimisation sans perdre en exactitude
- En passant d’une approche impérative à déclarative, l’agent boucle plus longtemps et offre davantage de levier
Plaisir
- L’aspect inattendu, c’est que programmer avec un agent devient plus amusant
- Les tâches ennuyeuses de remplissage des blancs disparaissent, et il ne reste que les parties créatives
- Il y a moins de blocages / stagnation (l’état non amusant) et on ressent davantage d’audace — parce qu’il y a toujours un moyen d’avancer positivement ensemble
- D’autres ressentent l’inverse : le codage avec LLM va séparer les ingénieurs qui aiment coder en soi et les ingénieurs qui aiment construire des choses
Atrophie
- Il se rend compte que sa capacité à écrire du code manuellement commence peu à peu à s’atrophier
- Génération (écriture de code) et discrimination (lecture de code) sont deux capacités différentes dans le cerveau
- À cause de petits détails syntaxiques liés à la programmation, on peut avoir du mal à écrire tout en restant parfaitement capable de faire de la revue de code
Slopacolypse
- Il s’attend à ce que 2026 soit l’année de la slopacolypse (déferlement de contenus IA de mauvaise qualité) sur GitHub, Substack, arXiv, X/Instagram et, plus généralement, dans tous les médias numériques
- Au-delà des véritables améliorations, on verra apparaître encore plus de théâtre de productivité IA survendu (si c’est encore possible)
Questions
- Que se passe-t-il pour les « ingénieurs 10x » ? — Qu’advient-il du ratio de productivité entre ingénieurs moyens et meilleurs ingénieurs ? Il est possible que ce ratio augmente fortement
- Armés de LLM, les généralistes vont-ils surpasser de plus en plus les spécialistes ? Les LLM sont bien meilleurs pour remplir les blancs (micro) que pour la grande stratégie (macro)
- À quoi ressemblera le codage avec LLM dans le futur ? Est-ce que cela donnera l’impression de jouer à StarCraft ? Ou à Factorio ? Ou de jouer de la musique ?
- Quelle part de la société est aujourd’hui engorgée comme par un goulot d’étranglement à cause du travail intellectuel numérique ?
TLDR
- Les capacités d’agents LLM comme Claude et Codex ont, vers décembre 2025, franchi un certain seuil de cohérence, provoquant un changement de phase dans l’ingénierie logicielle et les domaines connexes
- On a l’impression que la partie intelligence est soudain très en avance sur tout le reste — intégration (outils, connaissances), besoin de nouveaux workflows organisationnels, processus, diffusion plus générale
- 2026 sera une année à haute énergie durant laquelle l’industrie devra digérer ces nouvelles capacités
15 commentaires
Il semble qu’une version des skills visant à améliorer le fonctionnement de Claude Code sur la base du contenu de cet article ait également été publiée.
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
J’ai l’impression que je négligeais beaucoup trop les 20 % restants.
Récemment, je suis tombé sur un bug que l’IA ne parvenait pas à résoudre… ce n’est pas une solution miracle, mais je me suis rendu compte que je la considérais comme telle.
Ah... hahaha
C’est une question que je me pose souvent : c’est très bien que des personnes déjà habituées au code à la main supervisent les LLM, mais pour ceux qui apprennent en partant de zéro, s’ils ne font que regarder le code généré par les LLM, j’ai l’impression qu’il leur sera difficile de savoir si c’est correct ou non.
À l’époque, ceux qui programmaient en assembleur se sont-ils dit, à l’arrivée des compilateurs, quelque chose comme : comment faire confiance à un compilateur qui produit une sortie assembleur aussi mauvaise ?
Même alors, ils devaient sans doute coder en C tout en orientant l’écriture pour que la sortie assembleur corresponde à ce qu’ils voulaient.
Je me demande aussi si, à mesure que l’ère de l’IA progressera, on arrivera à produire de bonnes versions finales en langage naturel sans supervision humaine.
Même à l’époque où les humains écrivaient le code, j’ai l’impression que si on n’étudiait pas, on ne savait pas ce qui n’allait pas lol
Les experts en assembleur critiquent encore les compilateurs. Au fond, l’important, c’est que dans les situations où une optimisation extrême est nécessaire, on a besoin de ce genre de spécialistes ; appliqué à l’IA, cela veut dire que même si l’IA progresse énormément, il lui sera peut-être difficile de surpasser les personnes capables de coder au plus haut niveau d’optimisation. Mais de façon générale, aucun humain ne peut déjà battre l’IA. Ce serait amusant d’avoir un nouveau moment à la AlphaGo avec une confrontation AlphaCode.
Si l’on fait l’effort d’analyser et de comprendre le code qu’il produit, cela devrait aller.
Le compilateur relève d’un concept un peu différent : comme il génère de l’assembleur de manière déterministe sur la base de règles, une fois le problème vérifié il ne se reproduit généralement pas ensuite. Mais les LLM relèvent d’un domaine probabiliste, donc il reste une possibilité que le problème se reproduise.
Peut-être qu’avec les progrès de cette précision probabiliste, on se rapprochera des 100 %, mais si la demande en langage naturel elle-même est imprécise, le résultat finira lui aussi par l’être ; au fond, j’ai l’impression qu’un
bonlivrable final dépend malgré tout de l’humain.Moi aussi, je m’inquiète pour les profils juniors qui côtoient les LLM depuis leurs années d’études. J’ai aussi l’impression que le vivier de recrutement junior s’est un peu dégradé, mais c’est encore difficile à prouver…
Personnellement, j’ai l’impression qu’avec seulement des connaissances en CS, il n’y a pas une si grande différence.
Ou alors c’est peut-être parce que la façon dont je l’utilise actuellement me donne l’impression de faire du pair programming avec un collègue qui tape extrêmement vite et écrit tout le code à ma place...
Au final, quand on développe en profondeur, il arrive forcément un moment où il faut comprendre ce qu’il y a à l’intérieur des couches d’abstraction
l’écart entre les prompts en langage naturel et le code généré est trop grand, donc il semble difficile, à partir du prompt, d’entrer à l’intérieur de la couche d’abstraction du LLM
À l’heure actuelle, on transmet au LLM, via un prompt, le concept de la spécification qu’on avait en tête, puis on relit le code produit pour le vérifier
ça se rapproche davantage d’une revue de code écrit par quelqu’un d’autre, donc je n’ai pas vraiment l’impression d’entrer à l’intérieur de l’abstraction
Je suis tout à fait d’accord. Sur un projet récent, j’ai commité environ 100 000 lignes de code (et le volume réel de code est encore plus important) et j’utilise en moyenne 2 à 3 agents. Je dirais que 95 % du code est écrit par les agents.
Mais il faut toujours gérer les tests et le code mort, et il faut des détails sur les cas de test et les critères de réussite des tests. Il est important de piloter ce qui doit être fait, et jusqu’où. Pour cela, il faut mettre à jour en continu non seulement le plan, mais aussi l’architecture qui fournit le harness, ainsi que les paramètres comme les Rules.
Avis sur Hacker News
Il est intéressant de voir l’agent continuer d’essayer sans se fatiguer
Les GPU et NPU tournent à plein régime, et nous lui donnons même des données que nous ne partagerions pas en temps normal
Cela ressemble aujourd’hui à un échange pratique, mais à long terme il existe un risque croissant de dépendance et de problèmes sociétaux
Au final, cela pourrait nous enfermer dans une structure de dépendance à l’égard de cet énorme gatekeeper
En travaillant avec l’IA, le problème plus grave que l’atrophie cérébrale semble être la transformation en autosatisfaction et apathie
Au début, les résultats rapides procurent un pic de dopamine, mais à force de répétition on a l’impression que l’IA entraîne le projet dans sa propre direction
Au final, les expérimentations créatives que je voulais faire disparaissent, aspirées par la gravité de l’espace latent de l’IA
C’est comme du doomscrolling : une boucle addictive qui donne sans cesse envie de voir la sortie suivante
Je crée un jeu multijoueur avec Rust et Bevy, et même si le code fonctionne bien, il devient du code que je ne comprends pas
Avant, je ne serais jamais arrivé jusque-là sans comprendre complètement mes outils ; aujourd’hui j’ai fabriqué un jeu à moitié fonctionnel sans même savoir ce qu’est l’ECS
Quand on pense à la maintenance ou aux interventions d’urgence, c’est vraiment dangereux
Nous nous concentrons désormais sur l’apprentissage des modèles, et nous oublions comment penser par nous-mêmes
Comme les façons d’utiliser les LLM changent en permanence, cela revient à rester sur un tapis de course d’apprentissage éternel
Même après une longue pause, les réflexes restent, et ils reviennent vite une fois qu’on s’y remet
De plus en plus de développeurs abandonnent dès que le LLM ne sait pas, et ne veulent plus lire la documentation
Même si on leur montre la doc directement, captures d’écran à l’appui, ils demandent encore : « Tu es sûr que c’est correct ? »
On continue à lancer de petits prompts pour une gratification brève, en attendant de voir « ce qui va sortir cette fois »
Le coding avec les LLM devient un moyen de distinguer ceux qui aiment coder de ceux qui aiment construire
J’aime produire des résultats, j’ai un profil de builder, donc ce changement me plaît
En revanche, ceux qui aiment le code pour lui-même sont mal à l’aise avec cette évolution
Le charme de la programmation résidait dans le processus de structuration du problème et d’exécution directe
Aujourd’hui, j’ai l’impression de ne plus coder moi-même, mais de donner des ordres, et cela me passionne moins
Il y a déjà eu par le passé des oppositions comme compilé vs interprété, typé vs non typé, déploiement rapide vs maintenabilité
Au final, les logiciels qui réussissent passent d’une phase initiale chaotique à une phase d’extension stable
Je ne sais toujours pas si l’IA aide ce processus ou le rend au contraire plus complexe
Ce n’est pas seulement le résultat final qui les intéresse, mais le plaisir de structurer le système
Un coéquipier humain implique responsabilité et confiance, ce qui n’est pas le cas d’un LLM
L’idée que l’IA puisse apporter un gain de productivité x10 est intéressante
DevOps a transformé la manière dont dev et ops collaborent pour créer des équipes à haute performance, avec un effet proche d’un 10X à l’échelle de l’équipe
Pour bien utiliser l’IA pour coder, il faut comme avec DevOps un processus d’amélioration continue, des changements de workflow et une accumulation de confiance via l’automatisation et la vérification
De même que DevOps ne s’est pas diffusé partout parce qu’il exigeait l’apprentissage de nouveaux concepts et une évolution de la culture d’équipe, le coding avec l’IA pourrait lui aussi avoir du mal à se généraliser malgré son potentiel x10 s’il n’y a pas de changement d’apprentissage et de culture
Son adoption durable exige de la formation et une évolution de la culture d’ingénierie
J’ai trouvé les LLM inutiles sur les grandes codebases
En particulier dans du code complexe avec beaucoup d’interactions, ils n’aident presque pas
Les introduire dans une grande codebase existante et complexe est risqué, sauf pour des changements limités et soigneusement relus
Sur une structure simple, donner une liste de fichiers et laisser l’agent implémenter est impressionnant, mais à mesure que la complexité augmente, il faut des prompts de plus en plus détaillés pour conserver de bons résultats
Contrairement aux modèles précédents, il apporte désormais une aide concrète même dans des monorepos complexes
Il faut comparer avec ce qu’un nouveau membre de l’équipe ferait avec les mêmes informations
Les codebases internes commerciales deviennent désordonnées à force de développement itératif pour répondre aux demandes des clients, tandis que les hypothèses initiales et les besoins réels divergent progressivement, créant de la dette technique
Si l’on utilise un LLM pour refactorer en séparant les helpers, en modularisant, en renommant, afin de réaligner le tout sur les besoins actuels, le comportement des agents devient ensuite plus prévisible
Il faut organiser les exigences, critères d’acceptation et user stories en markdown, lui faire détailler le plan, puis passer à l’implémentation dans un flux progressif
Il est impressionnant de voir à quel point la persévérance et l’endurance de l’IA dépassent les limites humaines
Même dans la recherche, on dit que la ténacité (grit) est plus étroitement liée au succès que l’intelligence
Tant que le budget le permet, un LLM dispose d’une persévérance quasi infinie
Ces derniers mois, j’ai eu l’impression que les performances de l’IA avaient plutôt régressé
Elle oublie les règles, génère des plans excessifs et du code surconçu
En revanche, elle reste utile en frontend (HTML + Tailwind)
Je trouve prématurées les attentes excessives autour des IDE ou des essaims d’agents
En développant une app iPhone, j’ai été impressionné par la capacité de Claude à générer du code à partir de prompts en anglais
En recoupant aussi ce que j’entends autour de moi, j’ai l’impression qu’au final on se retrouve effectivement dans cette distinction.