L’éternel Sloptember

• Les agents IA n’exécutent pas tant la programmation qu’ils n’imitent la distribution de la programmation, et leurs sorties défectueuses deviennent de plus en plus difficiles à repérer
• Ils ont servi à écrire une partie de tinygrad et à faire du reverse engineering d’une puce USB <-> PCIe, mais il reste le soupçon qu’en le faisant soi-même, cela aurait pu être meilleur et plus rapide
• Les agents accélèrent les progrès au début, mais pour finir, ils poussent à compter sur des tentatives répétées comme avec le levier d’une machine à sous, sans parvenir jusqu’au bout
• Les grandes organisations peuvent subir des dégâts de qualité plus importants que les individus très performants, à cause de boucles de feedback lentes et d’une production multipliée par 10 sans auto-vérification
• L’IA est utile pour la recherche et le prototypage rapide, mais il est difficile de la considérer comme un vrai ingénieur logiciel, et l’essentiel est de savoir quand ne pas l’utiliser

---

Principales critiques envers les agents IA

• La tendance à introduire des agents IA dans le développement logiciel peut être une erreur très coûteuse, car ces agents ressemblent davantage à des modèles statistiques sophistiqués qui imitent la distribution de la programmation qu’à de la programmation elle-même
• Les résultats sont défectueux, mais d’une manière de plus en plus difficile à détecter, et plus le modèle statistique devient précis, plus ces problèmes deviennent difficiles à voir
• Au cours des six derniers mois, ils ont été utilisés pour écrire une partie de tinygrad et faire le reverse engineering d’une puce USB <-> PCIe, mais il subsiste le doute qu’en le faisant soi-même, cela aurait pu être meilleur et plus rapide
• Les agents accélèrent les progrès au départ, mais à l’étape finale, ils font tirer encore et encore le levier d’une machine à sous dans l’espoir d’un meilleur résultat, sans permettre d’arriver au bout
• Puisque plusieurs modèles, harness et prompts ont été essayés, l’argument selon lequel ils auraient été “mal utilisés” convainc peu, et ressemble à l’idée qu’il suffirait de parier d’une certaine manière pour gagner à la machine à sous
• L’IA elle-même est utile : pour beaucoup de recherches, elle fonctionne comme un meilleur Google, et elle est très rapide pour du prototypage express quand on ne se soucie pas trop du niveau de finition
• En revanche, il est difficile de la voir comme un ingénieur logiciel, ni même comme quelque chose qui se rapproche des standards d’aucune entreprise avec laquelle l’auteur a travaillé ; l’essentiel est de savoir quand l’utiliser et quand ne pas l’utiliser

Impact sur les organisations et la qualité

• AFL a trouvé plus de bugs que les LLM, mais les développeurs n’ont pas craint d’y perdre leur statut, et les échecs comme le Go sont devenus encore plus populaires après l’arrivée de l’IA ; il est donc difficile de réduire les critiques de l’IA à une simple anxiété de statut
• Un futur où des assistants robotiques fiables rangent le code fait envie, mais la peur de la perte semble être utilisée pour vendre des agents de la manière susceptible de faire bouger les grandes entreprises
• Les grandes organisations ont sans doute plus à perdre avec les agents que les individus très performants ou les petites structures
  • Les profils les plus performants peuvent corriger les erreurs, repèrent plus facilement quand la production est bâclée, et sauf dans des domaines très limités, continuent à lire et comprendre attentivement chaque ligne
  • Les grandes organisations ont des boucles de feedback lentes et un alignement plus faible ; si des collaborateurs moins performants produisent 10 fois plus grâce aux agents sans auto-vérification, la qualité moyenne de la production peut baisser
• Les agents produiront sans doute plus de code, plus d’apps et plus de fonctionnalités qu’avant, mais on pourrait entrer dans une époque d’accumulation massive de productions bâclées plutôt que de pépites de haute qualité
• Les récits selon lesquels Apple pousse tous ses ingénieurs à utiliser l’IA doivent être examinés non pas à travers des attentes abstraites, mais via des questions concrètes comme : “macOS sera-t-il meilleur ou pire dans les deux prochaines années ?”
• Les gens supposent implicitement qu’un créateur a traversé un état d’esprit et un processus humains, mais cette hypothèse ne tient plus pour les productions de l’IA
• Des éléments comme la grammaire et la syntaxe, autrefois utilisés comme indicateurs indirects de qualité, deviennent moins utiles face aux productions de l’IA, et la différence apparaît lorsqu’on interagit avec elles de manière humaine ou qu’on construit quelque chose par-dessus
• Concernant les LLM, la position s’est rapprochée de celle de LeCun/Marcus : ces modèles ne savent pas programmer, et cela conduit à la conclusion que le processus est important
• Le deep learning peut toujours être la solution, mais pour de vrais agents de programmation, il faut un modèle du monde, et non une forme de RLVR qui commente les tests en échec avant d’affirmer que tous les tests passent
• L’enjeu central de cette époque pourrait être de savoir qui, au milieu de l’emballement collectif autour de l’IA, parvient à tenir sans se nuire lui-même

[GN⁺]

Avis sur Hacker News

• Le grand problème du discours actuel, c’est qu’il est trop manichéen. Si on doute des LLM, on est un luddite ; si on y croit, on est « ai pilled »
  Dans la plupart des cas, les LLM vous amènent à 80–95 % du chemin, parfois moins, parfois davantage. Et parfois, ils vous emmènent complètement dans la mauvaise direction
  Pourtant, tout le monde semble se battre uniquement pour savoir si les LLM peuvent devenir à eux seuls, dans un placard, des ingénieurs logiciel parfaits, et s’en sert ensuite pour nier leur énorme potentiel dans d’autres scénarios
  Quand on pense à tout ce que la seule existence d’Internet aurait déjà pu apporter en productivité à la plupart des organisations, on voit bien que, dans les entreprises réelles, on n’exploite souvent même pas une petite partie de ce qui est possible. Je vois les LLM sous cet angle
  Le problème, ce n’est pas le modèle de langage, c’est nous

  • Plus j’en apprends sur les vrais luddites, plus leur point de vue me paraît compréhensible
    À l’origine, les luddites protestaient surtout contre des machines utilisées pour produire des biens de mauvaise qualité de manière « frauduleuse et trompeuse », contourner les normes du travail et priver les artisans qualifiés de leurs moyens de subsistance
  • Il y a beaucoup trop d’argent en jeu pour avoir un débat rationnel
  • Le texte vise en particulier les agents : « introduire des agents IA dans le développement logiciel pourrait être l’une des erreurs les plus coûteuses de l’histoire de ce secteur »
    De mon côté, je n’utilise pas d’agents ; je construis des logiciels fonction par fonction via une simple interface de chat et une conversation continue. Le workflow qui en résulte est assez « chimérique » et tire beaucoup parti de mon expérience et de mon expertise. Le LLM ne fait que fluidifier le processus
    Dans mon cas, ça fonctionne bien, et je n’ai pas envie de revenir en arrière
  • Le point de geohot semble proche. Il ne s’agit ni de devenir totalement « ai pilled », ni de devenir luddite, mais plutôt d’utiliser l’IA comme un outil
  • Les luddites n’étaient pas de simples « sceptiques », mais des militants violents
    Dans le débat actuel, ceux qu’on appelle « luddites » sont généralement des gens qui osent douter de l’emballement autour de l’« IA ». En général, ce ne sont même pas des militants

• Au niveau actuel des capacités de l’IA, il m’a personnellement été utile de la voir comme une très bonne recherche appliquée à des connaissances existantes. Cela ressemble à l’étape suivante de la recherche, après les manuels de référence, Stack Overflow et GitHub
  Les programmeurs réutilisent et réinventent sans cesse les mêmes techniques, probablement plus que dans n’importe quel autre métier auquel je puisse penser, donc ils étaient particulièrement bien placés pour tirer parti d’un outil capable de très bien rechercher l’état de l’art. Le fait que l’IA puisse ensuite adapter cet état de l’art à un cas d’usage précis la rend encore plus puissante
  Cela dit, tout comme assembler des bouts de code copiés depuis Stack Overflow n’a jamais garanti un grand succès, l’IA actuelle ne parvient pas non plus à construire correctement un projet complet

  • Il devient clair que la réponse n’est pas forcément de tout bien empaqueter en bibliothèques réutilisables, mais plutôt d’avoir des outils qui réduisent le coût de la réécriture et de la réinvention
  • Je suis 100 % d’accord avec l’idée que l’IA actuelle ressemble davantage à une version renforcée de Stack Overflow et Google. D’après mon expérience, à part pour une ossature initiale, elle ne construit pas bien des applications complètes à grande échelle
    Dans une vieille codebase legacy peu utilisée, on peut par exemple demander à un agent IA de lire le code pour répondre à une question comme « comment l’application X fait-elle Y ? ». Mais je ne lui ferais pas produire des fonctionnalités à la chaîne ni prendre en charge des refactorings
    Sinon, on se retrouve avec trop de commits et une équipe de développement désorientée, avec de fortes chances d’obtenir quelque chose d’encore pire que le bazar qu’on gérait déjà. J’étais un peu déçu par l’IA ces derniers temps, et cette explication résume bien mon expérience
  • L’idée que « l’IA peut adapter l’état de l’art à un cas d’usage spécifique » est de toute façon exactement ce que tout le monde affirme

• En ingénierie logicielle, la chose la plus difficile est de résoudre le bon problème. À mon sens, la capacité à identifier quel problème doit être résolu est ce qui distingue les ingénieurs seniors de tout premier plan
  Pour simplifier, ici, on peut dire qu’il s’agit du problème dont la résolution apporte le plus de valeur au produit par rapport à la complexité et aux coûts annexes qu’elle entraîne
  Il y a longtemps, j’ai travaillé sur un produit web où un designer junior trouvait que ce serait sympa de pouvoir administrer le backend avec des outils LDAP. Le schéma et la structure de la base de données du produit imitaient donc OpenLDAP, avec des clés CN composites, et toute la codebase devait gérer cette structure à chaque lecture ou écriture en base. Au moment de concevoir le schéma de base de données, la compatibilité LDAP n’était pas le bon problème à résoudre
  Il peut être difficile d’identifier un logiciel qui résout les bons problèmes. En général, son fonctionnement paraît tellement évident qu’on ne voit même pas qu’un autre design aurait pu être choisi
  Avec le temps, ce qui limite généralement le rayon d’explosion d’un design qui résout les mauvais problèmes, c’est la friction qu’il produit. Le développement ralentit, et le développement qui ajoute encore plus de mauvais problèmes ralentit lui aussi. C’est un phénomène auto-limitant
  C’est précisément ce qui m’inquiète beaucoup avec les agents de code basés sur des LLM. Ils masquent cette friction. Ils ne corrigent pas le problème, ils en repoussent simplement le coût
  On se retrouve alors avec des codebases dont la complexité augmente sans limite par rapport à la valeur qu’elles apportent, sans mécanisme de contrôle
  Les juniors risquent de ne jamais passer par les boucles de feedback qui développent l’intuition et le goût d’ingénierie nécessaires pour juger quels problèmes sont les bons à résoudre dans un design donné
  À l’échelle de tout le secteur, on pourrait même finir par oublier qu’il a un jour existé une notion consistant à résoudre les bons problèmes
  Je ne sais pas quoi faire. Je devrais peut-être commencer à préparer une retraite anticipée

• Il y a actuellement des gens qui achètent des peptides du marché gris et s’injectent des substances marquées « pas pour consommation humaine » en se fiant uniquement à des anecdotes douteuses et à leur ressenti, pour avoir une peau plus nette ou augmenter leur masse musculaire
  Est-ce qu’ils se transforment soudain tous en zombies ? Non. Savent-ils réellement ce qui arrivera à leur corps dans quelques années ? Non plus. Est-ce que cela pourrait être catastrophique ? C’est possible
  Cette analogie me revient quand je pense au virage brutal du secteur, ces six derniers mois environ, vers l’IA comme principal générateur de code. L’IA, ce sont les peptides, et la base de code, c’est le corps. À quel point cette approche sera maintenable, littéralement personne n’en sait rien. Parce qu’il ne s’est tout simplement pas encore écoulé assez de temps pour le découvrir
  Ça peut très bien se passer, ou devenir un chaos total. Toute l’équipe d’ingénierie peut aussi lâcher le volant et s’endormir, persuadée de comprendre ce qu’elle construit alors qu’en réalité ce n’est pas le cas, puis perdre complètement la capacité de corriger ou maintenir quoi que ce soit au moment où le LLM n’arrive plus à suivre
  https://www.bbc.co.uk/news/articles/cdr268m5pxro
  Dans ma base de code personnelle, je ne procède plus ainsi, sauf si je me moque vraiment de la maintenabilité ou de la durée de vie

  • J’imagine que les développeurs intelligents vont créer des modules isolés. Ainsi, si un module généré par l’IA continue d’échouer, on peut l’amputer et le reconstruire

• En ce moment, je suis plutôt dans le camp du « je n’ai pas écrit de code moi-même depuis un moment ». J’aimerais voir un exemple d’un problème suffisamment grave pour me faire revenir au codage manuel
  Mon principal problème, c’est que la qualité varie d’une sortie de modèle à l’autre et que, surtout dans les outils en ligne de commande, ils ont tendance à ressortir des API ou de la documentation obsolètes
  Je comprends que les modèles peinent sur une base de code monolithique d’un million de lignes avec dix ans de déchets accumulés. Mais j’ai plus de mal à voir pourquoi ce serait si pénible sur une nouvelle base de code

  • Il n’est pas nécessaire que ce soit un problème « trop gros ». Cela peut aussi être quelque chose de trop petit pour valoir l’usage de l’outil
    Le code n’est pas si difficile ; il est souvent plus simple de coder directement que de lire et écrire en anglais. Cela dit, je n’utilise que Haskell, donc je suis peut-être biaisé
  • Au bout de combien de temps sans « écrire de code soi-même » estimes-tu qu’on finit par ne plus savoir coder, faute de pratique ?
    L’un des risques du management d’ingénierie, c’est justement de te transformer en quelqu’un qui n’est plus capable de faire ce travail
    Est-ce que c’est vraiment important ?
  • Si chaque prompt produit une PR de mille lignes, on n’est déjà plus très loin d’une autre base monolithique d’un million de lignes
    Cela dit, je suis un peu plus optimiste que l’auteur. J’ai l’impression qu’il est possible de gérer le processus pour éviter que cela n’arrive
  • Il y avait récemment un exemple en page d’accueil : https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/
  • Le type de projet compte. En particulier, tout dépend du degré de nouveauté, du nombre de points de données difficiles à trouver par recherche, et de l’ampleur des différences non triviales, propres au projet, par rapport aux standards du secteur

• Les environnements d’exécution pour agents n’existent que depuis à peine plus d’un an, et cela fait seulement environ six mois qu’ils sont devenus assez fiables, pourtant la fatigue est déjà forte. À mon avis, cela montre moins si les LLM peuvent réellement programmer que l’épuisement mental de la programmation assistée par IA
  Pour suivre correctement ce que l’agent fait à la base de code, il faut prendre des décisions plus fréquemment et lire une quantité astronomique de code et de prose
  Cette fatigue personnelle et psychologique, ainsi que les émotions négatives qu’elle suscite, se transforment de manière imprécise en vision pessimiste du potentiel d’évolution de la technologie elle-même

  • https://evilmartians.com/chronicles/ai-assisted-engineers-ar...
  • La technologie n’existe pas indépendamment de la manière dont les gens l’utilisent
    Si tous ceux qui l’utilisent correctement finissent frustrés, et que ceux qui l’adorent produisent des montagnes de bric-à-brac impossibles à maintenir, alors nous finirons bientôt par la jeter dans les poubelles de l’histoire
    Beaucoup de choses ont du « potentiel », mais nombreuses sont aussi celles qui, au final, ne deviennent rien
    Je continuerai à utiliser les LLM, mais à mon avis, l’utilité du codage de type agentique a déjà atteint son sommet

• Une partie de mon travail consiste à trouver comment rendre ces modèles productifs dans le grand groupe où je travaille. C’est un peu comme lancer des tomates contre un mur, et je constate aussi, dans une certaine mesure, ce qu’il décrit : les sorties semblent avoir certaines limites intrinsèques
  En même temps, nulle part dans son texte il n’y a de morceau de code ou d’élément concret auquel on puisse se raccrocher en disant : « le modèle a été catastrophique ici, et voilà ce qu’il aurait dû faire ». Cette manière de critiquer ressemble à un schéma qui se répète dans les billets de blog et les posts Twitter du type « les LLM, ça ne marche jamais »
  Les modèles font clairement mieux que de l’autocomplétion, et dans mon développement quotidien ils produisent de larges pans de codebase du niveau de ce qu’aurait pu faire un ingénieur junior ou intermédiaire
  Si personne ne cite concrètement les erreurs qu’ils font réellement, comment peut-on évaluer leurs capacités réelles ?

  • Les erreurs des LLM sont assez subtiles. Coder avec un LLM, c’est comme une scène de Whiplash. « Ce n’est pas mon tempo », « downbeat au 18e temps », « tu vas trop vite », « plus lentement »
    Ils produisent presque toujours du code qui fonctionne, et font en général ce qu’on leur demande. Mais c’est légèrement faux d’une manière incroyablement frustrante, au point de donner envie de jeter une chaise. Et en plus ils n’ont même pas le goût nécessaire pour voir ce qui cloche et comment
  • Quand des gens écrivent des billets de blog montrant qu’un LLM a échoué sur une tâche précise, la réaction des défenseurs est presque toujours : « utilise un autre modèle », « reformule le prompt comme ça », « ton niveau est insuffisant ; on ne peut pas tirer une conclusion générale sur l’IA à partir d’un cas particulier »
    Donc on ne peut ni donner un exemple concret, ni ne pas en donner. Dans ce cas, la partie est terminée
    Je sais bien que je commets une erreur d’attribution au groupe, mais je le pense quand même
  • C’est précisément ce point qui est excellent. Même du point de vue d’un débutant qui réalise grâce aux LLM des projets qu’il n’aurait jamais pu imaginer auparavant, on en vient à chercher des exemples et des preuves de ce que l’agent écrit exactement de travers et de la manière dont un humain ferait mieux
    Ce type de ressource doit exister, donc si quelqu’un connaît du contenu qui montre de bons exemples, j’aimerais qu’on me l’indique
    Je ne doute pas que les tout meilleurs codeurs écrivent bien mieux que Claude ou Codex. Mais je me demande à quel point ils sont moins bons qu’un développeur moyen tout à fait ordinaire
  • Ce billet présente des exemples assez détaillés, avec jusqu’à des extraits de code montrant une mauvaise architecture : https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

• À mon avis, les modèles vont continuer à s’améliorer
  Quand j’ai commencé le coding agentique il y a un ou deux ans, j’étais convaincu que ça ne servait guère plus qu’à l’autocomplétion. Puis quelque chose s’est produit au début de cette année, et les modèles ont atteint un nouveau palier de capacités
  Maintenant, tout le monde autour de moi fait du coding agentique, et c’est vraiment impressionnant. Je pense qu’il faut pousser ça aussi loin que possible. On a l’impression d’avoir l’accélération de l’humanité juste sous les yeux

  • On se heurte déjà à quelques limites logistiques. Même s’il n’existe pas de plateau de capacité intrinsèque aux Transformers, les GPU et l’électricité disponibles pour progresser restent limités, et il y a de grandes difficultés à faire monter cette infrastructure à l’échelle
    Environ 6 GW de nouveaux datacenters ont été annoncés ces deux dernières années, mais moins de 1 GW a réellement été mis en service. Le calendrier de livraison du reste continue de glisser
    Et les datacenters parlent comme si les puces qu’ils contiennent allaient tenir six ans, mais cela aussi commence à se révéler intenable
  • Et si nous étions en train d’accélérer droit dans un mur ?
  • « l’accélération de l’humanité » est l’auto-consolation la plus grandiose que j’aie vue cette année
  • Oui, quelque chose s’est passé. L’autocomplétion s’est améliorée. Quoi d’autre ? Les modèles de base n’ont pas changé
    J’aimerais qu’on arrête avec ce genre de discours sur « l’accélération de l’humanité ». Personne ne résout le cancer, le changement climatique, les inégalités ou d’autres problèmes réels importants avec les LLM
    Si cette technologie est assez bonne pour augmenter ta productivité, c’est justement parce que tu ne fais rien de nouveau, de pointe ou d’innovant. La seule raison pour laquelle un LLM sait faire ton travail, c’est que ce code a déjà été littéralement écrit suffisamment de fois pour apparaître en masse dans les données d’entraînement
    Essaie d’écrire du C++26, du HDL, ou une stack très niche avec un LLM, et tu auras vite un retour à la réalité

• Ce n’est pas AFL qui a trouvé plus de vulnérabilités que les LLM. Ce sont AFL et des praticiens expérimentés qui ont trouvé ces vulnérabilités
  AFL provoque des défauts, et une part significative, voire la plupart, n’est pas exploitable. Il faut qu’un humain — et désormais peut-être un agent — fasse le tri et l’évaluation
  Et en plus, ce travail s’effectuait sur un corpus de logiciels non memory-safe datant d’avant AFL. L’âge d’or d’AFL, c’était il y a dix ans ; aujourd’hui toutes les cibles sont devenues plus difficiles

• Pour ajouter du contexte, l’auteur est George « geohot » Hotz. Il a un long historique d’exploits, et il est probablement surtout connu pour avoir quasiment créé comma.ai pour les voitures autonomes en mode vibe coding, avec peu de moyens, bien avant l’arrivée du véritable vibe coding IA
  https://en.wikipedia.org/wiki/George_Hotz