Comment j'utilise les agents IA pour écrire du code avec Claude Code

Par Nolan Lawson

Comment j'utilise les agents IA pour écrire du code avec Claude Code, par Nolan Lawson

Oui, c'est le énième article sur l'IA et le codage que vous voyez cette année. Bienvenue en 2025.

Certaines personnes trouvent les LLM vraiment déplaisants, et si c'est votre cas, je vous recommande de passer cet article. J'ai entendu tous les arguments, et je ne suis plus convaincu.

J'étais autrefois un fervent opposant à l'IA, mais avec la sortie de Claude Code, OpenAI Codex, Gemini CLI, etc., je ne peux plus me permettre de m'opposer à l'histoire et de crier « Stop ! ». J'ai vu mes collègues utiliser cette technologie de manière trop productive pour la rejeter comme une mode ou un mirage. Elle écrit souvent mieux que moi, ce qui n'est pas peu dire, car je fais cela depuis 20 ans et j'ai beaucoup d'opinions grincheuses et vieillottes sur la qualité et l'exactitude du code.

Mais il faut savoir utiliser correctement les agents IA ! Sinon, ils sont un peu comme un couteau de cuisine bien affûté fixé à une tronçonneuse : si vous ne savez pas vous en servir correctement, vous allez vous blesser.

Configuration de base

J'utilise Claude Code. Principalement parce que je suis trop paresseux pour explorer toutes les autres options. J'ai des collègues qui ne jurent que par Gemini, Codex, des outils open source ou autres, mais pour moi, Claude est suffisant.

Tout d'abord, vous avez besoin d'un bon fichier CLAUDE.md (ou AGENTS.md). De préférence un pour le projet sur lequel vous travaillez (la configuration du terrain, l'architecture globale du projet, les pièges, etc.) et un pour vous-même (votre environnement local et vos particularités de codage).

Cette étape peut sembler facultative, mais elle ne l'est pas. Pensez à vos premiers mois dans un nouvel emploi : vous ne savez rien du fonctionnement du code, vous ne connaissez pas la vision ou la conception globale, vous tâtonnez donc dans le code et vous cassez tout sur votre passage. Idéalement, vous avez besoin d'une personne expérimentée, qui connaît vraiment les petits secrets du code, pour rédiger un bon fichier CLAUDE.md qui explique la structure globale, les parties stables, celles qui sont encore en cours de développement, celles qui posent problème, etc. Sinon, le LLM arrive à chaque fois dans le projet sans aucune connaissance préalable et va tout chambouler.

Quant à votre propre CLAUDE.md personnel (c'est-à-dire dans ~/.claude), il devrait être réservé à vos propres particularités de codage. Par exemple, j'aime le nom de variable _ dans les fonctions map() ou filter(). C'est comme ma carte de visite, je ne peux pas m'en passer.

Stratégie globale

J'ai perdu beaucoup de temps avec les LLM. Beaucoup de temps. Ils sont aussi stupides que le prétendent leurs détracteurs. Ils vous mèneront joyeusement en bateau et vous diront « Excellente idée ! » jusqu'à ce que vous réalisiez peu à peu qu'ils ont construit une monstruosité qui fonctionne à peine. Je comprends pourquoi certaines personnes les essaient puis les abandonnent pour toujours avec dégoût.

Il existe cependant plusieurs façons de les rendre plus utiles :

1. Donnez-leur une boucle de rétroaction, généralement par le biais de tests automatisés. Les tests automatisés sont un bon moyen pour l'agent de passer de « J'ai résolu le problème ! » à « Oh, attendez, non, je ne l'ai pas fait... » et de trouver une solution qui fonctionne.

2. Utilisez le « mode planification » pour les tâches plus complexes. Le simple fait d'amener l'agent à « réfléchir » à ce qu'il fait avant de l'exécuter est utile pour quelque chose de plus simple qu'une refactorisation pure ou une autre tâche routinière.

Par exemple, une fois, j'ai demandé à un agent d'améliorer les performances d'une requête SQL. Il a immédiatement répondu « J'ai trouvé une solution ! ». Je lui ai alors demandé d'écrire un benchmark et d'utiliser un SQL EXPLAIN, et il s'est immédiatement rendu compte que cela ralentissait en fait les choses. L'étape suivante a donc consisté à essayer trois variantes différentes de la solution, à les tester chacune par rapport au benchmark, et seulement ensuite à décider de la marche à suivre. Cela ressemble étrangement à ma propre expérience en matière d'optimisation des performances : le plus grand danger est de se laisser séduire par sa propre solution « intelligente » sans la tester rigoureusement.

C'est pourquoi j'ai constaté que les agents de codage ne sont (actuellement) pas très doués pour l'interface utilisateur. On finit par utiliser quelque chose comme Playwright ou Chrome DevTools MCP/skill, et soit cela consomme beaucoup trop de jetons, soit cela ralentit considérablement les choses parce que l'agent doit inspecter le DOM (une multitude de jetons) ou écrire un script Playwright et prendre une capture d'écran pour l'inspecter (très lent). J'ai vu Claude se débattre trop souvent pour fermer une boîte de dialogue modale pour avoir la patience de le faire. Cela ne vaut la peine que si vous êtes prêt à laisser l'agent fonctionner pendant votre pause déjeuner ou autre.

L'IA a fait une erreur ? Ajoutez plus d'IA

Cela devrait être évident, mais ce n'est étonnamment pas le cas. Les IA ont tendance à faire des erreurs singulières et caractéristiques :

1. Supprimer les commentaires utiles des développeurs précédents – « c'est un hack stupide que nous prévoyons de supprimer dans la version X » est soit supprimé, soit transformé en un commentaire très officiel qui obscurcit le sens original.

2. Dupliquer du code. Dupliquer du code. Je ne sais pas pourquoi les agents aiment tant dupliquer du code, mais c'est le cas. C'est comme s'ils n'avaient jamais entendu parler du principe DRY.

3. Apporter des « corrections » subtiles lors de la refactorisation du code qui vont à l'encontre de l'intention initiale. (Par exemple : « Je vais juste ajouter une vérification null supplémentaire ici ! »)

Heureusement, il existe une solution assez simple à ce problème : vous fermez Claude Code, vous démarrez une nouvelle session et vous dites à l'agent « Hé, comparez avec origin/main. Ceci est censé être une refactorisation pure. Est-ce vraiment le cas ? Vérifiez s'il y a des bugs fonctionnels. » Inévitablement, l'agent trouvera des erreurs.

Cela semble mieux fonctionner si vous ne dites pas à l'agent que le code est le vôtre (probablement parce qu'il essaierait simplement de vous flatter en vous disant à quel point votre code est brillant). Vous pouvez donc mentir et dire que vous examinez la demande de modification d'un collègue ou quelque chose du genre si vous le souhaitez.

Une fois que cet agent de « révision de code » a fonctionné, vous pouvez littéralement fermer Claude Code et relancer exactement la même invite. Répétez l'opération plusieurs fois jusqu'à ce que vous soyez sûr que tous les bugs ont été éliminés. C'est incroyablement efficace.

Accomplissez un travail supplémentaire pendant que vous dormez

L'un des aspects les plus addictifs de Claude Code est que, lorsque je quitte le travail, je peux le laisser itérer sur un problème pendant que je bois une bière, que je passe du temps avec ma famille ou que je m'accroupis pour faire une sieste. Il ne se fatigue pas, ne prend pas de vacances et ne s'énerve pas lorsqu'il essaie 10 solutions différentes pour résoudre le même problème.

Dans un certain sens, c'est comme mon double virtuel à la Jekyll et Hyde, car il accomplit un travail que je n'aurais jamais fait autrement. Parfois, le travail est un échec : je me réveille et je me rends compte que le LLM s'est lancé dans une tangente bizarre qui n'a pas résolu le vrai problème, alors je fais un git reset --hard et je recommence à zéro. (Souvent, j'utilise mon propre cerveau humain pour ce genre de choses, car cette situation est un bon indice que ce n'est pas le bon travail pour un LLM).

J'ai constaté que le plus grand facteur limitant dans ces cas-là n'est pas le LLM lui-même, mais plutôt le fait que Claude Code demande une autorisation pour chaque petite chose, au point que j'ai développé une cécité à l'automatisation qui me pousse à parcourir rapidement la commande et à taper « oui ». Cela m'effraie, j'ai donc commencé à tester l'exécution de Claude Code dans un conteneur Podman en mode yolo. Cependant, en raison de la triple menace mortelle, je ne me sens actuellement à l'aise de le faire que pour des projets secondaires où je me moque que l'ensemble de mon code soit envoyé sur le dark web (ou quoi que ce soit d'autre que des agents malveillants pourraient faire).

Malheureusement, cela conduit à une situation où l'agent envahit mon temps libre, et je suis tenté de vérifier régulièrement ses progrès et soit de les approuver, soit de lui donner une autre direction. Mais cela devient davantage un problème d'équilibre entre vie professionnelle et vie privée qu'un problème d'interaction entre l'homme et l'agent. Je devrais probablement accepter de profiter de mes loisirs plutôt que de superviser un agent pointilleux 24 heures sur 24 !

Conclusion

Je déteste toujours un peu les agents IA et j'ai des sentiments ambivalents à leur égard. Mais ils fonctionnent. Quand je lis aujourd'hui des diatribes anti-IA, mes yeux ont tendance à se voiler et je pense à la citation de Galilée : « Et pourtant, elle tourne. » Tous vos arguments sont très sensés, ils me parlent beaucoup, et pourtant, la technologie fonctionne. J'écris une quantité folle de code ces jours-ci en très peu de temps, ce qui aurait été impossible avant les LLM.

Je n'utilise pas les LLM pour tout. J'ai appris à mes dépens qu'ils ne sont tout simplement pas très doués pour les projets subtils, novateurs ou nébuleux qui touchent à de nombreuses parties disparates du code. Dans ce cas, je mets simplement Claude de côté et j'écris tout moi-même, comme un Néandertalien. Mais ces cas sont de plus en plus rares, et je passe beaucoup de temps à rédiger des spécifications, à réviser du code ou à demander à des IA d'écrire du code pour réviser le code d'autres IA (un peu comme un apprenti sorcier bizarre qui surveille un autre apprenti sorcier).

D'une certaine manière, je compare mon nouveau rôle à celui d'un architecte logiciel : les meilleurs architectes que je connaisse continuent parfois à se salir les mains et à écrire eux-mêmes du code, ne serait-ce que pour se rappeler la réalité du terrain. Mais ils passent encore la plupart de leur temps à rédiger des documents de conception et des spécifications.

Je n'utilise pas non plus l'IA pour mon travail open source, parce que ça me semble... dégoûtant. Le code est « le mien » dans un certain sens, mais en fin de compte, je ne me sens pas vraiment propriétaire, parce que je ne l'ai pas écrit. Ça me semblerait bizarre de mettre mon nom dessus et de le diffuser sur Internet pour le partager avec d'autres. Je suis sûr que je nage à contre-courant sur ce point, cependant.

Si je pouvais remonter le temps et faire en sorte que les LLM n'aient jamais existé... je le ferais peut-être encore. J'ai vraiment pris beaucoup plus de plaisir à écrire tout le code moi-même, même si j'éprouve aujourd'hui un plaisir différent, je ne peux donc pas complètement le renier.

Cela me rappelle la conception de jeux vidéo : si vous créez un mécanisme ennuyeux, mais que les joueurs peuvent exploiter pour gagner systématiquement (par exemple, sauter sur des carapaces de tortues pour obtenir des 1-Up à l'infini), ils choisiront cette stratégie, même s'ils finissent par détester le jeu et s'amuser moins. Les LLM sont un peu comme ça : ils constituent la stratégie optimale évidente, et même s'ils sont moins amusants, je continuerai à les choisir.

Quoi qu'il en soit, je vais peut-être me faire quelques ennemis avec cet article, mais j'ai depuis longtemps accepté le fait que ce que j'écris sur Internet attire généralement des détracteurs. En attendant, je pense que la grande majorité des développeurs ont fait la paix avec l'IA et passent à autre chose. Pour le meilleur ou pour le pire, je fais partie de ceux-là.

Source : "How I use AI agents to write code"

Et vous ?

Pensez-vous que ces affirmations sont crédibles ou pertinentes ?
Quel est votre avis sur le sujet ?

Voir aussi :

Une expérience de vibe coding : le bon, le mauvais et le laid, par Nolan Lawson

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

L'IA n'est même pas capable de corriger un simple bug, mais bien sûr, virons les ingénieurs, par Namanyay Goel