Utiliser l’IA pour écrire du meilleur code, plus lentement

• Le coding avec l’IA ne sert pas seulement à générer rapidement de grandes quantités de code de mauvaise qualité, mais peut aussi être utilisé pour examiner des PR en profondeur et produire lentement du code de haute qualité
• Les agents LLM excellent dans la détection de bugs dans une base de code, mais la vraie difficulté réside dans la priorisation et la vérification des problèmes détectés
• Une skill Claude qui combine plusieurs modèles utilise un sub-agent Claude, Codex et Cursor Bugbot pour relire les PR et produire un rapport final réduisant les faux positifs
• Le flux de traitement consiste à corriger de façon itérative les problèmes critical/high, à ignorer les éléments dont le bénéfice est faible au regard du coût, et à abandonner la PR si elle contient trop de problèmes critiques
• Cette approche privilégie la santé de la base de code plutôt que la vitesse, et renforce une programmation prudente qui comprend les modes d’échec et les bugs existants

---

Une façon lente de faire du coding avec l’IA

• Considérer le coding avec l’IA uniquement comme un moyen de produire rapidement en masse du code de mauvaise qualité sous-estime la flexibilité des LLM
• Les LLM peuvent être utilisés efficacement non seulement pour générer du code rapidement, mais aussi pour écrire du code de meilleure qualité plus lentement
• À l’opposé d’approches qui déversent de grosses PR non vérifiées comme les slop cannons, il est aussi possible d’examiner les PR plus en profondeur et de traquer avec ténacité les scénarios d’échec

Validation et priorisation, plus importantes que la détection de bugs

• Mythos montre que les agents LLM peuvent très bien trouver des bugs dans une base de code
• D’autres cas montrent également que des modèles autres que Mythos peuvent trouver de nombreux bugs dans des bases de code non relues
• Les derniers modèles publics d’Anthropic et d’OpenAI diffèrent dans leur capacité à détecter des bugs subtils et à éviter les faux positifs, mais ils peuvent en trouver un nombre suffisant
• La vraie difficulté, plus encore que la découverte des bugs elle-même, tient à la priorisation et à la vérification

Une skill Claude qui relit les PR avec plusieurs modèles

• L’approche de revue de code par IA qui compare et fait débattre plusieurs modèles met l’accent sur l’idée que plus on mobilise de modèles différents, plus on réduit les risques d’hallucination ou de rapports de bugs erronés
• La skill Claude utilisée exécute Claude sub-agent, Codex et Cursor Bugbot pour relire les PR
• Chaque outil classe les bugs d’une PR en critical/high/medium/low, puis les résultats sont consolidés pour produire un rapport final d’où les faux positifs ont été retirés
• La notion de « bug » peut être élargie selon les critères du projet
  • violations des principes KISS et DRY
  • qualité de rédaction d’un HTML/JSX accessible
  • usage d’index appropriés dans les requêtes SQL
  • autres critères de qualité propres au projet

Workflow réel et critères de décision

• Cette méthode permet de trouver beaucoup de bugs dans une PR, tout en ramenant le taux de faux positifs à un niveau proche de zéro
• Les problèmes détectés vont de bugs critiques liés à la sécurité ou à la justesse à des problèmes de performance, jusqu’à des remarques de faible gravité du type « ce commentaire induit en erreur »

• Flux de traitement habituel

  • les éléments classés critical et high sont corrigés par l’agent, tandis qu’un humain indique la solution appropriée
  • on répète jusqu’à disparition des éléments critical/high
  • les problèmes high/medium dont le bénéfice est faible par rapport au coût de correction sont ignorés
  • le cas typique est celui où 100 lignes de code sont nécessaires pour corriger un edge case très étroit
  • s’il y a trop de problèmes critiques et que l’approche globale est jugée erronée, la PR est abandonnée

Une priorité donnée à la santé de la base de code plutôt qu’à la productivité

• Cette technique n’accélère pas nécessairement la vitesse de développement
• Au cours de la revue, des bugs préexistants à la PR peuvent être découverts, ce qui peut mener à l’écriture de tests unitaires et à la correction de défauts subtils
• C’est presque l’inverse d’un développement de type « productivité multipliée par 10 », souvent associé au « vibe coding »
• Dans les architectures complexes, les modes d’échec sont parfois plus intéressants que le chemin nominal, et comprendre puis corriger ces points de défaillance peut devenir une manière d’apprendre la base de code
• Cette approche est utile pour améliorer la santé de l’ensemble de la base de code tout en découvrant des zones peu connues

Conseils pratiques pour un vibe coding lent

• Si vous êtes un développeur qui utilise un agent pour produire des PR de plusieurs centaines de lignes que vous ne comprenez pas totalement vous-même, vous pouvez essayer une approche plus lente
• Vous pouvez demander à l’agent comment la PR fonctionne et où elle peut échouer
• Si nécessaire, vous pouvez lui faire rédiger un document Markdown incluant des diagrammes Mermaid
• Vous pouvez utiliser la skill /grill-me de Matt Pocock jusqu’à comprendre la PR de bout en bout
• La « productivité » mesurée au nombre de lignes de code n’augmentera pas forcément, et vous pouvez conclure, après avoir consommé beaucoup de tokens, que le plan initial était mauvais
• Cette méthode ressemble davantage à une version renforcée d’une programmation prudente, méthodique et obsédée par la qualité qui était déjà visée avant l’arrivée des LLM

[GN⁺]

Commentaires sur Lobste.rs

• Au travail, on a renoncé au rêve d’aller plus vite avec l’IA. Dans notre cas, le code n’est pas le goulot d’étranglement
  Cela dit, ce qui est bien avec les agents de code, c’est qu’ils me permettent de travailler comme l’ingénieur que j’ai toujours voulu être
  Par exemple, mettre en place un vrai harnais de test qui permet de pousser un peu plus le code, ajouter une étape de CI qui vérifie que le code généré correspond à la source, ou surveiller correctement les déploiements de changements
  Avant, c’étaient des choses impossibles à caser dans le planning, parce qu’il aurait fallu lire le manuel de GitLab CI, comprendre comment satisfaire les conditions et démêler la façon tordue dont notre entreprise fait les choses. Maintenant, c’est devenu possible, et je pense que c’est ça, l’avenir

• J’ai eu pas mal de succès en utilisant les LLM comme partenaire de spike qui connaît l’API ou comme outil de refactorisation mécanique, surtout dans les langages fortement typés. C’est aussi utile pour écrire des tests, mais il faut une procédure à plusieurs niveaux pour vérifier que ces tests imposent réellement des contraintes
  Le mutation testing m’a bien aidé, et comme le suggère l’article d’origine, plusieurs passes de relecture sont aussi nécessaires
  Avant, j’étais bien plus négatif vis-à-vis des LLM, et avec le recul c’était presque irrationnel, mais c’était surtout à cause du logiciel de mauvaise qualité qu’ils produisaient à la chaîne
  En creusant moi-même, j’ai compris qu’il fallait plutôt les traiter comme un outil de prototypage en carton et comme un dactylo beaucoup plus rapide. Par exemple, si je dis « trouve ce motif dans tous les théorèmes de ce projet Lean, remplace-le par cet autre motif, et indique-moi les cas qui ne passent pas directement avec la liste de ce qu’il reste », il me corrige plus de 100 théorèmes par chunks dans le temps qu’il me faudrait pour faire un ou deux premiers essais en bricolant avec vim, sed, awk et des rustines
  Avec Lean, c’est particulièrement bien parce que, du fait des caractéristiques du langage et du type de travail que je fais, l’écart entre « ça compile » et « ça fonctionne » est faible. En Rust aussi, avec une bonne suite de tests et du mutation testing, j’ai une sensation comparable
  À long terme, le vrai potentiel de ces outils n’est pas « j’appuie sur un bouton et un produit sort », mais plutôt qu’un bon ingénieur les adopte pour concentrer son énergie sur l’essentiel et déléguer à la machine une bonne partie des corvées d’avant

  • Moi aussi, au début, j’étais très négatif vis-à-vis des LLM, mais maintenant je pense qu’ils se sont améliorés au point d’aider plus qu’ils ne gênent
    L’exemple est intéressant : quand je travaillais dans une équipe de framework JavaScript, j’écrivais moi-même des codemods pour gérer les montées de version ou les migrations. C’était le travail pénible de modifier des AST
    Aujourd’hui, j’aurais probablement tendance à le confier à un LLM en me disant qu’il atteindrait 90 % du résultat

• J’aime bien cette façon de voir les choses. Il semble évident qu’un outil est flexible et n’a pas nécessairement à produire des résultats médiocres, mais aussi bien les partisans que les opposants oublient souvent ce point de vue
  Je n’ai pas encore essayé de faire de la revue de code avec des LLM, mais je devrais l’ajouter à ma liste. Jusqu’ici, je m’en suis surtout servi pour générer des idées, m’aider avec du SQL ou du VimScript, et j’écris le code moi-même
  Un risque, c’est que la revue de code est aussi une compétence, donc si on s’appuie trop sur le modèle, cette capacité peut s’atrophier. Cela dit, dans un environnement commercial, même la meilleure revue de code repose généralement sur une combinaison de « temps raisonnable » et de « est-ce que je fais confiance à cette personne », pas sur quelque chose qui se rapproche de la rigueur mathématique

  • C’est vrai aussi, mais j’ai plutôt l’impression que ce flux de travail a renforcé mes compétences en revue de code. Parce qu’il faut juger si le « bug » est réellement possible ou seulement théorique, s’il vaut la peine d’être corrigé, ou s’il faut le repousser à la PR suivante
    Pour les bugs complexes, j’ai tendance à aller jusqu’au bout moi-même, parce que 1) il y a encore des hallucinations qui se glissent dedans, et 2) de toute façon, cela vaut la peine de comprendre le système de bout en bout

• Petite remarque méta, mais je ne comprends pas les flags sur cet article. Un hors-sujet et trois spams, c’est bizarre
  L’article tout en haut de la première page parle lui aussi de l’usage des LLM, et comme il traite d’écriture en général, il me semble encore moins dans le thème que celui-ci qui est centré sur le code, pourtant il n’a apparemment pas été signalé

  • J’imagine que certains l’ont signalé comme autopromotion, d’où le spam

• C’est rafraîchissant de voir ce point de vue sur Lobsters. Le sentiment anti-IA uniforme devient de plus en plus fatigant. Je pense qu’on peut tous s’accorder sur le fait que personne n’aime les résultats de mauvaise qualité
  Mais ceux qui boycottent complètement l’IA et adoptent une posture dogmatique auront plus de mal à accepter l’avenir que ceux qui choisissent une approche plus pragmatique
  Depuis le début, je dis que l’IA ressemble à l’invention des outils électriques. Si on préfère changer un pneu avec une clé à main, très bien, mais quand la perceuse à choc est arrivée, les mécaniciens ne l’ont pas boycottée. Ce n’est pas la meilleure analogie dans le contexte de l’article, mais je continue à penser que c’est vrai
  J’ai plus appris en utilisant l’IA qu’en lisant de la documentation, parce qu’on ne peut pas poser des questions à la doc quand on a besoin de plus de contexte, d’explications ou d’exemples. On peut aussi lui dire « fabrique quelque chose, ne te trompe pas », mais je préfère une approche plus lente pour réellement apprendre

  • Je n’ai pas vu ici de sentiment anti-IA uniforme. Tu pourrais donner des exemples ?
    Ce que j’ai vu, c’était surtout des critiques envers des changements où des millions de lignes de code sont modifiées d’un coup avec des LLM puis déployées sans revue humaine. Concrètement, par exemple, dans le fil sur le portage de Bun de Zig vers Rust
    Et cet article critique aussi cela