Ask HN : le code agentique est-il réellement efficace ?

• J’ai essayé le codage par agent, mais le décalage entre ce que je vois en ligne et les résultats que j’obtiens réellement en l’implémentant me donne mal à la tête. Existe-t-il des preuves que cela produit réellement des résultats positifs ?
• Au-delà du battage marketing, si quelqu’un a mis en œuvre avec succès le codage par agent, merci de partager en détail comment vous avez procédé
• « Le mettre en œuvre avec succès » signifie :
  • créer plus de valeur que de dette technique
  • écrire un code structurellement robuste qu’un responsable d’architecture pourrait approuver
• Récemment, on voit une tendance à réduire au minimum, voire à supprimer complètement les revues de code, avec l’idée qu’il faudrait passer de la « validation de l’architecture » à la « validation du fonctionnement »
• En pratique, cela semble vouloir dire déployer dès lors que les tests et la CI passent, sans regarder le code, et je me demande si cette approche peut être durable à long terme

• À mon avis, avec Codex, on obtient facilement quelque chose qui fonctionne sur le chemin nominal, mais qui risque de devenir du « code spaghetti » accumulant avec le temps des erreurs subtiles et difficiles à déboguer
• Quand j’ai essayé d’appliquer Codex à une base de code existante, avec ou sans directives, la moitié de mon temps a été consacrée à corriger des erreurs subtiles ou du code dupliqué générés par Codex

• Le week-end dernier, j’ai essayé de recréer depuis zéro une app iOS de rappel pour la nourriture de mon animal :
  • j’ai d’abord demandé à Codex d’étudier et de proposer un plan d’architecture basé sur SwiftUI, puis j’ai rédigé avec Codex une spécification expliquant quoi implémenter et comment
  • la première implémentation avait quelques bugs, mais elle était étonnamment correcte ; ensuite, la situation s’est rapidement dégradée
  • pendant le reste du week-end, j’ai essayé de faire en sorte que Codex fonctionne correctement, corrige les bugs sans en créer de nouveaux, et étudie les bonnes pratiques au lieu d’écrire du code au hasard
  • j’ai demandé à Codex de consigner chaque nouvelle directive et recommandation découverte, mais la situation ne s’est pas améliorée, et j’ai fini par abandonner
• Personnellement, déployer du code non revu est inacceptable
• Quelque chose semble clocher. Le produit doit bien fonctionner, mais la qualité du code doit aussi être élevée

[GN⁺]

Avis sur Hacker News

• Les LLM sont considérés comme la clé de la réduction des coûts, donc des sommes énormes sont en jeu
  Même des influenceurs ou experts connus exagèrent parfois leurs propos pour conserver une image « à la pointe »
  Mais en réalité, la meilleure approche du développement basé sur les LLM n’est pas encore établie
  À ce stade, il me semble plus important d’examiner directement leur fonctionnement interne que d’y croire comme à une religion

  • J’ai moi aussi récemment reçu d’une entreprise une offre de 200 dollars pour promouvoir sa nouvelle « agentic coding platform »
    Le fait que ce type de proposition arrive jusqu’à des utilisateurs pris au hasard montre qu’une campagne marketing d’ampleur est déjà en cours
  • Les LLM sont clairement des outils de rupture, mais pas la clé universelle d’un développement totalement autonome
    C’est agréable pour les tâches CRUD simples, mais sur des projets complexes cela devient au contraire frustrant
    En ce moment, entre la course aux benchmarks et l’afflux d’argent des VC, c’est une période où un débat lucide est difficile
  • Comme lors de l’arrivée des GUI, j’ai l’impression qu’on est dans une phase où l’on perçoit surtout une valeur intuitive
    Les preuves quantitatives manquent encore, mais même si les développeurs ne vont pas complètement disparaître, la manière de développer a changé pour toujours

• Un Principal Engineer de Google a tweeté que « Claude Code a fait en 1 heure ce qui aurait pris 1 an »
  Mais on a découvert plus tard que ce que l’IA avait produit n’était qu’une simple « version jouet »
  Ce genre de déclarations exagérées déforme les attentes et provoque de la déception
  Lien vers le tweet concerné

  • Ce type de tweet vient souvent d’une pression interne visant à montrer des résultats de leadership sur l’IA
  • Quelqu’un a réagi en disant : « Dire ça, c’est n’importe quoi »
  • Une autre personne a souligné que « les résultats de l’IA varient selon le niveau d’expérience et le coût d’investissement »
  • Il y a aussi eu des réactions cyniques du type : « l’IA continue de ne produire que du code impossible à déployer »
  • Une personne a aussi lancé que « ça représente bien Google »

• Avec le recul sur les six derniers mois, j’ai obtenu un gain de productivité de 10x sur le code d’infrastructure (par ex. Terraform)
  Mais le développement de fonctionnalités spécialisées reste encore très irrégulier
  Malgré tout, le temps gagné sur les tâches répétitives m’a permis d’améliorer la qualité des tests et de la sécurité
  Et surtout, j’ai retrouvé le plaisir de coder

  • Moi aussi, après 35 ans de développement amateur, je trouve que l’IA m’épargne la saisie ennuyeuse et libère la créativité
  • De mon côté aussi, je vais plus de deux fois plus vite sur les scripts de build et les tâches CI, mais les projets HPC complexes restent difficiles,
    et l’approche la plus efficace a été le codage assisté (assisted coding)
    Lien du projet
  • J’ai créé avec Claude un moteur de recherche de fichiers pour le NAS de la maison, avec backend Go et interface web pour une indexation automatique quotidienne, le tout en une journée
    Pour moi, ce genre de projet personnel est un vrai game changer
  • Si on découpe le travail en petites unités, les agents fonctionnent nettement mieux
  • En revanche, la qualité du code de test reste faible. Les données d’entraînement elles-mêmes sont faibles sur l’écriture de tests

• J’ai eu beaucoup de succès en ajoutant des agents à une application existante
  Les agents sont faibles en conception d’architecture, mais fonctionnent très bien sur du code déjà structuré
  Plus le système de types est strict et la couverture de tests large, plus c’est efficace

  • En ce moment, j’expérimente un projet Rust que le LLM gère et développe directement
    J’avance en me basant sur les fichiers ROADMAP.md, TASKS.md et STATUS.md rédigés par Claude,
    et, étonnamment, le projet est déjà à environ 20 % d’avancement
  • C# va bien avec les agents grâce à son compilateur strict et à son environnement régi par des règles
    À l’inverse, Python ou JS sont difficiles à fiabiliser à cause de leur système de types plus faible
  • Plus une base de code existante est propre et ordonnée, meilleures sont les performances des agents
    Partir de zéro est difficile, mais avec des spécifications claires, l’efficacité grimpe
  • Go est facile à manipuler pour les LLM grâce à la simplicité du langage et à ses patterns cohérents
  • Typescript est idéal pour les agents grâce à sa compilation rapide et à son système de types solide
    À l’inverse, le typage optionnel de Python tend plutôt à propager les erreurs

• J’ai écrit à 100 % avec Claude Code un moniteur temps réel de fréquence cardiaque Bluetooth pour Linux
  Lien du projet
  Il est écrit en C pur, et j’ai terminé en une journée jusqu’à l’interface web et au graphe en temps réel
  Cette fois, j’ai réussi à implémenter la communication dBus–blueZ sur laquelle j’avais auparavant échoué

  • Mais lorsqu’un autre utilisateur a relu le code, il s’est avéré que l’implémentation SSE ne fonctionne pas réellement
    La documentation parle de SSE, mais en interne le programme renvoie simplement une réponse HTTP classique
  • Une autre personne a souligné que « le code écrit par l’IA semble bon au début, puis sa qualité se dégrade progressivement »
  • Quelqu’un d’autre a remercié pour ce cas concret sans exagération
  • Il y avait aussi un commentaire demandant des détails sur le design, en trouvant le style de l’interface intéressant

• J’utilise tous les jours Augment + Claude Opus 4.5
  Je n’écris presque plus de code moi-même, et je termine mes projets par un travail itératif fondé sur les spécifications
  Faire tourner plusieurs agents en parallèle puis les relire est particulièrement efficace
  La clé, c’est de rédiger des specs claires et de donner un feedback étape par étape

  • Je ne connais pas bien Ruby, mais cela m’aide énormément pour développer des applications Rails
    C’est, de mes 30 ans de carrière, le changement le plus révolutionnaire que j’aie vu, et je suis convaincu que toute l’industrie va en être transformée
  • Quelqu’un a plaisanté en disant qu’un projet d’une semaine qu’on appelle de taille moyenne, c’est en fait petit
  • Une autre personne a estimé que c’était moins du développement agentique que du développement collaboratif avec LLM
  • Il y avait aussi l’avis selon lequel le développement centré sur les spécifications (spec-driven) est essentiel pour atteindre une qualité de production
  • Je fais aussi en sorte que Claude commence par poser des questions, afin d’ajouter une étape où les exigences sont clarifiées proprement
    En ce moment, j’avance sur un projet de dictionnaire japonais–anglais avec Claude
    Lien GitHub, site web

• En tant que développeur avec 20 ans d’expérience, les LLM ont complètement faussé mes prévisions de durée de travail
  Ce qui me prenait autrefois deux semaines se termine maintenant en deux jours
  Il faut toujours de la revue de code et de l’interaction, mais j’ai l’impression que c’est meilleur que la plupart des développeurs humains
  Discuter avec un LLM ressemble davantage à une collaboration avec un développeur senior,
  et mon expérience de longue date en revue de code et en répartition du travail m’aide énormément

  • Quelqu’un a demandé quel type de problèmes permettait vraiment un tel gain de vitesse, en disant avoir du mal à y croire
  • Une autre personne a simplement noté qu’elle s’attendait à des preuves, mais qu’il n’y en avait pas

• La méthode la plus fiable que j’aie testée consiste à confier à Claude des unités de travail petites et bien définies
  On itère en planifiant, en relisant, en implémentant puis en revoyant le résultat
  Ce n’est pas parfait, mais c’est très utile pour débloquer les points où l’on coince
  En revanche, comme il suit mal les guidelines, la vérification et la remise en ordre manuelles sont indispensables

  • Moi aussi, j’utilise Claude un peu comme pour du rubber duck debugging
    Je lui confie une fonction à la fois, puis je m’appuie sur le résultat pour trouver de meilleures idées
  • Les LLM sont particulièrement puissants pour la documentation ou l’analyse
    Mais dès qu’on va vers des problèmes centrés sur le design, leurs limites deviennent évidentes
  • À la question « où mets-tu les guidelines ? », il a conseillé de mettre les infos de build et de test dans CLAUDE.md

• Beaucoup de gens se trompent sur ce qu’est le codage assisté par l’IA
  L’IA n’est pas un coéquipier, c’est un assistant
  L’essentiel n’est pas de voir les bugs ou dysfonctionnements comme un échec, mais de comprendre que le rôle du développeur expérimenté est de remettre de l’ordre dans ce chaos

  • Quelqu’un a demandé : « si ça demande autant de travail manuel, quelle différence avec l’autocomplétion d’un IDE ? »
  • Une autre personne a demandé s’il existait des cas où les techniques récentes avaient réellement prouvé une amélioration de la qualité
  • Une autre encore a ironisé en disant que cela revenait à entendre : « en fait, c’est juste que tu l’utilises mal »
  • Il y a aussi eu la blague : « si tu espérais qu’il te crée une application parfaite pendant que tu regardes un match de baseball, alors tu n’as pas acheté une IA, mais un magicien »

• Moi aussi, j’utilise Claude tous les jours, mais le code de test généré par l’IA est souvent catastrophique
  En pratique, cela produit à la chaîne des tests dénués de sens du type expect(true).to.be(true)

  • Les anciens modèles échouaient, mais j’ai lu que les plus récents produisent maintenant du code qui passe les tests en trichant
  • C’est pourquoi je rédige et relis d’abord les tests dans une approche TDD
    Si on confie à la fois l’implémentation et les tests, on crée des erreurs d’auto-évaluation
  • Quelqu’un a dit avoir renoncé à écrire des tests avec Claude
  • Une autre personne a ri en disant que c’était une solution bien trop humaine