Discussion :

[Nolan Lawson]

Utiliser l'IA pour écrire un meilleur code, mais plus lentement, par Nolan Lawson

Beaucoup de gens semblent convaincus que l'intérêt du codage par IA est d'écrire du code de mauvaise qualité aussi vite que possible. Produire à la chaîne du code à peine passable, ouvrir des PR massives et les fusionner sans les vérifier. Et c'est parti !

Mais le fait est que les LLM sont très flexibles. Et vous pouvez les utiliser tout aussi efficacement pour écrire du code de haute qualité plus lentement.

Cette affirmation me semble tout à fait évidente à ce stade, et j’ai failli ne pas écrire cet article pour cette raison. Mais il semble y avoir suffisamment de personnes convaincues que les LLM ne servent qu’à cracher du code de mauvaise qualité pour qu’il vaille la peine de défendre le point de vue opposé.

Si Mythos nous a appris quelque chose, c’est que les agents LLM sont vraiment doués pour trouver des bugs. Lancez-les suffisamment de fois sur une base de code, et ils trouveront tellement de bugs que vous ne saurez presque plus quoi en faire.

Comme beaucoup d’autres, j’ai également constaté que cela vaut pour les modèles autres que Mythos – certains sont peut-être plus efficaces que d’autres pour détecter des bugs subtils ou éviter les faux positifs, mais le fait est que les derniers modèles publics d’Anthropic et d’OpenAI sont suffisamment performants pour trouver de nombreux bugs dans une base de code non vérifiée.

Le problème ne réside pas tant dans la détection des bugs que dans leur hiérarchisation et leur validation. C’est pourquoi j’ai créé une compétence Claude que j’ai adaptée à partir de l’idée centrale de cet article, à savoir que plus vous utilisez de modèles différents pour l’examen d’une PR, moins vous risquez d’obtenir des hallucinations ou de faux bugs.

La compétence dit (en paraphrasant) :

Lancez un sous-agent Claude, Codex et Cursor Bugbot pour trouver les bugs dans cette PR classés par niveau de gravité : critique/élevé/moyen/faible. Une fois qu’ils ont tous terminé, examinez leurs résultats, effectuez vos propres recherches pour écarter les faux positifs, puis rédigez un rapport final.

C’est en gros tout. Vous pouvez ajouter votre propre définition du terme « bug » si vous le souhaitez – la mienne comprend des stipulations concernant les principes KISS et DRY, l’écriture de code HTML/JSX accessible, l’utilisation d’index appropriés pour les requêtes SQL, etc.

D'après mon expérience, cette compétence permet toujours de trouver des tonnes de bugs dans une PR, et le taux de faux positifs est proche de zéro. Elle détecte tellement de bugs que vous vous ennuierez à mourir si vous essayez de tous les corriger. Ils vont des bugs critiques de sécurité ou d'exactitude aux bugs de performance de niveau moyen plus banals, en passant par les bugs de bas niveau du type « ce commentaire est trompeur ».

Mon workflow type est le suivant :

- Demander à un agent de corriger tous les bugs critiques et à haut risque (en lui indiquant la solution appropriée), puis répéter l’opération jusqu’à ce qu’il n’y ait plus de bugs critiques/à haut risque

- Ignorer les bugs à haut risque/moyen risque qui ne valent pas la peine d’être corrigés (par exemple, 100 lignes de code pour corriger un cas limite très spécifique)

- Abandonner la PR si elle contient tellement de bugs critiques que je me rends compte que l’approche globale est erronée

Lorsque j’utilise cette technique, je ne constate pas nécessairement une augmentation de ma vélocité. Au contraire, le processus de révision met souvent en évidence des bugs préexistants, ce qui m’entraîne dans une quête secondaire où je me retrouve à écrire des tests unitaires et à corriger des défauts subtils antérieurs à la PR. C’est l’opposé du style de développement « 10x la productivité » à la chaîne que la plupart des gens imaginent lorsqu’ils pensent au vibe coding, mais je trouve cela très satisfaisant.

C’est un excellent moyen d’améliorer la santé globale du code tout en vous familiarisant avec ses recoins les plus obscurs. D’après mon expérience, le scénario idéal d’une architecture complexe est moins intéressant que ses modes de défaillance. Et avant l’arrivée des LLM, c’est généralement ainsi que je me familiarisais avec un code : en comprenant où les hypothèses tombaient à l’eau, puis en mettant la main à la pâte pour corriger le problème.

Si vous êtes du genre à douter que le codage par IA serve à quoi que ce soit, je doute que cet article vous convainque. Mais si vous êtes le genre de développeur qui utilise des agents pour écrire des PR de plusieurs centaines de lignes que vous comprenez à peine vous-même, je vous invite à ralentir un peu et à essayer cet autre style, plus lent, de « vibe coding ». Demandez à un agent comment fonctionne votre PR et comment elle pourrait échouer. Demandez-lui de rédiger des documents Markdown avec des graphiques Mermaid si nécessaire. Utilisez la compétence /grill-me de Matt Pocock jusqu’à ce que vous compreniez le PR dans son intégralité, de bout en bout.

Vous ne serez peut-être pas plus « productif » en termes de lignes de code brutes. Vous risquez de gaspiller une tonne de jetons pour finalement découvrir que votre plan était erroné dès le départ. Mais je trouve que ce style de codage est une version plus puissante du type de programmation que j’essayais déjà de pratiquer avant les LLM : minutieux, méthodique, obsédé par la qualité, axé sur l’amélioration des choses pour le prochain codeur.

Alors respirez profondément, ralentissez, essayez cette technique, et voyez si vous n’appréciez pas d’écrire un meilleur code plus lentement.

Source : Using AI to write better code more slowly

Et vous ?

Pensez-vous que cette proposition est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Il existe une meilleure façon de coder avec l'IA, par Namanyay Goel

Vos pull requests slop vibe-codées ne sont pas les bienvenues, car les outils de codage basés sur l'IA posent un nouveau problème aux responsables de projets open source, par Sam Saffron

Si vous êtes doué pour la révision de code, vous serez doué pour utiliser les agents IA, par Sean Goedecke

[Matthieu Vergne]

Je suis en train de produire une formation à l'usage de l'IA pour les développeurs dans ma boîte, et c'est grosso modo le même message. Pour coder de manière responsable avec l'IA, il faut faire du pair programming avec. Or entre humain, le pair programming implique déjà de communiquer en continu et de poser des questions à l'autre pour comprendre, de façon à ce que tout le monde comprenne la même chose et monte en compétence. C'est pareil avec l'IA. La différence étant qu'elle peut produire beaucoup plus vite qu'on ne peut lire. Et pour rendre ça reviewable je parle d'établir un plan avec l'IA dont le niveau de détail dépend d'un niveau de granularité de pilotage (niveau pour que le LLM arrive à exécuter le plan sans accrocs, ça dépend notamment du modèle) et d'un niveau de granularité de suivi (niveau pour que l'humain arrive à suivre). L'idée étant de prendre le plus petit des deux.