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 Hacker News

• En travaillant avec l’IA, ce n’est plus un simple processus en une seule passe, mais une longue boucle d’aller-retour de revue
  Pour des fonctionnalités de taille intermédiaire couvrant plusieurs domaines, je commence par faire définir la conception d’implémentation par l’IA, puis j’examine les détails avant de faire implémenter le tout par Claude 4.7 Max, plus lent mais meilleur en résultat
  Ensuite, je relis l’implémentation et je la fais de nouveau revoir par Codex GPT 5.5 xhigh fast, qui trouve presque toujours des cas limites. Je laisse Claude faire les corrections, car Codex est fort pour repérer les bugs et faire de la revue, mais son code a tendance à être surconçu ou à mélanger des raccourcis, tandis que Claude écrit un code plus intuitif et plus maintenable
  Après ça, je fais réexaminer les changements staged par une nouvelle instance de Claude/Codex, j’intègre le feedback, puis j’ajoute les tests. C’est toujours plus rapide que d’écrire à la main, mais la majeure partie du temps passe en revue et en traitement des cas limites, et au final une fonctionnalité v1 donne déjà l’impression d’une implémentation de type v3 ayant subi plusieurs itérations

  • Avant l’implémentation, il me convient bien de discuter du problème avec l’IA jusqu’à saturation
    On a l’impression d’être productif, les résultats de l’IA sont bons, et on garde en général une bonne compréhension du code. À force de passer la journée à débattre design et architecture avec des robots, j’ai le sentiment que c’est précisément là que la révolution de l’IA a fait de moi un meilleur ingénieur
  • C’est exactement ça. Trop de gens demandent à l’IA de tout traiter d’un coup sur des tâches complexes, puis s’étonnent qu’elle se comporte comme un junior à qui on a tout demandé dans l’urgence
    Ma méthode consiste à faire 5 tours de recherche/planification/plan de tests, en me mettant dans la boucle à chaque décision importante. Je pars de la forme globale puis je descends dans le détail ; la seule planification peut me prendre 2 à 3 jours, et l’agent d’implémentation (Opus 4.7) plusieurs heures
    L’implémentation est découpée en plusieurs étapes/commits, et chaque étape a sa propre boucle de correction après code review. La revue de code finale en profondeur peut aussi prendre 1 à 2 heures ; quand j’ouvre une PR, Gemini la relit et je lis ensuite ses remarques pour les traiter
    Les projets prennent toujours plusieurs jours ou plusieurs semaines, mais c’est malgré tout 5 fois plus rapide que de tout faire seul
    Ajout : cette skill est disponible sur https://github.com/scosman/vibe-crafting
  • Mon flux quand je code avec l’IA est assez similaire, mais même quand ça se passe bien, ça prend souvent à peu près autant de temps que de coder moi-même
    Dans certains cas, j’ai jeté ce que l’IA avait produit et je l’ai fait directement. Je pense que c’est une compétence que les gens doivent apprendre : à un moment, il faut savoir couper ses pertes. J’ai notamment vu des collègues continuer à se disputer avec un LLM pour lui faire faire quelque chose, même sur des changements simples
  • Approche similaire ici, mais je commence aussi par poser une architecture manuelle de base / contrat de haut niveau / stubs pour que ça reste cohérent avec le reste du système et plus facile à lire
  • Et quand Anthropic tombe en panne, tu attends juste en buvant un café ?
    À force de surveiller plusieurs IA pour aller un peu plus vite, est-ce qu’on ne perd pas en connaissance et en contrôle sur ce que l’IA a réellement fait

• L’article où des LLM critiquent mutuellement leurs code reviews[1], l’outil magpie[2] et le récent billet de Cloudflare sur sa stack de code review[3] sont assez convaincants
  Je reste sceptique vis-à-vis de l’IA, mais davantage pour la question de savoir si c’est bon pour le monde que pour celle de savoir si ça fonctionne. Ce travail de revue donne rarement l’impression d’externaliser la réflexion ou d’amoindrir les compétences des travailleurs. Cela ne déclenche pas les mêmes signaux d’alarme que de faire écrire le code par l’IA, ou de faire corriger par l’IA les problèmes qu’elle a elle-même trouvés. Bien sûr, les problèmes environnementaux et les autres préoccupations éthiques restent très importants
  J’ai été impressionné récemment par la qualité des code reviews par IA, mais l’expérience de devoir interagir séparément avec trois reviewers IA dans une PR GitHub est affreuse. J’aimerais une boucle de revue plus locale, orientée local, et qui comprenne jj/rebase
  Contexte : un backend PHP/Laravel assez volumineux et un frontend Vue
  [1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
  [2]: https://github.com/liliu-z/magpie
  [3]: https://blog.cloudflare.com/ai-code-review/

• Le temps que je passe dans les boucles LLM de revue/correction est en moyenne plus long que si j’écrivais le code directement à la main
  C’est aussi parce que, quand je suis dans le flow, j’écris le code très vite, et qu’il arrive parfois que le code sorte encore plus vite que je ne le pensais. De plus, les premières versions que le LLM produit sont généralement vraiment médiocres
  Ce qui est intéressant malgré tout, c’est qu’en relisant moi-même et en demandant plusieurs tours de revue et de corrections, j’obtiens en moyenne un résultat de meilleure qualité que le code que j’aurais écrit moi-même dans le même temps. Voir le code de quelqu’un d’autre itéré plusieurs fois me donne l’impression de mieux comprendre, dans son ensemble, l’objectif que je cherche à atteindre qu’un résultat jailli d’un état de concentration intense

  • Si l’IA écrit du mauvais code, il faut changer d’IA. Les IA avancées actuelles ne devraient pas produire de mauvais code

• Cet article ne parle pas d’écrire du code avec l’IA, mais uniquement de code review
  Le problème que je rencontre avec le coding agentique, c’est qu’en programmant on prend une multitude de microdécisions d’architecture. On dispose rarement d’une spécification complète dès le départ ; on construit la spécification en observant ce qu’on écrit
  Avec Claude Code ou Codex, ce processus disparaît. Claude Code est tellement motivé à atteindre l’objectif qu’avoir l’impression de coder avec lui ressemble à un rêve fiévreux. Au final, on a moins confiance dans sa compréhension des cas limites ou dans l’adéquation au projet, à son architecture et à ses objectifs de conception
  En plus, j’aime programmer, faire du reverse engineering, etc. Les LLM peuvent résoudre certains problèmes ou livrer des fonctionnalités, mais j’ai l’impression qu’ils m’enlèvent ce plaisir. J’essaie de trouver un mode d’utilisation dans lequel je puisse les employer avec confiance, mais j’ai peur qu’au bout du compte ce mode se limite au chat, à la recherche et à jouer le rôle de rubber duck pour mes propres idées

• À l’inverse, certaines entreprises poussent l’idée que les ingénieurs devraient rendre robustes des pipelines d’agents auto-évaluateurs intégrant une boucle de feedback humain, afin que les agents écrivent l’essentiel du code de production
  Le CEO de Creao a déclaré en janvier de cette année avoir réarchitecturé l’ensemble de son système de production en deux semaines. Il a aussi affirmé que les agents implémentaient trop de fonctionnalités, trop vite, au point qu’il fallait attendre que le business development suive
  Je me demande comment évaluer l’option consistant à multiplier sa production par 100 avec l’IA, par rapport à celle qui consiste à développer ses propres compétences grâce à l’IA
  Cela dit, les gains de productivité liés à l’IA sont bien réels. Par exemple, une organisation d’ingénierie chez Snowflake a atteint tous ses OKR dès le premier trimestre, une première dans l’histoire de l’entreprise. D’ordinaire, atteindre 70 % des OKR prévus était déjà considéré comme une réussite ; j’imagine le stress que ce genre de résultat peut faire ressentir aux ingénieurs

• Le titre de cet article laissait penser qu’il aurait plus de profondeur, et je m’attendais à de vrais exemples de code
  Mais il ressemble à d’autres billets d’opinion. En gros, il propose des prompts qui fonctionnent pour l’auteur, c’est-à-dire une manière de demander à l’IA de trouver des bugs, puis recommande à tout le monde de faire pareil
  J’utilise ce genre d’outils au travail et sur des projets perso, donc j’espérais voir et apprendre quelque chose, mais les billets d’opinion sans exemples sont désormais trop nombreux

  • Je me demande s’il a réellement essayé le flux qu’il propose. Je pense que c’est un flux utile, et si je n’en avais pas déjà découvert un similaire, j’aurais été reconnaissant d’avoir ce genre de piste
    L’auteur pourrait créer un harness de code pour ça, ou en bricoler un rapidement, mais à ce stade ce type d’outillage semble plus relever de votre domaine en tant que praticien. Si vous voulez automatiser et expérimenter, spécifier directement ce que vous voulez a de fortes chances d’être, honnêtement, plus rapide que de manipuler son code

• Pendant que je lisais ça, je travaillais sur une fonctionnalité assez dense, et cela a demandé un nombre important d’itérations
  Le résultat final contenait en fait bien moins de code que celui que j’avais au milieu du processus. Du coup, je me suis demandé si l’IA m’avait réellement aidé, puisque j’aurais peut-être pu écrire moi-même le code dans le temps passé à itérer
  Mais grâce à l’IA, j’ai pu produire rapidement quatre variantes de fonctionnalité qui ne me plaisaient pas, et les jeter tout aussi rapidement sans que cela pèse

  • C’est justement l’un des plus grands bénéfices que j’ai tirés de l’usage de l’IA
    Avant, je devais énormément réfléchir au plan avant de me lancer dans l’implémentation d’une nouvelle fonctionnalité, et je ne découvrais souvent l’inadéquation avec le code existant qu’après avoir déjà écrit pas mal de choses. Maintenant, je peux demander à l’IA un plan d’implémentation détaillé et repérer ce genre de petits problèmes en quelques heures, voire moins
  • Alors, au final ? Ça valait le coup ?

• Ce qui a été intéressant ces dernières années, c’est de suivre les limites de ma paresse en programmation
  En tant que développeur, je déteste le code boilerplate. Je n’aime ni l’écrire ni le maintenir. J’ai donc souvent conçu mes designs et mon architecture autour de cette préférence ; parfois c’était judicieux, parfois non. Dans tous les cas, c’était ma préférence, et j’évitais les tâches qui me coûtaient
  Il y a quelques années, quand les LLM ont commencé à devenir un peu utiles pour coder, j’ai constaté qu’ils étaient en pratique excellents pour le boilerplate, et qu’autour de 2023 c’était presque tout ce qu’ils savaient vraiment bien faire. Cela m’a amené à réfléchir à quel point, dans nos designs et notre architecture système, nous avions intégré implicitement les forces et les faiblesses des personnes avec qui nous travaillons
  Les modèles les plus récents ont des forces et des faiblesses très différentes de celles des humains, et les mettre à contribution est un exercice intéressant qui demande d’autres types de compétences en architecture et en ingénierie. J’y prends du plaisir et j’espère continuer

  • Le boilerplate devient optionnel, ou est généré automatiquement, quand on dispose d’une bonne bibliothèque ou d’un bon framework
    Il est bien préférable d’obtenir une sortie déterministe avec django-admin startproject, npm init, meteor create que de lancer un prompt à un LLM sans savoir ce qui va en sortir
    Dans un écosystème web mature, le boilerplate est minimisé. Maintenant qu’on confie cette tâche aux LLM, j’ai peur que les efforts de développement pour créer des CLI de type startproject avec de bonnes valeurs par défaut diminuent

• J’aime bien. J’utilise moi aussi une approche ralph-loop similaire
  Je pars d’un plan validé, puis je le transmets à un coordinateur ; pour simplifier, le traitement se fait sur deux sessions, build et review, avec un modèle distinct affecté à chacune

• Ce qui me freine dans l’usage des agents de code, c’est le fait de devoir dépendre de services externes payants
  Existe-t-il un bon modèle local pour coder ?

  • À ce jour, ce mois-ci, Qwen3.6 (27B ou 35B-A3B) ou Gemma 4 reviennent souvent
    Ceci peut aussi aider : https://hnup.date/hn-sota
    Les modèles Qwen sont mon modèle de tous les jours cette semaine

[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