Depuis des années, parler d’assistants pour le codage revenait à évoquer l’autocomplétion : de petites suggestions utiles, mais limitées. Pourtant, ces dernières semaines, une conversation animée autour de Andrej Karpathy (chercheur et vulgarisateur en intelligence artificielle) et de la réponse de Boris Cherny (responsable de Claude Code chez Anthropic) a cristallisé une idée que de nombreux ingénieurs observaient silencieusement : la programmation est en train d’entrer dans une nouvelle phase.

Ce n’est pas simplement une question de « faire la même chose, mais plus vite ». Le vrai saut — celui qui modifie nos habitudes — consiste à automatiser davantage au lieu de réduire le temps passé. Où auparavant une personne réservait ses efforts aux tâches « qui valent la peine », maintenant des projets qui n’auraient jamais été tentés prennent vie, non par manque de vision, mais par manque de temps, d’énergie ou de connaissances dans des domaines périphériques.

De 20 % à 80 %… en quelques semaines

Karpathy décrit une transition qui paraît exagérée jusqu’à ce qu’on l’ait expérimentée : passer d’un flux dominé par l’écriture manuelle (avec un peu d’autocomplétion) à un futur où les agents accomplissent la majorité du travail, l’humain se concentrant sur la supervision, la révision et la responsabilité du résultat final. La sensation est ambivalente : puissance décuplée… mais aussi un léger coup au ego. « Programmer en anglais » — donner des instructions et des critères de succès plutôt que taper chaque ligne — peut sembler étrange au début, mais devient addictif quand ça commence à fonctionner.

Cette transition ne repose pas sur de la magie. Elle s’appuie sur quelque chose de très concret : des actions importantes sur une base de code (refactorisations complètes, changements transversaux, instrumentation, tests) qui, auparavant, réclamaient une concentration soutenue et une patience de fer.

Vitesse versus expansion : la distinction qui explique tout

La partie la plus intéressante du débat n’est pas de savoir si l’on gagne du temps (ce qui est le cas), mais en quoi ce temps est investi. Karpathy résume cette idée par une notion que beaucoup partagent : l’effet principal n’est pas d’aller plus vite, mais d’élargir la carte. Avec des assistants capables de combler les lacunes techniques, des profils généralistes osent s’attaquer à des tâches mêlant plusieurs disciplines : pipelines vidéo, automatisation en ligne de commande, intégration de modèles, déploiements, documentation, voire aspects pédagogiques ou produits.

En résumé : le goulot d’étranglement n’est plus toujours « savoir coder », mais plutôt savoir quoi construire, comment le valider et quelles limites ne pas dépasser.

Les modèles continuent de faire des erreurs, mais de meilleures erreurs (et c’est dangereux)

Voici l’avertissement central : ceux qui célèbrent le « pas besoin d’IDE » ou les « nuées d’agents » risquent d’aller trop vite. Karpathy insiste sur le fait que les modèles font encore des erreurs, mais leur nature a changé : elles ne sont plus de simples fautes de syntaxe facilement détectables, mais des erreurs conceptuelles subtiles, semblables à celles d’un développeur junior pressé.

On peut repérer certains schémas récurrents :

• Ils supposent des choses que personne ne leur a demandées d’assumer.
• Ils gèrent mal la confusion : ils ne posent pas de questions, ne mettent pas en évidence les incohérences, ni n’évaluent les compromis.
• Ils ont tendance à compliquer excessivement : plus d’abstractions, plus de couches, davantage de lignes de code.
• Ils laissent des « restes » : code mort, commentaires inutiles, changements accidentels.

La conclusion n’est pas « ne pas utiliser d’agents », mais plutôt « les utiliser avec des règles » : tests, revues, limites d’étendue, et une mentalité d’inspection constante. Dans des logiciels critiques, l’humain ne disparaît pas : il change simplement de rôle.

« Je dois me rappeler que Claude peut le faire »

La déclaration qui a alimenté le plus cette discussion vient d’Anthropic. Boris Cherny, créateur et responsable de Claude Code, a indiqué que cette sensation de ré-apprendre les capacités du modèle lui arrive « la majorité des semaines ». Son exemple est révélateur : face à une fuite de mémoire, il a d’abord voulu procéder comme d’habitude (profiler, reproduire, examiner à la main). En revanche, un collègue a demandé à l’agent un dump du tas, l’a analysé et a obtenu un PR « d’entrée » en quelques minutes.

Cherny va encore plus loin en décrivant une routine qui semble de la science-fiction pour le développement traditionnel : des périodes où il ne touche pas au IDE, avec une cadence de dizaines — puis de centaines — de PR en peu de temps, le modèle écrivant le code et l’humain manœuvrant le pilotage. Au-delà du titre, le message sous-jacent est autre : l’habitude mentale a son poids. Ceux qui n’ont pas une mémoire historique des modèles précédents (nouveaux employés, jeunes diplômés) exploitent parfois mieux leurs capacités actuelles, puisqu’ils ne sont pas limités par des contraintes apprises.

La nouvelle voie compétitive : maîtriser l’art de l’édition, pas seulement la génération

Si le LLM rédige, qu’est-ce qui distingue les meilleurs ? La discrimination. Savoir lire avec du recul, repérer les suppositions implicites, faire des tests, simplifier. La compétence passe de « générer » à « évaluer ». Karpathy évoque aussi un effet secondaire gênant : l’atrophie. Moins on tape à la main, plus les muscles de l’écriture de solutions s’affaiblissent, même si la capacité de révision se maintient ou s’améliore.

Ce déplacement ouvre la porte à une vieille question sous un nouveau jour : qu’en est-il de l’ingénieur 10x ? Si les outils profitent à tous, la différence peut se réduire… ou s’accentuer, si les meilleurs maîtrisent l’art de diriger des agents, de définir des critères, de concevoir l’architecture et d’exiger la propreté du code.

2026 et le “slopacolypse” : quand le problème n’est plus de produire, mais de filtrer

Karpathy avance une prédiction presque inévitable : si générer du code devient facile, il en sera de même pour la documentation, les articles, les dépôts, les publications, les vidéos et le bruit. une “slopacolypse” — une avalanche de contenu médiocre — pourrait envahir GitHub, newsletters, réseaux sociaux et tout espace numérique.

Ce n’est pas simplement une question culturelle, mais un enjeu opérationnel. En période d’excès, la vraie force sera de curer, vérifier et maintenir des standards élevés. Dans le développement logiciel, cela passera par des processus renforcés : linters, tests, observabilité, revue de sécurité, gestion des dépendances, politiques de fusion et traçabilité réelle des changements.

L’avenir : moins de frappe, plus de direction… et plus d’ambition

La lecture la plus pertinente de cette tendance n’est peut-être pas la nostalgie ni l’euphorie, mais une re-interpretation des “carences” comme une feuille de route : ce qui aujourd’hui pose problème — clarifier les doutes, discuter des alternatives, freiner les suppositions, simplifier — est précisément ce qui va s’améliorer dans les prochains mois. Et quand ces améliorations arriveront, ce ne sera pas seulement en quantité, mais en qualité : des projets plus ambitieux, des équipes plus petites, des cycles plus courts.

Et une règle demeure : quand le logiciel a de l’importance, quelqu’un doit en prendre la responsabilité. L’IA peut générer beaucoup de code, mais la responsabilité, le jugement et l’orientation stratégique restent humains. Pour l’instant, la révolution ne remplace pas l’ingénieur : elle l’incite à devenir un maître d’orchestre.

Source : Karpathy donne des mots au “changement de phase” dans le codage avec LLM