Jeremy Theocharis, CTO d’UMH, a publié un post qui met en mots une sensation diffuse : les critiques des LLM ont raison sur presque tout, et lui les utilise quand même. Le texte a récolté plus de 300 points sur Hacker News, et les commentaires montrent que la dissonance décrite est partagée par beaucoup.

Theocharis raconte avoir été à la Local-First Conf à Berlin, où les orateurs critiquaient les LLM en recevant des applaudissements nourris, tandis que le public avait Claude Code ouvert sur le portable. Armin Ronacher, créateur de Flask, a admis du podium qu’il auto-ferme presque tous les PR et les issues de son projet Pi.dev, parce qu’ils sont submergés par des contributions générées par des modèles.

Pourquoi ça te concerne. Si tu utilises l’IA dans ton travail, tu connais probablement déjà cette tension. Les problèmes sont réels : l’inondation de contributions de faible qualité est en train d’éroder la confiance dans l’open source, et celui qui aurait dû apprendre du travail ennuyeux déléguée par les seniors se retrouve sans parcours de croissance. Mais l’outil, utilisé avec jugement, fait économiser des heures vraies. Comme on l’expliquait quand le créateur de Zig et George Hotz convergeaient sur la même position, les LLM sont utiles et le hype sur la singularité est vide (/fr/radar/zig-geohot-anti-hype-convergence).

La conversation utile est entre celui qui utilise l’outil et veut l’utiliser mieux, en sachant exactement où il se casse.

En détail

Theocharis structure le post en trois parties : les critiques valides, pourquoi il utilise les LLM quand même, et les patterns concrets qu’il a trouvés.

Les critiques qu’il partage. L’entraînement sur des matériaux couverts par le copyright, l’impact environnemental, la bulle financière autour de NVIDIA et OpenAI : Theocharis dit être d’accord sur presque tout. Le point qu’il approfondît le plus est la qualité des contributions open source. Avant les LLM, créer une pull request décente nécessitait du temps humain, et ce temps fonctionnait comme un filtre naturel. Maintenant n’importe qui peut ouvrir un compte GitHub et lancer un modèle sur un repository, et le mainteneur ne peut pas distinguer la contribution pensée de celle générée en masse. Des projets comme Zig et Gentoo ont déjà essayé de refuser les PR générées par IA, mais Theocharis note que c’est impossible à vérifier de façon fiable.

Le deuxième point concerne les juniors. Un senior a toujours corrigé le code des juniors, mais avant il savait que le junior avait passé des heures sur cette tâche. Maintenant il ne le sait plus. Et puisque les tâches répétitives, celles qui faisaient office de gymnase d’apprentissage, peuvent être déléguées à un LLM, le senior a moins d’incitation à prendre des juniors et leur enseigner le métier.

Pourquoi il utilise les LLM quand même. Theocharis n’offre pas une défense philosophique. Il dit que l’outil fonctionne pour son travail, et que le nier serait nier l’évidence. La position converge avec celle d’autres voix techniques de la communauté : reconnaître les défauts signifie utiliser l’outil les yeux ouverts, pas renoncer au bénéfice.

Les commentaires sur Hacker News montrent la même scission. Beaucoup confirment le problème de la confiance dans les contributions. D’autres soulignent que le modèle économique de l’open source basé sur le volontariat était déjà fragile avant les LLM. Quelqu’un note que la solution réside dans la construction de systèmes de vérification et de confiance différents, peut-être basés sur l’identité vérifiée hors ligne, au lieu d’interdire des outputs qu’on ne peut pas distinguer.

Ce qui reste ouvert. Le post ne résout pas la tension, il la nomme. Pour celui qui travaille avec l’IA, le takeaway pratique est celui que le cours traite dans la leçon sur la confiance calibrée : pas tous les erreurs pèsent pareil, et savoir où regarder avant d’utiliser un résultat compte plus que contrôler tout ou ne rien contrôler.