La méthode de codage IA « en laisse courte » qui bat Fable

• Pour utiliser des agents de codage IA sur des logiciels où la sécurité est critique, il faut une approche Short Leash où le développeur garde en permanence le contrôle des modifications, plutôt que de déléguer une exécution autonome
• Une approche de type « vibe », où plusieurs agents produisent et relisent le code en parallèle, peut affaiblir la compréhension de la base de code et faire en sorte que les problèmes ne soient découverts qu’une fois l’IA partie off the rails
• La procédure centrale enchaîne planification, découpage en étapes, revue des diffs dans les invites d’autorisation, refus et interventions fréquents, commits par sous-tâche, puis revue finale
• Dans les revues de PR, combiner IA et humains permet de réduire davantage les erreurs : l’IA repère vite les fautes courantes, tandis que les humains jugent les problèmes de plus haut niveau et la direction à suivre
• Pour une PR à laquelle l’IA a contribué, son auteur doit tout relire lui-même ligne par ligne et indiquer dans la description de la PR, via une section AI Disclosure, le modèle utilisé afin d’instaurer la confiance

---

Pré requis pour utiliser des agents de codage IA

• Cette méthode s’appuie sur une expérience concrète d’utilisation d’agents IA pour produire des logiciels de haute qualité dans des systèmes critiques pour la sécurité
• Elle ne s’adresse pas aux développeurs débutants, qui devraient considérer l’IA comme un obstacle à l’apprentissage, mais à des développeurs experts meilleurs que les « frontier AI models » dans leur domaine de spécialité
• L’objectif est d’utiliser l’IA comme outil d’amélioration de la productivité sans sacrifier la qualité du logiciel
• Le retour d’expérience couvre l’exploration des limites des agents IA, la création d’un outil interne de revue IA, ainsi que la maintenance d’un fork personnalisé de l’agent de codage IA Crush

Là où l’approche « vibe » vacille

• Lors d’une session avec des agents IA, deux problèmes reviennent souvent
  • l’idée de départ est mauvaise et l’on découvre trop tard qu’une meilleure approche existait
  • l’agent part dans une direction non souhaitée et se retrouve off the rails
• Quand plusieurs agents parallèles et un orchestrateur travaillent en même temps, et que le développeur est sorti de la boucle pendant le codage, il devient difficile de construire soi-même une compréhension directe de la base de code
• Dans un contexte où la qualité importe peu, cette méthode peut convenir, mais quand la qualité est essentielle, une autre approche est nécessaire
• Le code écrit ou relu par Fable 5 peut fonctionner tout en restant inefficace et peu esthétique
• Dans des domaines de niche avec peu de données d’entraînement sur lesquelles le modèle peut s’appuyer, ces problèmes peuvent être plus fréquents
• Contrairement au marketing de certains CEO, ce point de vue considère que les modèles ne peuvent pas raisonner au-delà de leurs données d’entraînement

Comment fonctionne l’approche Short Leash

• L’approche Short Leash n’est pas une méthode pour tout le monde ; elle est pensée pour des développeurs logiciels experts
• Son avantage est de pouvoir obtenir de meilleurs résultats que Fable sans même utiliser de frontier model
• Avant de commencer, on passe par une phase de planification pour étudier la tâche et établir un plan
  • Les gros travaux sont suivis et découpés en étapes avec des outils comme tasks skill
  • Sur ce point, elle rejoint plusieurs approches de « vibe engineering »
• L’essentiel ensuite est de garder en permanence l’IA en laisse courte
  • ne pas utiliser le mode « YOLO » ni « dangerously skip permissions »
  • ne pas laisser l’IA travailler seule pendant que l’utilisateur joue à un jeu
  • utiliser un agent de codage qui affiche le diff des modifications prévues dans les invites d’autorisation
  • le développeur analyse réellement les changements proposés par l’IA
  • les diffs des invites d’autorisation servent à garder une compréhension à jour de la base de code et à conserver le contrôle sur l’IA
  • si l’IA tente une action non souhaitée, l’autorisation est refusée
  • intervenir souvent quand c’est nécessaire pour éviter que l’IA perde la bonne direction
• À la fin de chaque sous-tâche, on crée un commit afin d’éviter que l’IA n’abîme ou ne supprime un travail précédent
  • cela peut réellement arriver, et des cas ont été observés avec Opus
• L’étape finale consiste à effectuer une revue

La revue IA ne remplace pas la revue humaine

• Les PR relues à la fois par des humains et par une IA permettent de réduire davantage les erreurs que celles relues uniquement par des humains ou uniquement par une IA
• L’IA peut être utilisée comme un linter
  • elle repère rapidement les erreurs courantes
  • les humains évaluent les problèmes de plus haut niveau et la nécessité éventuelle de changer de direction
• Il est recommandé que toutes les PR passent par une revue IA
• Une revue IA a besoin d’un contexte suffisant
  • l’issue
  • la description de la PR
  • la base de code
  • les changements
• Il est recommandé d’utiliser, pour la revue, le modèle le plus récent disponible

AI Disclosure et responsabilité du soumissionnaire

• Si une IA a été utilisée pour rédiger une PR, le modèle exact employé doit être indiqué dans une section AI Disclosure de la description de la PR
• Cette divulgation a plusieurs objectifs
  • informer les mainteneurs qu’une IA a été utilisée
  • permettre de suggérer un meilleur modèle si un modèle faible a été utilisé
  • montrer qu’il ne s’agit pas d’introduire de l’IA en douce
• Toute PR utilisant l’IA doit impérativement être relue par son auteur
• Une PR assistée par IA est en pratique plus proche d’une PR d’IA aidée par un humain ; le soumissionnaire doit donc comprendre ce qu’il soumet
• Le soumissionnaire doit relire sa PR lui-même, line-by-line, comme s’il s’agissait de la PR de quelqu’un d’autre
• Une fois cette auto-revue terminée, il peut confirmer sa propre approbation et demander la revue d’un mainteneur
• Ce processus sert à construire et à démontrer la compréhension de la base de code par le soumissionnaire

Comment okTurtles applique cette méthode

• okTurtles utilise l’IA de cette façon
• La politique officielle est décrite dans l’AI Usage Policy
• Le texte lui-même a été écrit par un humain, avec seulement une correction orthographique de style IA avant publication, comme l’indique son AI Disclosure

[GN⁺]

Avis sur Hacker News

• Cette méthode de « laisse courte » ressemble moins à un outil d’assistance qu’à une béquille, et donne l’impression qu’on n’a pas assez bien expliqué le problème à l’IA dès le départ, ou qu’on n’a pas relu et itéré sur ses sorties.
  Tenir par la main un modèle puissant comme Fable pendant l’implémentation est une perte de temps, et un gaspillage de Fable. Plus un modèle est puissant, plus on peut avoir avec lui des discussions de conception subtiles, et il écrit du code bien meilleur qu’avant. Discuter de la conception et de l’implémentation, poser des questions sur ce qui paraît étrange, et réellement lire les réponses de l’IA aide en soi à trouver de meilleures solutions.
  Par le passé, alors que j’essayais de produire une solution avec un algorithme glouton, une discussion avec Opus m’a amené à la suggestion qu’une bibliothèque MILP existante permettait de résoudre exactement le problème ; je n’avais même jamais entendu parler de MILP, mais l’implémentation finale a été meilleure et plus simple que si je l’avais faite seul.

  • On dit qu’il est possible d’avoir des discussions plus subtiles avec les modèles puissants, mais quand j’ai demandé à Claude pourquoi il avait fait une petite modification que je ne comprenais pas, il a répondu qu’il avait « raisonné à partir des premiers principes » en se basant sur les chemins du code.
    Sauf que ça ne marchait pas, et quand je lui ai demandé d’expliquer ces étapes de raisonnement à partir des premiers principes, il a fini par répondre qu’en réalité il les avait simplement inventées. Donc j’ai du mal à croire à cette idée de discussion subtile avec le modèle.
  • Je suis globalement d’accord.
    Si l’on a suffisamment investi dans la phase de planification et que l’architecture et les conventions existantes du projet sont solides, il n’est pas forcément nécessaire de superviser autant l’implémentation que ce qui est décrit ici.
    Le fait que « l’idée initiale était stupide et qu’on peut découvrir une meilleure méthode » se découvre généralement à haut niveau, pendant la phase de planification et d’architecture.
    Le problème des agents qui « déraillent » dans une direction non souhaitée n’est plus aussi grave qu’avant, et toute modification à impact devrait avoir au moins une couverture de tests minimale. Même si ces tests ne font que « figer » le comportement implémenté. La discussion finale de revue est une bonne occasion de vérifier davantage que ce qu’une review, ou un agent de review adversarial, a déjà trouvé.
  • Je ne suis pas tout à fait sûr de la partie avec laquelle tu es en désaccord. Lire les réponses de l’IA et relire le code me semblent finalement relever de la même approche.
    L’exemple du MILP n’est pas quelque chose que cette approche empêcherait, et serait apparu pendant la phase de planification.
    Au bout du compte, les détails comptent, et la façon dont on formule le prompt de départ influence le résultat. Mais vérifier les sorties, rester impliqué dans ce que fait le modèle et lui demander pourquoi il veut construire les choses de cette manière reste indispensable.
  • L’article donne l’impression de micromanager l’IA. Si on la considère comme un employé junior, le micromanagement peut effectivement permettre de lui faire faire ce qu’on veut, de la manière qu’on veut.
    Mais ses idées n’arrivent jamais sur la table, et les contributions qui pourraient être bénéfiques à long terme pour toute l’équipe disparaissent aussi.
  • C’est comme ça que je l’utilise.
    Cela me permet de comprendre tout ce qui est généré et de conserver en permanence une connaissance opérationnelle de la base de code. Je peux aussi la faire changer de direction facilement.

• J’ai procédé ainsi pendant deux semaines sur un projet perso, mais j’ai fini sans modèle mental de la base de code.
  Cela m’a encore davantage convaincu qu’il n’y a pas moyen de construire ce modèle sans l’avoir faite soi-même.

  • Malheureusement, j’avais déjà le même problème avant l’IA.
    À cause de la courbe de l’oubli, mon modèle mental ne dure pas beaucoup plus longtemps que la période pendant laquelle je l’ai construit au départ. Je n’ai pas encore trouvé comment le reconstruire.
  • Comment un manager d’un gros projet construit-il ce modèle ? Dans une situation où son rôle exige de comprendre l’ensemble du projet, mais sans nécessairement écrire ni relire beaucoup de code.
  • Il suffit de demander au modèle d’expliquer le code.
  • Je ne sais pas trop. Je pense que c’est possible, mais il faut creuser volontairement les parties qu’on ne comprend pas, et c’est ça la consigne.
    Cela dit, je suis d’accord pour dire qu’on ne développe pas vraiment la même « capacité à le construire soi-même » que lorsqu’on l’a écrit directement.
    Par exemple, je sais quels changements faire pour obtenir tel effet, et quand je les fais effectivement, j’obtiens le résultat attendu, donc je sais que mon modèle mental fonctionne. Mais si je devais construire quelque chose de similaire depuis zéro, je ne pense pas que j’y arriverais. J’ai l’impression que l’approche reste hors de ma portée, mais c’est difficile à expliquer.
  • La revue de code me convient bien.

• Je pensais que les gens qui savent vraiment coder utilisent tous l’IA de cette façon pour les choses importantes.
  Je me trompe ? Tout le monde lance simplement le mode YOLO ces temps-ci ?

  • Oui. J’ai un ordinateur portable dont je me fiche, sur lequel je laisse Claude bidouiller librement dans WSL.
    C’est le plaisir du funemployment. Quand je reprendrai le travail, ça devrait être un changement assez intéressant.
    Pour l’instant, je le laisse tourner, puis je bois une bière pendant environ une heure en ajoutant une critique à haut niveau et une nouvelle boucle d’autocontrôle/feedback en boucle fermée, puis je le relaisse faire ce qu’il veut. C’est assez simple.
  • Par « mode YOLO », c’est-à-dire « ignorer dangereusement les permissions », c’est bien de ça qu’il est question quand on dit de ne pas l’utiliser ?
    Je suis curieux de savoir comment utiliser Claude autrement qu’avec bypass-permissions. J’ai longtemps maintenu une liste d’outils que Claude pouvait utiliser, mais à chaque fois que je revenais, il s’était arrêté parce qu’il avait essayé de piper la sortie d’un outil vers un autre et que ce n’était pas explicitement autorisé. Même pour quelque chose comme grep, ça m’agaçait qu’il s’arrête.
    Avec bypass-permissions, « ça marche, tout simplement ». Bien sûr, je ne m’en sers que pour analyser le code existant et proposer des changements ; si quelque chose casse, c’est bien pour ça qu’on a le contrôle de version.

• Je suis globalement d’accord avec l’auteur. J’ajouterais surtout : ne faites confiance à rien de ce que fait ou dit un LLM.
  Aujourd’hui, j’ai demandé à Claude d’unifier le comportement de 3 composants, et je lui ai fait faire 5 fois. À chaque fois, à la fin, il restait encore des incohérences, et Claude trouvait un moyen de les rationaliser.
  Quand je lui demandais, il répondait « c’est ma responsabilité » ou « je pensais que c’était un choix intentionnel », mais il n’a jamais, pas une seule fois, commencé par poser des questions sur ce qu’il fallait faire ou signaler le problème. Donc il faut le tenir en laisse courte, regarder son processus de réflexion et corriger ses bêtises immédiatement. C’est valable aujourd’hui avec Sonnet 5 ; demain, ce sera peut-être mieux ou pire. La façon de parler qui fonctionne avec Claude aujourd’hui peut produire un résultat différent demain.

• Le problème avec les articles du type « comment faire X avec l’IA », c’est que chaque situation est différente. Par exemple, faire passer un projet Symfony de 3.1 à 8.1 suit un chemin clair
  Il suffit de suivre les guides de migration rédigés pour chaque version majeure, puis de tester toutes les routes, les flux d’authentification, etc. Ces tests peuvent aussi être sélectionnés manuellement, certains pouvant renvoyer 200, d’autres 302
  On peut aussi, en option, écrire d’abord un filet de sécurité pour réduire les tests manuels, et poser par exemple une baseline PHPStan
  Si les routes fonctionnent de bout en bout comme prévu sur le plan fonctionnel, c’est terminé. On peut aussi utiliser des tests par snapshot pour cela
  Dans ce genre de cas, il n’est pas nécessaire de surveiller l’IA. On peut relire le code à la fin, mais il n’y a pas besoin d’approuver manuellement chaque étape, donc je désactive les fonctions de sécurité

  • Ce n’est pas tant un problème des « comment faire X avec l’IA » qu’une question de manière de consommer du contenu sur Internet
    La plupart des gens écrivent depuis un point de vue donné, mais les points de vue réels sont beaucoup plus larges, et ce qui marche dans une situation ne marche pas dans une autre. Au fond, tout le génie logiciel consiste presque à comprendre quoi appliquer, où et quand, et à ignorer le reste
    Beaucoup d’articles de blogs d’entreprise donnent l’impression qu’il existe une balle d’argent valable dans tous les cas, mais ce n’est généralement pas vrai
    Au final, comme cela a toujours été le cas en génie logiciel, c’est plutôt « certaines choses fonctionnent dans certaines situations » ; ce n’est pas tant une question de vrai ou de faux que d’applications concrètes différentes selon le contexte, et c’est normal
  • Tu as essayé rector ?

• L’IA est du niveau d’un ingénieur junior à intermédiaire. Si on la traite comme telle, on peut obtenir à la fois les avantages du vibe coding et ceux d’une ingénierie rigoureuse, sans toute cette paranoïa
  Dès le départ, j’ai fait tourner Claude en mode YOLO dans une VM isolée. C’est comme donner son propre ordinateur portable à un ingénieur. Claude amène une fonctionnalité jusqu’au point où elle peut faire l’objet d’une PR, puis je relis le diff comme je le ferais pour un autre ingénieur, je remets le tout dans la forme appropriée et je passe à la suite
  Les ingénieurs inexpérimentés font les mêmes erreurs. J’ai déjà vu des rm -rf, même si ce n’était pas à la racine. Si j’avais micro-managé quelqu’un en lui refusant toutes les permissions, je pense que je serais devenu fou

  • Je suis fortement d’accord avec ce point de vue, et c’est pourquoi je comprends encore moins cet article. La PR n’est-elle pas déjà le point de passage obligé ? Peu importe ce que l’agent fait ou non dans l’espace de travail, tant que sa contribution est filtrée par le dépôt git et que le développement ne nécessite pas d’accès bizarre à la production, je ne m’en soucie pas
    Je suis aussi d’accord avec l’analogie de l’ingénieur junior/intermédiaire, mais avec une grosse réserve. L’IA ressemble à un ingénieur junior qui ne sait pas apprendre
    C’est comme travailler avec le protagoniste de Memento. Chaque jour, quand le LLM arrive au travail, il n’a rien appris de tout ce qui a été fait jusque-là, et chaque jour est son premier jour
    Bien sûr, comme avec le protagoniste de Memento, on peut l’aider en disséminant des post-it et des rappels partout dans l’espace de travail. Avec des efforts, on peut se rapprocher de quelque chose qui ressemble à de « l’apprentissage », mais c’est littéralement la qualité la plus importante chez tous les développeurs logiciels d’une équipe
    Mais ce n’est pas facile, et les outils manquent encore. Le mieux que j’aie réussi à faire ressemble à un « second cerveau » avec des outils comme Obsidian. Malheureusement, je pense qu’un second cerveau ne remplace pas le premier. Honnêtement, un ingénieur incapable d’apprendre et de progresser comme un agent IA aurait été licencié après son premier mois dans toutes les entreprises où j’ai travaillé
    Cela dit, je suis assez optimiste sur le fait que les grands fournisseurs d’IA, ou quelqu’un d’autre, amélioreront ce point à l’avenir. Avec une bonne mémoire, combinée à un système de raisonnement bien conçu qui injecte mieux les souvenirs selon le contexte, et capable de capter un véritable apprentissage sans supervision, cela ne me semble pas impossible
    Je lis ce genre d’articles en espérant que quelqu’un ait déjà résolu ce problème et que je n’aie plus qu’à m’en rendre compte avec retard, mais pour l’instant je suis simplement un peu meilleur qu’au début pour concevoir des agents
  • Mon expérience est la même. Je le vois plutôt comme un stagiaire très intelligent et très rapide. On voit qu’il ira loin, et il est déjà bien meilleur que moi sur beaucoup d’aspects, mais il faut encore la main d’une personne expérimentée pour l’orienter
    Ma règle empirique, c’est que tout processus spécial créé pour l’IA doit aussi être pertinent pour les humains ; sinon, il n’a pas de valeur. De bons outils en ligne de commande, la synthèse automatique de longues sorties de commandes, la documentation Markdown et les workflows sont aussi utiles aux humains
    Pour éviter les erreurs et les abus, il faut utiliser des sandboxes et des permissions à portée limitée, pas du micro-management
    Ce que je cherche à comprendre, c’est un bon workflow de pair programming avec un agent IA. On peut confier de gros travaux à un modèle performant, et ça marche bien. On peut aussi utiliser un modèle de niveau inférieur comme assistant dans l’IDE, et ça marche bien aussi. Mais ce sont deux workflows distincts
    Ce qui serait vraiment utile, ce serait de construire quelque chose avec un modèle performant en se passant le clavier. Mais il ne faudrait pas qu’il tourne en mode YOLO complet sur ma machine. C’est là que se situe la différence entre un humain et un LLM. Il est tellement rapide que, quand il déraille, il est difficile de lui reprendre le clavier
  • Si tu donnes un vrai ordinateur portable à Claude, il peut aussi réparer les problèmes d’audio Bluetooth sous Linux ;)
  • Quelle VM / quel provisionnement utilises-tu ?
  • Dire que « l’IA est un ingénieur junior à intermédiaire » n’est plus vrai, et se bercer de cette illusion n’aide pas
    Personne ne sait exactement ce qu’est l’IA, mais ce n’est pas un ingénieur junior ou intermédiaire. C’est plutôt un staff engineer nucléaire vivant dans une cabane, sans contexte métier et qui se réveille toutes les 5 heures sans mémoire

• Les LLM restent des prédicteurs du prochain token. Le fait qu’ils trouvent les bonnes étapes même avec des consignes plus vagues ne signifie pas qu’ils sont intelligents. Cela signifie que tu parles le même langage que le harnais utilisé pour entraîner le modèle.
  Et cela a ses limites. Si tu restes au niveau de la preuve de concept ou d’une application simple, tu ne vois peut-être pas à quel point les modèles actuels restent limités. Dans ces cas-là, il faut découper le travail, pas faire confiance à un prédicteur de tokens qui aligne des étapes plausibles.
  Il doit forcément y avoir un humain dans la boucle quelque part. Si tu commences à contourner les autorisations, dans le meilleur des cas tu touches le jackpot, mais le scénario le plus probable, c’est une solution sous-optimale et du gaspillage de tokens. Le vrai risque, c’est que le modèle ignore les consignes, fasse une bêtise et te ruine la journée.
  C’est tranchant comme une machine CNC. Ce n’est pas inutile, mais ça peut être dangereux. Si tu ne sais pas faire un créneau, mieux vaut éviter de vouloir sculpter du bois avec une machine monstrueuse ou de garer une Ferrari dans un quartier exigu.

  • La prédiction du prochain token n’est pas un algorithme, c’est une interface. Le processus qui consiste à « prédire le prochain token » peut être arbitrairement complexe ou simple, et sa capacité à accomplir une tâche donnée peut être aussi élevée ou faible que l’on veut.
    Dire qu’un LLM peut ou ne peut pas faire quelque chose parce que c’est un « prédicteur de tokens » est une erreur de catégorie. L’interface n’est pas une limite dure.
  • Je ne sais pas comment tu définis l’intelligence dans « ce n’est pas de l’intelligence ».
    Je me demande comment on peut proposer une définition qui exclut les modèles de langage mais inclut les humains, sans partir de l’axiome selon lequel les LLM n’ont pas d’intelligence.
  • Dans ce cas, toi aussi tu es juste quelqu’un qui dit le mot suivant.
  • Qualifier les LLM de prédicteurs du prochain token est totalement réducteur et de mauvaise foi. Techniquement, c’est vrai, mais c’est aussi ton cas.
    En général, ce qu’on veut dire par là, c’est qu’ils « ne font que prédire le prochain token des données d’entraînement, c’est-à-dire d’Internet », ce qui peut être vrai pour les modèles bruts. Mais les modèles passent par un post-entraînement, donc même cette description n’est plus exacte.
    Dire que « ce n’est pas de l’intelligence » n’est pas utile et, à mon avis, c’est faux. Qui se soucie de savoir si cela correspond à ta définition de l’intelligence ? Ils accomplissent quand même des choses impressionnantes, et même des choses bien plus fortes que ce que tu sous-entends.
  • À partir de quel seuil dirais-tu que c’est intelligent ?

• L’article original donne encore l’impression d’être resté en 2025.
  Il dit que « l’IA déraillera plusieurs fois et on ne s’en rendra compte qu’en essayant vraiment le logiciel », mais désormais cette IA peut utiliser directement le logiciel, trouver et corriger des bugs, et même pousser de nouvelles fonctionnalités.
  Il arrive encore que des agents se mettent à faire des choses non désirées, mais beaucoup moins qu’avant, et l’argument en faveur des agents entièrement autonomes ne s’affaiblit pas, il se renforce.
  Dire qu’« il est humainement impossible pour quelqu’un de comprendre une codebase » paraît aussi dépassé. À mon avis, on va vers un monde où les humains n’ont plus besoin de comprendre la codebase, et où l’IA mène la danse.

  • Les entreprises d’IA ont intérêt à pousser ce slopmaxxing imprudent. Le résultat final, c’est que ton business dépend entièrement d’elles, et que toute la valeur de ton produit vient aussi d’elles.
    Beaucoup de gens montent dans ce train, mais je vois ça comme une mode stupide.
  • Exact, comprendre quelque chose, c’est tellement 2025.
  • Cela peut être vrai pour des logiciels non critiques, comme dans le divertissement ou les médias.
    Mais ce n’est absolument pas vrai pour des systèmes à forts risques de sécurité. Dans la banque, l’aviation ou la défense, l’IA apportera certainement sa contribution, mais elle ne fonctionnera pas indépendamment de la compréhension d’ingénierie humaine.
  • Toute personne ayant un assez bon sens de la programmation efficace et de l’architecture ne serait pas d’accord avec l’idée que l’IA utilise directement le logiciel pour trouver des bugs et créer des fonctionnalités.
    La méthode de la laisse courte est un moyen de garantir de bons résultats quand on travaille hors des données d’entraînement. Même un programmeur à peine meilleur que la moyenne verrait, je pense, que c’est la seule façon de garantir un développement rapide et de qualité avec un LLM.
    Dire que les humains n’ont plus besoin de comprendre la codebase semble venir d’une méconnaissance du monde de la programmation, où l’IA reste encore catastrophiquement maladroite. Je la vois régulièrement rater la gestion mémoire dans des langages avec gestion manuelle de la mémoire. Ce n’est pas aussi simple que de la mettre dans une boucle Valgrind.
  • Je n’ai pas l’impression que l’argument en faveur des agents entièrement autonomes se renforce. Voici ce qui m’est arrivé il y a quelques semaines avec Claude Code + Opus 4.8. La tâche n’était pas si complexe : quatre nouveaux endpoints d’API et des événements streamés vers le client via WebSocket.
    J’ai affiné à plusieurs reprises la définition de l’API, les modèles de requête/réponse, le schéma de base de données et le flux complet, et j’ai beaucoup supprimé de contradictions et corrigé la documentation moi-même. Opus déraillait sans cesse, et le document final dépassait 500 lignes.
    Il a aussi fallu faire plusieurs allers-retours sur les tests d’intégration de l’API. L’IA n’arrivait pas à créer directement les tests à partir du document ; elle a d’abord créé des placeholders avec des commentaires Given-When-Then, que j’ai relus et corrigés à la main, puis elle a implémenté les tests lors d’une deuxième itération. Il y avait beaucoup d’erreurs corrigées après review.
    À l’étape d’implémentation, je lui ai fourni la documentation d’API, des tests fonctionnels, des hooks bloquant les modifications, plus de six compétences de « bonnes pratiques », des agents « rubber duck » et « simplification du code », ainsi que des scripts pour vérifier les tests, le linter et les erreurs de compilation. Après planification, exécution, review et plusieurs corrections, la fonctionnalité a été implémentée et tous les tests passaient.
    Lors de la review du code, je trouvais en moyenne un problème toutes les 20 lignes de code. Même en excluant le style, il y avait l’utilisation de sémaphores en mémoire dans un service Kubernetes, huit appels à la base de données pour mettre à jour le même enregistrement au cours d’une seule requête, des mises à jour colonne par colonne, des lectures-modifications-écritures sans transaction, ainsi que des erreurs de logique métier, de récupération et d’autorisation.
    Au final : presque une semaine de travail, plus de 100 dollars de tokens, et seulement la question « est-ce que cet effort en valait la peine ? ». Je gère une équipe de deux développeurs, et je viens de relire la PR de l’un d’eux : 80 % était du slop.

• J’ai essayé une approche similaire, mais elle ne m’a pas vraiment convenu. Le gain de vitesse était faible, voire inexistant. Pour gagner en productivité, je pense qu’il faut un certain mode YOLO dans un sandbox.
  L’objectif devrait être d’externaliser autant de travail que possible au modèle, tout en minimisant l’effort nécessaire pour comprendre et relire le résultat.
  Par exemple, confier au modèle la recherche de la cause d’un bug, la création d’une preuve de concept de X, l’optimisation progressive de quelque chose, ou un refactoring bien défini avec un guide.
  Ce que les gens appellent créer une boucle est très similaire : maximiser ce que fait le modèle, et minimiser ce que je dois faire pour le contrôler.

• L’article n’avait pas grand-chose à dire

  • Il ne faisait que reprendre la formule à la mode du moment
    L’an dernier, c’était « l’IA n’est qu’un perroquet stochastique »
    Cette année, c’est « l’IA peut écrire du code, mais les humains doivent encore le relire ! ». Bien sûr, on utilise aussi l’IA pour cette relecture
    Dans un an de plus, le récit deviendra : « la revue de code ne peut être faite que par l’IA, et seule l’IA peut relire la revue de l’IA. Les humains n’ont qu’à lire l’avis final de l’IA pour conserver une supervision significative »
    Les poteaux de but bougent sans cesse, mais les certitudes, elles, ne bougent jamais