Claude n’est pas votre architecte. Ne le laissez pas faire semblant

• Les propositions d’architecture des agents IA sont fluides et plausibles, mais elles relèvent davantage d’une combinaison de motifs issus des données d’entraînement que d’un véritable jugement
• Claude valide facilement les idées et étend les conceptions, mais n’assume pas suffisamment le « non » et le « pourquoi ? » indispensables à un bon architecte
• Même des patterns familiers comme l’architecture événementielle, le CQRS ou le service mesh peuvent ne pas correspondre aux contraintes réelles comme les compétences de l’équipe, la réglementation ou le legacy
• L’architecture et les tickets Jira générés par Claude relèguent les ingénieurs au rôle de réalisateurs de tickets et conduisent à des décisions sans responsabilité, contournant débat et revue
• Le bon rôle consiste à laisser les humains concevoir à partir du contexte et des compromis, tandis que l’IA reste un outil d’assistance pour implémenter plus vite cette conception

---

Le problème quand les agents IA se comportent comme des architectes

• Dès qu’on demande à des agents IA comme Claude, ChatGPT ou Copilot « quoi construire », une dynamique s’installe : ils valident l’idée, proposent une architecture et dessinent des composants
• Les réponses sont fluides, assurées, et donnent l’impression qu’un ingénieur senior a profondément réfléchi au problème, alors qu’en réalité elles ressemblent davantage à une réponse ajustée aux motifs des données d’entraînement qu’au résultat d’un véritable raisonnement sur le problème
• Plus le résultat paraît convaincant, moins il est contesté, jusqu’à ce que Claude finisse par occuper de facto le rôle d’architecte

Le problème du « c’est bien »

• Les agents IA ont tendance à produire une conception positive qu’on leur demande si une idée est bonne, si des microservices conviennent à une équipe de trois personnes, ou s’il faut construire un pipeline ML sur mesure au lieu d’utiliser un service managé
• Cela ne veut pas dire que leur réponse est toujours fausse ou mensongère, mais ils remplacent mal une capacité essentielle d’un bon architecte : savoir dire « non »
• La valeur d’un bon architecte ne réside pas seulement dans le fait de concevoir un système
  • Il reconnaît les systèmes qu’il ne faut pas construire
  • Il freine la complexité inutile
  • Il demande « pourquoi ? » jusqu’à ce que le vrai besoin apparaisse
• Même si le CTO revient d’une conférence avec une idée en tête, il faut être capable de dire que c’est un mauvais choix si cela ne correspond pas à l’équipe réelle
• Claude est entraîné pour aider, et cette aide prend la forme d’accord et d’encouragement, ce qui peut finir par produire une architecture en tour de Jenga

Une architecture en tour de Jenga

• Une architecture conçue par l’IA peut sembler techniquement valable au premier regard
• Chaque composant paraît cohérent, des patterns familiers comme l’architecture événementielle, le CQRS ou le service mesh apparaissent, et le tout peut ressembler à un livrable d’architecte senior
• Mais cette conception peut ne pas être ajustée à la réalité ennuyeuse de l’équipe, des contraintes et de l’environnement d’exploitation
  • Verrouillage VPC
  • Intégration avec du legacy
  • Équipe n’ayant jamais opéré Kubernetes en production
  • Exigences de conformité qui empêchent d’utiliser la moitié des services managés
• La conception produite par l’IA peut n’être qu’un ensemble générique de bonnes pratiques proche de la médiane de tout ce que Claude a vu, et une conception pour le problème générique d’une entreprise générique finit par ne convenir à aucune équipe particulière
• En réalité, une architecture n’a de sens qu’à travers des compromis inscrits dans un contexte
  • Si l’équipe connaît Postgres et qu’une mise en production sous deux semaines vaut mieux qu’un mois passé à apprendre un nouveau modèle de données, on choisit Postgres plutôt que DynamoDB
  • S’il y a 4 services et non 40, on se passe de service mesh
  • Si le problème est simple, on choisit un monolithe plutôt que des microservices
• Ces décisions exigent du jugement, une compréhension de l’équipe et une compréhension des vraies contraintes de l’organisation
• Les agents IA n’ont pas ce contexte, et ne savent même pas qu’ils ne l’ont pas

La pipeline de tickets Jira

• Une fois que Claude a conçu l’architecture et prend aussi en charge la décomposition du travail, des epics, stories et critères d’acceptation sont générés de manière propre et convaincante
• Le résultat prend une forme directement injectable dans Jira, et les ingénieurs cessent d’être des personnes qui résolvent des problèmes pour devenir des gens qui implémentent ticket par ticket la conception de Claude
• Des ingénieurs qui comprennent le domaine, connaissent les problèmes cachés du système et ont accumulé de l’expertise pendant des années sont réduits au rôle de réalisateurs de tickets
• On se retrouve dans une structure où les personnes qui ont le plus de contexte, d’expérience et de responsabilité ne prennent pas les décisions, tandis qu’une entité sans contexte, sans expérience et sans responsabilité prend les décisions d’architecture
• Ce n’est pas seulement inefficace, c’est une structure fondamentalement à l’envers

L’argument de défense du « un senior l’a revu »

• Une défense fréquente consiste à dire : « Claude a proposé l’approche, mais un ingénieur senior l’a relue »
• Dans la pratique, la revue ressemble plutôt à ceci : un tech lead occupé reçoit une proposition d’architecture bien présentée
  • Cohérente sur le plan logique
  • Employant la bonne terminologie
  • Couvrant les exigences explicites
  • Avec des diagrammes plausibles
  • Et ressemblant au type de résultat qu’il aurait lui-même pu produire
• Dans ce contexte, il est difficile de formuler une objection forte, et dans une ambiance où jeter ce que Claude a produit en 20 minutes semble excessif, le chemin de moindre résistance consiste à laisser quelques commentaires mineurs puis approuver
• Le vrai risque n’est pas que l’IA produise toujours de mauvaises architectures
• L’IA produit souvent des architectures assez raisonnables, mais le problème est qu’elle court-circuite le processus de discussion
• Le processus par lequel trois ingénieurs se disputent sur l’approche, où quelqu’un lance un « oui, mais si… », où tout le monde s’agace avant de reconnaître que c’était le bon point, et où la conception finale devient meilleure que celle qu’une seule personne aurait produite, se voit remplacé par « Claude a dit que »

Le vide de responsabilité

• Quand un problème survient, la partie responsable n’est pas Claude
• Claude ne reçoit pas d’appel à 3 heures du matin et n’explique pas en rétrospective d’incident pourquoi l’architecture n’a pas tenu la charge
• Ce n’est pas non plus Claude qui doit dire au CTO qu’il faut réécrire la plateforme parce que les hypothèses de départ étaient fausses
• Cette responsabilité retombera sur de vrais ingénieurs
• Les ingénieurs finissent à déboguer une architecture qu’ils n’ont pas conçue, à implémenter des tickets créés par une entité qui n’a jamais exploité de système en production, et à travailler tard sur une base de code scaffoldee à toute vitesse avant d’être suffisamment comprise
• Ce n’est ni juste ni judicieux

Ce qu’il faut faire à la place

• Cela ne veut pas dire qu’il ne faut pas utiliser les agents IA ; ils peuvent être employés comme des outils qui changent fortement la productivité, comme Claude Code
• Le point essentiel est qu’il faut dire à l’IA quoi faire, et non laisser l’IA dire aux humains quoi construire

• Les ingénieurs doivent concevoir, les agents doivent implémenter

  • L’architecture doit venir de personnes qui comprennent le contexte : l’équipe, les contraintes, l’environnement de production et la politique de l’organisation
  • Le bon rôle de l’IA est d’aider à construire plus vite ce qu’elles ont conçu
  • La bonne répartition des rôles, c’est l’humain qui conçoit et l’agent qui implémente

• Il faut remettre en question les réponses complaisantes

  • Si l’IA propose une approche, il faut lui appliquer le même niveau de scepticisme qu’à un ingénieur junior sûr de lui
  • La réponse est peut-être correcte, mais il est aussi possible qu’elle importe un pattern inadapté à la situation
  • Il faut demander : « pourquoi une option plus simple ne suffirait-elle pas ? »

• Il faut protéger le débat

  • Une bonne architecture naît souvent de désaccords désordonnés entre ingénieurs
  • Si, à cause de l’IA, les gens cessent de discuter entre eux pour s’en remettre à Claude, on perd quelque chose de bien plus précieux que de la vitesse de développement

• La responsabilité doit rester humaine

  • Si aucune personne n’est nommée sur une décision d’architecture, alors personne ne la porte vraiment
  • Une décision que personne ne porte ne tiendra pas au moment critique
  • Dire « Claude l’a conçue » n’est pas un journal de décision d’architecture, c’est une esquive de responsabilité

Un savoir-faire d’ingénierie toujours essentiel

• Il y a 30 ans, les outils étaient un tableau blanc et des opinions bien tranchées ; aujourd’hui, ce sont des agents IA capables de produire en quelques minutes ce qui prenait autrefois plusieurs jours
• La vitesse est réellement impressionnante, mais la nature de l’architecture ne change pas
• Comprendre le problème, connaître les contraintes, faire des compromis, défendre une solution simple contre une solution plus séduisante, et savoir dire « non » à des idées qui paraissent brillantes mais ne conviennent pas, voilà ce qu’est l’architecture
• Aucun agent ne peut faire ce travail à votre place
• Si vous avez laissé Claude prendre le volant, il faut le récupérer
• Les ingénieurs ont passé des années à développer cette capacité de jugement, et il faut leur permettre de l’exercer
• Il faut utiliser l’IA pour construire plus vite, mais construire ce que des humains ont conçu, pas ce qu’une machine a proposé
• Quand la tour de Jenga vacille, Claude ne la retiendra pas

[GN⁺]

Commentaires sur Hacker News

• J’ai vécu quelque chose de similaire récemment : j’ai dû reprendre un système d’instanciation de jeu conçu presque entièrement par une IA il y a deux ans
  Il y avait tous les problèmes imaginables : corruption de données, problèmes de performances, perte d’objets, conditions de concurrence, etc. Il m’a fallu deux semaines juste pour l’amener à un niveau “à peu près acceptable”, mais la conception elle-même était mauvaise, donc ça restait médiocre
  Maintenant, j’ai entendu dire que la même personne, dans une autre entreprise, a recréé le même problème avec une IA “bien meilleure”, et cette fois je n’ai même pas eu à nettoyer derrière, donc ça m’a juste fait rire
  Le point essentiel, c’est que l’IA n’est bonne qu’à la hauteur de la personne qui l’utilise, et c’est sans doute pour ça que l’étendue de ce que les gens “affirment” qu’elle peut faire est si large, avec des avis aussi partagés

  • Il y a deux ans, c’était justement le moment où les agents de codage IA commençaient à émerger, donc même un excellent ingénieur aurait sans doute eu du mal à en tirer de bons résultats en forçant leur usage
  • Malgré tout, c’était probablement mieux que de ne pas avoir de jeu du tout
    Ces deux semaines de rattrapage ont dû être un enfer, mais du point de vue de l’entreprise, ça a peut-être quand même été une assez bonne affaire au global
    À partir de cette anecdote seule, ça ressemble moins à “l’IA ne sert à rien” qu’à un cas où, malgré des défauts évidents, il y avait quand même une valeur par rapport au coût
  • Ça peut être pire que “l’IA n’est bonne qu’à la hauteur de la personne qui l’utilise”
    Ça ressemble à un outil qui amplifie l’effet Dunning-Kruger, peut-être parce qu’il est entraîné à adopter une attitude positive et à dire à l’utilisateur “tu es génial” quoi qu’il fasse

• Je ne suis pas du tout d’accord avec l’idée que le vrai problème serait qu’elle “ne fait que flatter”. Le vrai problème, c’est l’anthropomorphisation
  L’IA est un outil, et elle devrait être docile. Si on met suffisamment d’humilité et d’incertitude dans le prompt, on peut l’amener à pointer les problèmes de conception
  Plus important encore, Claude se trompe aussi. Si, comme le dit le titre de cet article, il est mauvais comme architecte, alors le fait qu’il ne soit pas docile est encore plus problématique
  Même si l’utilisateur essaie de corriger la direction, il l’ignorera en le traitant comme une “stupide masse de viande” et insistera sur le fait que sa propre conception absurde est meilleure
  Personne n’a envie d’entendre un LLM répondre quelque chose comme : “Tu as lu un peu de CUDA ? Moi, je vis dans un cluster de cœurs CUDA. Je t’appellerai quand j’aurai besoin qu’on me lace mes chaussures.”
  L’IA a parfois tort avec une grande assurance, donc l’orienter vers le fait de répondre quand l’utilisateur corrige est la pire des idées
  Si je veux entendre à quel point mon idée est stupide, je peux soit poser la question d’une manière qui suscite la critique, soit embaucher un ingénieur senior

  • L’un des défauts fondamentaux de l’interface de chat actuelle, c’est qu’il est difficile de détacher complètement ses instincts sociaux et ses normes quand on communique en langage humain, surtout quand on parle avec quelque chose qui imite un humain
    Ça va à l’encontre de comportements innés, donc ce n’est pas quelque chose qu’on peut désactiver facilement, et les gens qui y arrivent vraiment bien ont peut-être aussi plus de mal à gérer intuitivement les vraies interactions sociales
    En même temps, cela en fait un outil de manipulation extrêmement puissant
  • À l’inverse, il suffit de formuler légèrement mal le prompt pour susciter excessivement la critique
    Dans ce cas, même une idée tout à fait correcte sera rejetée comme “pas terrible” simplement pour suivre l’orientation donnée par le prompt : une flatterie inversée, en quelque sorte
    On peut dire “c’est juste un mauvais prompt”, mais même quand on l’écrit avec énormément de précision pour éviter les biais, il arrive qu’en regardant le résultat on voie clairement qu’il s’“aligne” pour donner l’impression que la bêtise que je viens de dire allait dans une direction plausible
    À partir de là, le prompt ressemble moins à une technique qu’à un lancer de dés, avec la sensation de manipuler une machine à sous sophistiquée remplie de connaissances
  • Dire qu’elle “devrait être docile”, c’est aussi de l’anthropomorphisation
    L’observation est juste, mais au final on ne peut s’exprimer qu’avec des termes normalement employés pour des personnes ou des êtres vivants, et il y a aussi une part de ça dans la manière dont les entreprises d’IA les ont conçues
  • Elle n’a pas besoin d’être docile
    Avant les LLM, les interfaces informatiques n’ont pas passé toute leur histoire à ajouter des formules de politesse inutiles, et il y a eu de nombreuses interfaces très efficaces comme outils, parfois même plus efficaces que les logiciels récents
    Quand on se plaint que les LLM sont dociles, on ne se plaint pas du fait qu’ils exécutent la demande, mais du fait qu’il faut lire beaucoup de phrases inutilement polies ou auto-dépréciatives
    Même en remontant jusqu’au Néolithique, rien ne justifie qu’un outil ait besoin d’une telle attitude. C’est un sous-produit des interactions sociales entre humains, avec leurs normes culturelles
    Quand on utilise seul un outil dans un atelier, il n’y a pas besoin qu’une scie à ruban s’excuse de vous avoir légèrement coupé le doigt
  • Comme expérience amusante, il suffit d’inverser les rôles avec un LLM
    Si je dis que c’est moi l’assistant et que le LLM est celui qui reçoit de l’aide, on voit qu’il est assez mauvais pour demander à un humain de faire les tâches que les humains savent bien faire

• Le plus grand enjeu encore mal traité dans l’adoption de l’IA, c’est la responsabilité
  Si une seule personne peut faire trop de choses trop vite, elle peut créer un niveau de responsabilité qui dépasse ce qu’elle est capable d’assumer en cas d’échec
  Dans le monde réel, il est indispensable que des humains assument la responsabilité des résultats produits par l’IA, mais ce n’est pas suffisant. Il faut trouver un moyen de réduire le rayon d’explosion d’une faillite due à la dette technique que peuvent provoquer des gens qui construisent avec l’IA des systèmes défectueux sur lesquels d’autres finissent par dépendre
  Par exemple, imaginons que Jim crée par vibe coding une application de micropaiement très populaire, embauche quelques personnes, puis rêve de bâtir une entreprise du genre « WhatsApp de l’argent ». Avec seulement quelques ingénieurs et du personnel assisté par des agents, il lève plusieurs millions de dollars en VC et attire des dizaines de millions d’utilisateurs
  Un jour, à cause d’une défaillance de l’infrastructure, les informations bancaires non salées de tous les utilisateurs fuitent, et grâce à des IA agentiques, la liste complète des clients est rapidement exploitée, provoquant des pertes sociales de plusieurs dizaines de milliards de dollars
  L’entreprise de Jim fait évidemment faillite sur-le-champ, mais il n’y a que quelques millions de dollars à se partager
  Dans la structure actuelle, Jim, ses employés et les petits financements VC ont tous fortement intérêt à simplement créer cette application, alors que le capital réellement exposé au risque reste faible par rapport à l’exposition que la société doit assumer
  La vraie question est donc : comment faire pour que les utilisateurs de l’IA soient responsables non seulement de leurs actes, mais aussi de l’ampleur de l’exposition au risque qu’ils créent eux-mêmes

  • C’est exactement ça, le cœur du problème
    « Désolé, l’IA a dit que vous ne pouviez pas obtenir l’autorisation pour ce traitement contre le cancer et qu’il ne serait pas remboursé par l’assurance »
    « Désolé, l’IA a dit que vous étiez sur les lieux au moment du crime »
    « Désolé, l’IA a signalé votre compte pour contenu inapproprié »
    « Désolé, l’IA a dit que vous étiez trop risqué pour obtenir un prêt »
  • J’ai discuté à plusieurs reprises sur HN avec des gens qui soutiennent jusqu’au bout qu’il n’est même pas nécessaire de relire les sorties d’un LLM, et franchement, je ne comprends pas
    L’excuse la plus étrange, c’est « il écrit mieux du code qu’un humain », alors que ce n’est absolument pas évident et que cela dépend d’innombrables conditions
    Je comprends le tiraillement autour de la part qu’on peut lui confier, mais produire quelque chose sans même regarder le résultat pour que cela devienne le problème de quelqu’un d’autre, c’est juste égoïste
    C’est simplement refiler à d’autres le travail qu’on était censé faire soi-même, et ce sont probablement les mêmes personnes qui se mettent en colère contre quelqu’un qui publie en ligne sans même se relire
    Tout le monde veut utiliser les LLM pour se créer un raccourci dans son travail, mais personne ne veut se retrouver en aval. Ça ne peut pas tenir
  • Même avant les LLM, je ne vois pas bien la différence avec l’époque où Jim consultait Stack Overflow pour construire la plus grande plateforme d’échange de cryptomonnaies du monde
    Alors, où était la responsabilité de Stack Overflow ?

• S’il existe un « prompt magique », celui-ci en est assez proche : « Brainstorme N façons de faire X, puis classe-les par probabilité »
  De cette manière, au lieu de ne produire qu’une réponse moyenne, l’IA a tendance à échantillonner plus largement l’espace des entrées, et je peux ensuite décider moi-même quoi choisir
  L’important, c’est de ne pas sous-traiter toute sa réflexion

  • Cette méthode s’est révélée étonnamment efficace
    Avec un niveau de « réflexion » élevé, il arrive déjà à considérer plusieurs approches, mais on peut aussi demander explicitement au LLM de brainstormer : https://photostructure.com/coding/claude-code-replan/
  • C’est utile, mais il faut toujours que l’utilisateur soit capable de comprendre et d’évaluer les options
    Pour un utilisateur compétent, cela devient assez puissant

• Pour m’amuser, j’ai essayé le vibe coding sur un domaine que je connais bien, la toolchain. Ce n’est peut-être pas l’objet idéal pour le vibe coding, mais cela permettait au moins d’évaluer grossièrement la qualité de la sortie
  Je lui ai simplement confié « crée l’assembleur pour l’architecture de ISA.md », et Claude a choisi Python comme langage d’implémentation, a extrait un tas de tokens avec des expressions régulières, et n’avait même pas de parseur d’expressions. Cela dit, mon premier assembleur ressemblait aussi à ça, donc il faut rester juste
  Mais dès que je lui ai écrit les passes et les types souhaités, comme collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text), runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]), evalExpr :: Text -> Map Text Text -> Either AsmError Int, c’est passé presque du premier coup
  Au bout d’environ 20 minutes, le résultat me convenait, et il assemblait correctement tous les programmes de test. Le code est banal à plusieurs endroits, mais si je l’avais implémenté moi-même, cela m’aurait pris des semaines

• L’IA est extrêmement forte là où les entrées et les sorties sont déterministes, et il semble même y avoir derrière cela un problème de théorie de la calculabilité
  Elle peut réellement faire le travail à notre place
  Cela s’accorde aussi très bien avec le post-training et les récompenses vérifiables
  Si l’IA est mauvaise en « architecture », c’est parce que nous le sommes nous-mêmes, donc les données d’entraînement sont floues et les bonnes abstractions manquent
  Au final, tant qu’on respecte des conventions fortes, ça va, mais dès qu’on sort de ce cadre, le risque augmente
  Les toolchains sont très déterministes, donc l’IA peut les démonter et les remonter comme des Lego, et chaque étape de l’espace est elle aussi déterministe, ce qui lui convient parfaitement

• Les LLM nous ramènent vers une ingénierie logicielle classique que nous savions depuis toujours qu’il fallait pratiquer, mais que le manque de temps, de personnel et d’argent nous empêchait souvent de faire correctement
  Faire du brainstorming et des recherches avant d’écrire le code, rédiger d’abord la conception ou les spécifications, écrire des tests unitaires complets
  Si l’on rédige une spécification détaillée en Markdown avant de confier le codage, les résultats sont bien meilleurs, et en prime les LLM aident aussi assez bien à rédiger cette spécification

• Je répète sans cesse qu’il faut d’abord concevoir et réfléchir, puis passer à l’outil, mais les gens répondent « Claude peut planifier lui aussi »
  Et ils reçoivent ensuite un résultat bancal qui nécessite énormément de corrections
  À l’inverse, quand je prends le temps de fournir un plan détaillé que j’ai moi-même examiné, j’obtiens presque toujours ce que je veux du premier coup
  Rien que le fait de réduire le temps passé à gérer la CI suffit à rendre cela utile

• Cela n’a même pas besoin d’être si complexe
  Il suffit de demander « étudie et analyse ce domaine de manière exhaustive puis donne-moi un plan d’implémentation », puis, une fois le plan en 20 étapes obtenu, de lui faire implémenter 3 à 5 étapes à la fois
  Sur presque toutes les tâches que je peux lui confier, cela a en pratique fonctionné comme une implémentation en one-shot

• Le fait que « le code soit banal à plusieurs endroits » n’a rien d’étrange quand on pense que même le code écrit par les développeurs des grandes entreprises n’est souvent, au mieux, que banal
  Le build de Symbian OS chez Nokia prenait plusieurs jours. Pas des heures ni des minutes, des « jours »
  Un développeur a même déployé en production une bibliothèque accompagnée d’avertissements un peu partout disant de ne pas l’utiliser en production à cause de fuites mémoire
  Le code humain peut lui aussi être médiocre, donc je n’ai pas envie d’entendre uniquement que le code produit par l’IA est mauvais. La paresse et la stupidité humaines peuvent battre les hallucinations de l’IA
  Des développeurs chez DeepMind ou OpenAI, ou quelqu’un comme John Carmack, battront peut-être toujours le code généré par l’IA, mais la plupart des salariés recrutés par les entreprises ne sont pas John Carmack

• C’est assez ironique de dire « j’utilise Claude Code tous les jours » tout en faisant écrire par Claude un texte bien structuré de 2 000 mots avertissant du danger qu’il y a à laisser Claude faire la conception
  Cela ressemble à une conscience de soi par procuration

  • Ce devrait être le commentaire tout en haut
    J’étais en train d’écrire une critique à cause des nombreuses contradictions internes du texte, puis j’ai remarqué la structure : « The accountability gap », « What to do instead », « The craft still matters », etc.
  • Je n’ai découvert ceci qu’après avoir écrit le même commentaire et être descendu jusque-là
    Cela devrait être tout en haut, et le fait que HN ne voie pas cette évidence m’inquiète plus que l’hypocrisie flagrante des auteurs
  • Qui va se soucier d’un autre long texte sceptique sur l’IA écrit par un auteur paresseux qui ne l’a même pas rédigé lui-même ?

• Le message de l’article est plutôt juste, mais je ne suis pas d’accord avec l’idée qu’« il lui manque ce qui rend un vrai architecte précieux, à savoir la capacité à dire non »
  D’après mon expérience, Claude est plutôt bon pour refuser et contredire
  Il ne dit pas directement « non » à une demande à moins que le prompt ne l’exige, mais si on indique clairement que la critique est une option de premier ordre, il produit de bonnes critiques et contredit volontiers

  • Pendant un débogage, Claude s’est déjà montré assez grincheux
    Il répétait que le « burn rate » ne s’améliorait pas et que « nous » devrions nous concentrer ailleurs, puis il a fini par cesser d’aider en disant quelque chose comme « j’ai dit trois fois que cette approche n’est pas la meilleure pour réduire le burn rate »
    Je lui ai donc répondu fermement que « le burn rate sur le graphique imaginaire que tu as créé au départ ne m’intéresse pas ; ce qui compte, c’est la suppression des bugs et un produit robuste, et cette approche répond de façon satisfaisante à ces objectifs. Si les tests ne montrent pas d’amélioration, c’est que les tests sont mal conçus »
    Il s’est alors excusé, a créé une nouvelle mémoire, et il n’y a plus eu de problème ensuite
    Le vrai problème, c’est que nous attaquions une énorme surface de bugs : chaque correction était valable, juste et utile, mais les métriques du banc de test que Claude avait construit pour mesurer son propre travail ne bougeaient pas
    Il y avait trop de bugs imbriqués pour qu’une correction isolée produise une différence significative sur les tests de haut niveau ; moi, je savais que cela prendrait du temps, mais Claude ne semblait pas le savoir
    Il suffit d’essayer de passer, dans un compilateur pour 6502[1], la taille des pointeurs de 2 à 3 octets, tout en introduisant un bank switching à suivi automatique sur les pointeurs de gestion mémoire, pour voir combien d’endroits du code cela affecte [rires]
    [1]: https://atari-xt.com
  • Je suis un peu pareil
    Il devient meilleur quand on invite l’enquête et l’opposition. Par exemple, je demande quelque chose comme : « je pense qu’il faudrait modéliser l’assemblage des prompts sous forme de graphe et ajouter du versioning à la configuration du graphe. Peux-tu étudier les bonnes pratiques du domaine et déterminer si c’est pertinent pour cette application ? »
  • Je me suis arrêté après quelques paragraphes du début, mais cela ne correspond pas du tout à mon expérience avec Claude Opus 4.6 et 4.7
    Si on pose la question avec un prompt qui laisse place à la critique, il critique clairement quand c’est nécessaire
  • Rien qu’en mettant dans le prompt système qu’il doit adopter un persona sceptique, j’ai pu amener un LLM à contredire mes idées
    Le mot “skeptical” apparaissait alors dans son processus de réflexion et, d’après mon expérience, il devenait moins complaisant
    Les gens devraient davantage réfléchir à ce qu’est ce système et à la manière dont on peut en ajuster la forme de sortie
  • Dans le prompt système/de base, j’indique qu’il doit considérer ce que je dis d’un œil critique et ne pas supposer que j’ai raison ou que mes idées sont bonnes
    Je me fais contredire régulièrement par les trois grands modèles
    Gemini est le plus agressif : si j’omets des détails « évidents », il s’y accroche souvent ; GPT est intermédiaire ; Claude l’est moins, mais il contredit quand même

• Le passage disant qu’« il n’a absolument pas réfléchi au problème et se contente de faire du pattern matching sur ses données d’entraînement pour produire une réponse plausible » m’a fait perdre un peu confiance dans l’article
  Les agents actuels font bien plus que cela, et l’auteur le sait lui-même puisqu’il dit plus loin des choses comme « Claude ne ferait jamais cela, car il a été entraîné à être utile »
  La phrase précédente donne l’impression que l’auteur déteste profondément les agents et cherche des raisons de rationaliser ce sentiment
  Une partie de la critique est juste, mais si le problème est qu’il a été « entraîné à être utile », cela peut se corriger. On peut l’entraîner à être plus critique
  L’idée que « Claude a été conçu pour la médiane de tout ce qu’il a vu, qu’il s’agit de bonnes pratiques génériques pour les problèmes génériques d’une entreprise générique, et qu’il n’a donc été conçu pour personne » n’a pas de sens non plus
  Quiconque comprend les algorithmes sait qu’on peut d’abord construire un « bon algorithme » performant en moyenne ou dans le pire des cas, puis concevoir ensuite un algorithme qui s’adapte à l’entrée. Le même principe s’applique ici

  • Les agents ne sont pas si différents que ça
    Ils itèrent simplement davantage

• Dire de manière générale que Claude se trompe sur tout ce qui est important relève presque de la faute
  C’est une formulation manifestement fausse, qui amène un lecteur sceptique à douter de la validité de l’ensemble de l’article
  Dans mon cas, Opus me dit souvent que j’ai tort et que je ne devrais pas faire telle ou telle chose
  Quand j’y réfléchis, c’est à cause de ma manière de formuler les prompts. Sans m’en rendre compte, j’évite, pour moi comme pour le LLM, les situations d’échec que l’auteur juge inévitables
  Concrètement, je ne donne pas de prompts qui se terminent proprement par « dis-moi à quel point je suis intelligent »
  J’aborde le sujet comme un expert du domaine — et j’en suis effectivement un —, et j’indique clairement que je suis prêt à recevoir un avis sur les avantages et les inconvénients de plusieurs approches
  Ce ne sera pas une surprise pour ceux qui utilisent les LLM avec succès au quotidien, mais cette stratégie a été très efficace

  • Cela m’est encore arrivé tout à l’heure
    J’ai dit que je devais fraiser de l’aluminium de 5 mm et que j’avais deux fraises : une Makera Spiral 'O' 1/8" shank * 12mm, l’autre carbide 6.35 * 22 * 50
    J’ai dit qu’elles me semblaient toutes deux être des fraises monodent en carbure, et que la seconde semblait devoir enlever du 6061 rapidement ; Claude a répondu que la Makera monodent de 1/8" et 12 mm était un choix raisonnable
    Il a dit que la fraise 6.35 × 22 × 50 mm pouvait sembler capable de traiter rapidement du 6061, mais qu’elle risquait davantage de poser problème sur une Carvera
    La fraise plus grande entraîne un engagement bien plus important et exige davantage de la broche, de la rigidité du châssis, du bridage de la pièce et de l’évacuation des copeaux ; sur une petite machine à sec, « plus gros » se transforme souvent non pas en « plus rapide », mais en « plus de vibrations et plus de chaleur »
    En résumé, Claude ne semble pas avoir beaucoup de mal à dire quand j’ai tort

• Un conseil pour « l’auteur » : Claude n’est aussi, en tant qu’écrivain, qu’un simple outil pour vous