Si l’IA écrit le code, pourquoi utiliser Python ?

 (medium.com/@NMitchem)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Avec le développement assisté par l’IA, les critères de choix d’un langage se déplacent de la vitesse d’écriture humaine vers la capacité de l’IA à corriger et vers les performances à l’exécution
  • En 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1 et DeepSeek V4 dépassent 80 % sur SWE-bench Verified
  • Rust aide l’IA à s’autocorriger grâce à sa boucle de feedback du compilateur ; Go et Swift sont eux aussi favorables aux agents grâce à leur vérification de types rapide
  • De grandes transitions sont déjà en cours, comme le portage en Go du compilateur TypeScript, un compilateur C en Rust, Rue ou encore le portage du moteur JS de Ladybird
  • Les écosystèmes Python et JavaScript dépendent eux aussi de plus en plus d’outils Rust et de wrappers, même s’il subsiste des exceptions comme Prisma, PyTorch ou certains langages plus modestes

Les critères de choix d’un langage changés par le développement assisté par l’IA

  • Pendant longtemps, le choix par défaut pour un nouveau projet était Python ou TypeScript
    • parce que l’écosystème était vaste, le vivier de recrutement large, et qu’on pouvait produire rapidement une démo
    • Rust, Go et C++ pouvaient offrir des performances 10 à 100 fois supérieures, mais le temps d’apprentissage, un marché des talents plus réduit et des systèmes de build plus complexes représentaient un coût
    • on lançait donc d’abord une version Python en se disant qu’on « améliorerait les performances plus tard », mais en pratique elle restait souvent telle quelle
  • Cet équilibre vacille à mesure que l’IA se met à maîtriser des langages difficiles
    • dans le choix d’un langage, la question « un humain peut-il l’écrire vite ? » pèse désormais moins que « l’IA peut-elle bien l’écrire et le corriger ? », ainsi que les performances à l’exécution

Les langages difficiles deviennent plus faciles d’abord pour l’IA

  • Il y a deux ans, GPT-4 en était au point d’inventer des noms de crates inexistants en écrivant des fonctions Rust
  • En avril 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1 et DeepSeek V4 dépassent chacun 80 % sur SWE-bench Verified, à quelques semaines d’intervalle
  • Les laboratoires optimisent explicitement leurs modèles pour le travail système
    • bugs de concurrence
    • conditions de course
    • défauts d’architecture détectés dès la phase de planification
  • CtrlAltDwayne explique la force de Rust en 2026 moins par sa sûreté mémoire ou ses performances que par la boucle de feedback du compilateur
    • l’IA écrit mieux du Rust que du C++
    • les messages d’erreur du compilateur Rust servent de signal pour l’autocorrection en temps réel du modèle
    • Rust fonctionne comme un langage « accidentellement conçu » avec 10 ans d’avance pour le développement assisté par l’IA
  • La même logique s’applique aussi, à des degrés divers, à Go et Swift
    • leur système de types strict et leur boucle de compilation/vérification rapide offrent aux agents un cycle d’itération serré
    • les langages système difficiles pour les humains peuvent au contraire devenir plus faciles pour les agents

Des cas concrets déjà mis en production

  • Portage en Go du compilateur TypeScript par Microsoft

    • Microsoft a publié TypeScript 7.0 beta et a porté une base de code TypeScript vieille de 10 ans en Go
    • TypeScript 7.0 beta est environ 10 fois plus rapide que 6.0
    • Selon l’analyse d’Anders Hejlsberg, Go fournit l’essentiel des gains de performance pour une fraction du coût d’ingénierie
    • l’un des plus grands groupes JS/TS a donc estimé que le rapport effort/bénéfice justifiait de choisir, pour son outil principal, un langage plus difficile mais plus rapide

  • Un compilateur C en Rust créé avec 16 agents Claude

    • Le chercheur d’Anthropic Nicholas Carlini a coordonné en parallèle 16 agents Claude pour écrire un compilateur C de production en Rust
    • le projet représente 100 000 lignes et démarre Linux 6.9 sur x86, ARM et RISC-V
    • il compile QEMU, FFmpeg, SQLite, PostgreSQL et Redis, et fait aussi tourner Doom
    • le coût total est resté sous les 20 000 dollars, répartis sur près de 2 000 sessions Claude Code
    • un compilateur C écrit en Rust relevait autrefois du sujet de thèse ; ce n’est plus un travail aussi exceptionnel

  • Rue de Steve Klabnik

    • Steve Klabnik, co-auteur de The Rust Programming Language et vétéran de Rust depuis 13 ans, a créé avec Claude un nouveau langage système appelé Rue en deux semaines
    • le résultat représentait environ 70 000 lignes de Rust
    • il a indiqué que ce travail de deux semaines allait plus loin que des tentatives qui lui avaient auparavant pris un à deux mois

  • Portage en Rust du moteur JavaScript de Ladybird

    • Andreas Kling, fondateur du navigateur Ladybird et ingénieur C++, a donné à Claude Code et Codex des centaines de petits prompts, puis a porté en deux semaines le moteur JavaScript de Ladybird de C++ vers Rust
    • le résultat comptait environ 25 000 lignes de Rust et a atteint une équivalence octet par octet avec l’original en C++
    • aucun régressif n’a été observé sur plus de 65 000 tests, en combinant test262 et les tests Ladybird
    • il a expliqué qu’à la main, le même travail lui aurait pris plusieurs mois

Une logique de « l’écosystème » qui s’affaiblit

  • L’argument le plus fort en faveur de Python et JavaScript concernait moins le langage lui-même que l’écosystème
    • FastAPI, Django, PyTorch, React, Next.js et les 4 millions de packages npm formaient déjà une base
    • si les équipes pouvaient livrer des fonctionnalités en quelques jours, c’est parce que l’écosystème avait déjà résolu 90 % du problème
  • Cet avantage a été décisif pendant les 10 dernières années, mais il s’affaiblit depuis deux ans
  • L’écosystème Python lui-même dépend de plus en plus de composants basés sur Rust
    • le cœur complet de validation de pydantic est une bibliothèque Rust
    • Polars, alternative à pandas, est écrit en Rust
    • les tokenizers de Hugging Face et orjson sont aussi en Rust
    • selon la Python survey 2025 de JetBrains, l’usage de Rust dans les extensions binaires Python est passé de 27 % à 33 % en un an
  • Les fondations des outils de développement évoluent dans la même direction
    • Astral, fondée en 2022 par Charlie Marsh, a lancé ruff, uv et ty, tous écrits en Rust, et leurs téléchargements mensuels sont passés de zéro à des centaines de millions
    • Le 19 mars 2026, OpenAI a acquis Astral et estime que uv fait économiser à Codex environ 1 million de minutes de calcul par semaine
    • dix semaines plus tôt, Anthropic a acquis Bun
    • Bun a atteint 7 millions de téléchargements mensuels et 89 000 étoiles sur GitHub, et a été qualifié « d’infrastructure essentielle pour l’ingénierie logicielle pilotée par l’IA »
    • VoidZero d’Evan You a lancé Rolldown-Vite
    • ce bundler Rust réduit les builds de GitLab de 2,5 minutes à 40 secondes et divise l’usage mémoire par 100
  • Lee Robinson, vice-président produits chez Vercel, affirme qu’on a « atteint un plafond d’optimisation en JS »
  • Les packages utilisés dans Python et JavaScript deviennent de plus en plus des wrappers autour de code écrit dans des langages auparavant jugés trop difficiles pour livrer directement
    • si l’on peut désormais livrer directement dans ces langages, ces wrappers commencent à ressembler à un surcoût

Quand porter devient plus facile que patcher

  • Le cercle vertueux historique des écosystèmes open source était centré sur le patch
    • on choisissait Python parce qu’il était simple
    • on trouvait un bug dans une dépendance
    • on le corrigeait puis on le faisait remonter en upstream
    • l’écosystème en ressortait plus sain
  • Les agents déplacent l’unité de contribution du patch vers le portage
  • En janvier, le créateur de Flask, Armin Ronacher, a utilisé des agents pour porter en Go la bibliothèque Rust MiniJinja
    • le temps total d’exécution a été de 10 heures
    • dont 3 heures de supervision et 7 heures en autonomie
    • le temps humain réel n’a été que de 45 minutes
    • le coût API a été de 60 dollars
  • Si le portage d’une bibliothèque entre langages devient un travail de 45 minutes, l’argument en faveur de corrections envoyées dans la bibliothèque d’un tiers s’affaiblit
    • ce n’est plus « pourquoi forker quand on peut patcher ? », mais « pourquoi patcher quand on peut forker ? »
  • Armin Ronacher estime que la valeur se déplace du code vers les tests et la documentation
    • une bonne suite de tests peut avoir plus de valeur que le code lui-même
  • La boucle qui a construit PyPI et npm fonctionne encore aujourd’hui, mais rien ne dit clairement qu’elle fonctionnera encore telle quelle en 2028

Des exceptions demeurent

  • Tous les changements ne vont pas dans une seule direction
  • Dans certains cas, le choix historique reste le bon
    • Prisma a retiré son query engine Rust pour passer à un cœur TypeScript/WASM
    • la taille du bundle a baissé de 85 % et les requêtes sont devenues jusqu’à 3,4 fois plus rapides
    • les binaires Rust natifs sont désavantagés dans les runtimes serverless
  • PyTorch représente encore environ 85 % de la recherche en deep learning
    • comme les poids des modèles ne dépendent pas du langage qui les encapsule, cette position ne changera pas facilement
  • L’IA ne maîtrise pas encore tous les langages système au même niveau
    • pour des langages plus modestes comme Zig, Haskell ou Gleam, la qualité de génération n’est pas encore au niveau de Rust ou Go
    • les données d’entraînement déterminent l’étendue de l’aide que le modèle peut apporter
    • Rust et Go sont en position favorable parce qu’ils sont suffisamment présents sur GitHub
    • Zig, Haskell et Gleam sont encore du mauvais côté de cette courbe

Pourquoi ce changement pourrait durer

  • Les arguments défensifs de Python et TypeScript reposaient en réalité sur l’expérience développeur
    • ils étaient choisis parce qu’ils minimisaient la friction entre l’idée d’un humain et le produit livré
    • Rust n’était pas un langage lent à l’exécution, c’était un langage lent quand il fallait livrer à 2 heures du matin
  • Désormais, les agents commencent à prendre en charge les parties difficiles
    • le rôle humain se déplace de « l’écriture du code » vers « la conception du système et la revue des sorties »
    • dans ce cadre, le confort syntaxique de Python compte moins à chaque embranchement
    • les avantages à l’exécution des langages plus difficiles s’accumulent chaque jour où le service tourne en production
  • Dans son billet de février A Language For Agents, Armin Ronacher estime que la chute du coût du codage réduit l’importance de l’ampleur d’un écosystème
  • Les choix de langage des 20 dernières années se sont construits autour d’une contrainte : « ce sont des humains qui écrivent le code, et les humains sont lents en langage bas niveau »
    • cette contrainte commence à disparaître
  • Dans l’enquête Stack Overflow 2025, Rust reste pour la dixième année consécutive le langage le plus admiré, avec 72 %
    • Gleam est à 70 %
    • Elixir à 66 %
    • Zig à 64 %
    • la préférence existait déjà ; les outils ne font maintenant que la rattraper

La prochaine étape : des langages faciles pour les agents

  • En février, Karpathy a expliqué que les LLM changent tout le paysage des contraintes du logiciel
    • il voit un signe de cela dans le mouvement de portage de C vers Rust
    • il ajoute que même Rust n’est probablement pas encore proche du langage optimal pour les LLM
  • Les gagnants actuels ne sont peut-être qu’un point de départ, et la forme finale pourrait être encore plus lointaine
  • Le 24 avril, @RealRichomie a déclaré que l’avenir de la programmation irait non pas vers le langage le plus facile pour les humains, mais vers le langage le plus facile pour les agents
    • des ingénieurs ont livré une application Mac sans rien connaître à Rust ni à Tauri au départ
    • le résultat faisait environ un dixième de la taille d’une version Electron et offrait de meilleures performances à l’exécution
    • les humains obtiennent donc ce résultat sans avoir besoin d’apprendre Rust
  • Le prochain projet n’a pas forcément besoin de prendre Python comme choix par défaut

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires de Hacker News

  • Si l’on accepte l’idée que les outils de codage par LLM sont une sorte de compilateur non déterministe, alors choisir un langage aussi performant que possible a plutôt du sens
    Bien sûr, il y a plein d’exceptions, comme les bibliothèques ou les avantages natifs propres à chaque langage, mais après avoir travaillé en C++ pendant environ un mois, la seule chose que le choix du langage ait ralentie, c’était le temps de compilation

  • J’ai été surpris de ne pas voir parler des données d’entraînement même après avoir lu les premiers commentaires. Il y a énormément de code Python dans les données d’entraînement
    On peut sans doute faire écrire du Brainfuck par une IA, mais je doute qu’on obtienne le même résultat qu’avec Python
    La vraie question ensuite, c’est : maintenant qu’on a l’IA, pourquoi se soucier du langage avant que cela ne devienne nécessaire ?

    • J’avais envie de refaire du Perl pour la première fois depuis 5 ans, et j’avais besoin d’un moyen très simple de lancer le proxy que je développais en Go et d’écrire plusieurs tests d’intégration
      J’ai laissé Claude Code en écrire la majeure partie, et Claude maîtrisait vraiment très bien Perl. Je lui ai demandé de ne pas toucher à CPAN et de n’utiliser que la bibliothèque standard de Perl, et il y avait déjà un client HTTP, TLS et JSON intégrés ; ça a permis de remplacer de façon très fiable et simple quelque chose que j’aurais normalement fait en script shell
      Comme Perl n’a pas beaucoup changé et qu’il existe beaucoup de données d’entraînement, Claude semble assez bien utiliser Perl dans les situations où l’on penserait spontanément à un script shell
    • Étonnamment, les LLM raisonnent bien moins bien en Python que dans d’autres langages de programmation courants pour les tâches de codage agentique
      Les données sont ici : https://gertlabs.com/rankings?mode=agentic_coding
    • Il suffit d’utiliser Go. Les LLM ont beaucoup vu Go, ils l’écrivent bien, ça compile presque instantanément, et on profite de tous les avantages d’un langage compilé et typé
      J’ai construit une grosse base de code Python avec une IA, et le LLM se trompait sans arrêt sur les arguments ou le format des dictionnaires. Les tests unitaires ou des outils comme pydantic aident, bien sûr, mais il vaut mieux éviter d’emblée ce genre d’erreurs d’exécution
    • Les seules données d’entraînement ne suffisent pas à expliquer toute la réponse. Les LLM sont vraiment très bons pour traduire d’un langage de programmation à un autre. C’est logique quand on pense qu’ils dérivent de systèmes de traduction de texte
      J’ai obtenu d’excellents résultats même avec des langages qui ont relativement peu de code public. Le plus gros obstacle, c’est plutôt que les LLM recopient les idiomes courants du langage cible ; avec des langages “orientés entreprise” comme Java ou C#, on peut très vite voir exploser la quantité de code boilerplate inutile. Le résultat risque alors de dépasser la taille de fenêtre de contexte exploitable et d’en dégrader la qualité
    • Si l’on demande à l’IA de générer du code en boucle ouverte, les données d’entraînement peuvent effectivement être importantes, car il est plus probable qu’un code proche de ce qu’on demande existe déjà en Python
      Mais si un agent produit le code, tente de le compiler, lit les messages d’erreur détaillés puis affine le code à partir de ces messages, on obtient un résultat de meilleure qualité. Les diagnostics de rustc sont excellents, et même s’il existe bien plus de Python ou de JavaScript/TypeScript, il y a désormais suffisamment de code Rust en ligne

  • La raison pour laquelle j’utilise Python, c’est exactement la même que depuis plus de 10 ans : je sais le déboguer, et je peux sentir en quelques secondes si l’agent est en train de faire quelque chose qui risque de très mal finir
    Ce n’est pas le cas avec d’autres langages, et il me faudrait en réapprendre beaucoup. Même si l’IA produit du code très vite, je préfère Python, parce que j’ai au moins l’impression de garder un certain contrôle. Avec Go ou Rust, cela m’aurait donné l’impression de faire non pas de la programmation assistée par IA, mais du “vibe coding” où l’on pousse tout le produit en mode YOLO

    • J’ai commencé à utiliser Rust à l’ère des agents, et l’expérience acquise dans d’autres langages m’a quand même aidé à repérer les odeurs de code et les mauvaises architectures
      Pour la partie sûreté mémoire, j’ai dû apprendre parce que je ne savais pas ce qui était “correct”, mais pour le reste, la transition s’est bien passée
      La syntaxe finit par s’effacer à l’arrière-plan, on se concentre sur des choses de plus haut niveau et on explore de nouvelles pistes. Si vous essayez, vous serez peut-être agréablement surpris de voir à quel point votre expérience est transférable
    • Pareil pour moi. Je peux repérer presque immédiatement si le Python généré par l’IA raconte n’importe quoi, donc je continue d’utiliser Python pour la plupart des projets

  • Si l’IA écrit à votre place, pourquoi utiliser encore votre cerveau ?

    • Ce n’est pas totalement risible. Les modèles sont bien meilleurs que le mois dernier et le coût des tokens a baissé. Les LLM sont comme des compilateurs pour le cerveau
      /s

  • Pourquoi s’arrêter à faire écrire du Rust par l’IA ? Si tout devient du vibe coding et qu’on ne fait même plus de revue de code, autant laisser le LLM concevoir un langage ultra-concis et ultra-dense optimisé uniquement pour minimiser l’usage des tokens et maximiser la vitesse
    Ce commentaire se termine par un /s seulement à moitié ironique

    • Pourquoi s’arrêter à l’écriture du code ? Nous devrions tous créer nos propres puces ASIC sur mesure, et si nous n’avons pas de fab, au minimum faire du FPGA

  • Un peu hors sujet, mais je ne comprends vraiment pas pourquoi les gens publient encore sur Medium
    L’expérience de lecture est atroce. Une popup en plein écran a littéralement masqué la phrase que j’étais en train de lire, au point que je n’ai même pas pu finir cet article
    Y a-t-il une incitation que je ne vois pas ?

    • Rien de ce qui se lit dans un navigateur ne pourra jamais offrir à tout le monde une expérience de lecture ultime, excellente et de loin supérieure de manière uniforme. Le modèle même du web moderne s’y oppose
      Une simple page HTML sans CSS est presque une expérience de lecture parfaite. Le problème, c’est que presque personne ne publie ainsi. Le web est devenu une plateforme d’édition sur laquelle les auteurs se battent pour attirer l’attention. Un protocole en texte brut, contrôlé par l’utilisateur, se rapproche davantage d’une “meilleure expérience de lecture pour tous”. Le web aurait pu l’être, mais dans la plupart des cas, il ne l’est pas
      J’ai renoncé à essayer de lire de longs textes dans le navigateur. Je peux extraire facilement le texte brut pertinent, voire du texte structuré, et le lire dans mon éditeur : pourquoi le lire dans un navigateur ? Je peux contrôler la police, les couleurs, la navigation, etc. Le navigateur est un moyen de transport, pas un environnement de lecture. Le traiter autrement relève de l’habitude, pas d’une nécessité
      Depuis longtemps, je n’écris plus rien de plus long que trois mots en dehors de mon éditeur. J’y ai déjà tout ce qu’il me faut : correcteur orthographique, dictionnaire de synonymes, recherche étymologique, traduction, accès à toutes mes notes, intégration LLM. Essayez un jour, c’est incroyablement libérateur. Et ensuite, vous pourrez aussi arrêter de lire de longs textes dans le navigateur

    • Medium a fait un effort assez sérieux pour rémunérer les auteurs. C’est un modèle différent de Substack, mais c’est bien la raison
      Je le vois un peu comme les paywalls des journaux. Je n’aime pas ça, mais je comprends pourquoi ils existent

    • L’hypothèse la plus plausible, c’est l’inertie. Certaines personnes sont très attachées aux marques et ont besoin de faire comme les autres
      En réalité, l’endroit où c’est publié importe peu tant qu’on a l’URL, mais tout le monde ne fonctionne pas comme ça

    • Cela ressemble à la dernière évolution des plateformes de blog pensées pour les auteurs. C’est plus facile à empaqueter sous forme de newsletter que WordPress, et aussi plus simple à monétiser avec un palier payant

    • Le frontend alternatif à Medium, Scribe, est bien meilleur :
      https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...

      https://sr.ht/~edwardloveall/Scribe/
      https://libredirect.github.io/

  • Python a un écosystème bien plus mature que Rust, surtout dans le domaine de l’IA et du machine learning
    Je suis tombé sur une crate Rust qui prétendait implémenter un certain algorithme de machine learning, mais elle ne fonctionnait pas correctement. Cela dit, j’ai quand même pu faire écrire une implémentation de remplacement par Claude
    Avec l’IA, je pense qu’il est judicieux de faire respecter la correction au niveau du système de types, donc je choisis souvent des langages comme C# ou Rust plutôt que Python. Mais pour certains usages, Python reste clairement le bon outil

    • Je choisis presque toujours Rust. Récemment, j’ai créé un plugin pour quelque chose écrit en Go
      J’aurais pu utiliser Rust, mais si le résultat fonctionne bien, les autres auront plus à gagner en n’ayant qu’une seule chaîne d’outils, donc Go me semblait plus approprié
      La raison essentielle, c’est qu’il faut pouvoir le relire quand nécessaire. Et l’écosystème destinataire attend parfois un langage donné. Si certaines communautés de data science choisissent R, MatLab, Julia, Python ou Mojo, ce n’est pas seulement une question de supériorité technique, mais aussi de ce qu’utilisent leurs pairs
    • À mon avis, le seul vrai cas d’usage, c’est quand on encapsule des bibliothèques C++ bas niveau, comme les bibliothèques de machine learning. Celles-là sont vraiment difficiles à reproduire
    • Il y a plusieurs raisons pour lesquelles l’application stricte d’un système de types est bénéfique avec l’IA
      Je suppose que les langages typés ont souvent des serveurs de langage plus rapides et meilleurs, ce qui permet de modifier le code plus efficacement à l’aide d’outils
      Et lorsque des humains doivent intervenir eux-mêmes pour examiner ou modifier le code, un typage fort permet aussi de s’orienter beaucoup plus facilement dans du code spaghetti
    • Il y a clairement quelque chose à dire sur le support des bibliothèques en IA/machine learning. Malgré cela, ces temps-ci, je tends à faire le backend en Rust/TypeScript. Et ce, même si j’aime vraiment Django
    • Si l’on sort de l’écosystème Python et que l’on va laisser l’IA gérer les dépendances ou faire des polyfills, autant aller jusqu’à OCaml/F# plutôt que Rust
      On bénéficie alors du garbage collector et d’un typage fort

  • Pour l’instant, c’est exactement la même raison que lorsqu’un humain écrit le code : bien plus de gens connaissent Python que Zig, donc les humains pourront le lire et le modifier plus facilement
    Je comprends l’idée de l’article, mais je ne pense pas qu’on en soit encore là

    • Un monde où l’automatisation écrit dans des langages que les humains ne comprennent pas me fait penser à une usine d’automatisation chinoise entièrement plongée dans le noir. Les humains y sont perdus et désorientés, mais les robots y sont parfaitement à l’aise

  • Une “application mise en production dans un langage que personne dans l’équipe ne connaît”, c’est magnifique. On repensera à ce genre de choses dans un avenir pas si lointain

    • Ce genre de situation existait déjà avant l’IA. Il y a 10 ans, quelqu’un a écrit un outil critique dans un langage choisi au hasard, et le reste de l’équipe a dû le maintenir. Et malgré tout, ils s’en sont sortis
    • C’est peut-être la seule chose au monde qui pourrait être encore plus effrayante que l’application Electron qu’ils remplaçaient
    • Il suffit de changer de poste dans 12 à 18 mois. Ce sera alors le problème de quelqu’un d’autre

  • L’affirmation selon laquelle “le chercheur d’Anthropic Nicholas Carlini a orchestré 16 agents Claude en parallèle pour écrire en Rust un compilateur C de production” est fausse
    Ce compilateur produit un code bien inférieur à celui de gcc/clang, donc il est en pratique inutile