6 semaines d’utilisation de Claude Code

 (blog.puzzmo.com)
37 points par GN⁺ 2025-08-07 | 7 commentaires | Partager sur WhatsApp
  • Depuis l’adoption de Claude Code, la manière d’écrire et de maintenir du code a profondément changé — au point d’être comparée à « l’arrivée de la photographie dans le monde du code », avec une implémentation rapide et une grande liberté d’expression
  • Les tâches répétitives ou perçues comme de la « dette technique » (migrations, changement de framework, etc.) peuvent désormais être menées rapidement en parallèle, même en solo, avec très peu de charge supplémentaire en plus du travail principal
  • Un mode de développement expérimental consistant à « essayer d’abord, juger ensuite », permettant de générer et supprimer facilement tests / abstractions / code d’expérimentation, et d’y gagner en productivité comme en compréhension
  • Le prototypage de jeux, la collaboration et les déploiements expérimentaux sont fortement accélérés — un game designer peut concrétiser une idée jusqu’à son exécution en quelques heures, sans écrire de code lui-même
  • Dans un environnement favorable à Claude Code, avec monorepo, stack technique claire et base de code récente, la vitesse et la flexibilité du développement réel augmentent fortement

Introduction : ce qui a changé après l’adoption de Claude Code

  • Après avoir utilisé Claude Code pendant les 6 dernières semaines, un changement majeur s’est fait sentir dans la manière d’écrire et de maintenir le code
  • Il semble qu’une « liberté d’expression » soit apparue, sans avoir à écrire soi-même chaque ligne de code
  • Avec Claude Code, il devient possible de concevoir la structure d’ensemble d’un seul coup, puis d’aboutir au résultat grâce aux capacités de revue et d’édition
  • Comme l’arrivée de la photographie a réduit l’attrait du dessin manuel, le processus d’entrée et de production en programmation est lui aussi en train de profondément changer
  • Ce changement peut sembler déstabilisant, mais l’apparition des outils fondés sur les LLM provoque un changement de paradigme dans la programmation

1. Comment Claude Code a transformé l’écriture et la maintenance du code

  • Des travaux de migration, refactorisation et résorption de dette technique qui prenaient autrefois plusieurs semaines à plusieurs mois ont tous été menés en parallèle et achevés en 6 semaines après l’adoption de Claude Code
  • Exemples : conversion de centaines de composants React Native vers React, remplacement du système RedwoodJS, migration de Jest vers Vitest, server-side rendering, refactorisation du design system, mise à niveau vers Node 22, etc.
  • Des side projects et éléments de backlog qui devaient auparavant être planifiés séparément peuvent maintenant être traités sur le temps libre, en parallèle du travail principal, avec presque aucune charge supplémentaire
  • L’ancienne logique « sécuriser du temps puis lancer un gros chantier de dette technique » est rompue, au profit d’une immédiateté où l’on peut commencer, avancer et terminer sur-le-champ

2. Une culture de développement expérimentale : « essayer d’abord, juger ensuite »

  • Lorsqu’une idée apparaît, elle est d’abord testée avec Claude Code, avec génération et suppression répétées de code de test dès le début afin d’apprendre en pratiquant
  • Même sans stratégie de test frontend établie, il devient possible de générer et supprimer à la volée différentes approches de test pour chaque PR avec Claude Code, afin d’accumuler de l’expérience et d’aider à fixer une direction globale
  • Les réflexions autour des idées et des abstractions peuvent elles aussi être validées et explorées rapidement selon une logique « essayer soi-même → l’échec n’est pas coûteux »
  • Le coût de l’échec chutant drastiquement, le cycle expérimentation → apprentissage → décision s’accélère fortement

3. Évolution du développement en parallèle et de la collaboration

  • En utilisant deux clones git / profils VSCode, il est possible de mener des travaux indépendants sur chaque clone (par exemple : l’un pour rédiger une PR, l’autre pour du développement expérimental)
  • Pendant que Claude Code travaille sur un clone, il est possible d’avancer en parallèle sur l’autre, ou de différencier clairement les environnements via des thèmes et ports distincts
  • Cela permet de préparer des Pull Requests en parallèle, d’éviter les conflits de ports des serveurs de développement et d’améliorer l’efficacité du travail

4. Réinvention du processus de prototypage de jeux et de développement expérimental

  • Un processus qui prenait auparavant de plusieurs semaines à plusieurs mois — création d’un prototype de jeu → diffusion interne → feedback → publication ou abandon — peut désormais, après l’adoption de Claude Code, être mené directement par un designer en quelques heures, jusqu’au déploiement sur le site
  • Le cycle idée → exécution → feedback d’équipe → fin de l’expérience ou passage en production (réécriture) devient drastiquement plus court
  • Cela s’accompagne toutefois de nouvelles questions opérationnelles, comme la gestion des jeux temporaires ou les critères de formalisation / abandon

5. Utilisation de Claude Code dans le codage quotidien et la collaboration

  • Lors du triage hebdomadaire, il est possible d’utiliser l’action GitHub de Claude Code pour générer instantanément des PR et mener des expériences, et d’appliquer immédiatement les petits correctifs
  • Les profils qui exploitent le plus efficacement Claude Code sont les membres d’équipe combinant compréhension produit, compétences techniques et autonomie, des « full-breadth developers »
    • « Full-breadth developers » : cela aide un même développeur à piloter librement l’ensemble du flux de travail
  • Tant que l’humain conserve la revue de code, l’apport de contexte, les corrections et les décisions, la productivité et la créativité de toute l’équipe augmentent

6. Un environnement de codebase favorable à Claude Code

  • Monorepo : lorsque tout le code, les schémas de base de données, les API et la logique d’interface sont réunis au même endroit, Claude Code est idéal pour comprendre le contexte et automatiser des tâches
  • L’adoption d’une stack standardisée (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap, etc.) facilite la compréhension et l’automatisation par le LLM
  • Le maintien d’une base de code récente et la réduction du legacy maximisent l’efficacité de l’usage des LLM

7. Les limites de Claude Code et les changements réellement ressentis

  • Même si les changements quantitatifs, comme le nombre de PR ou de commits, ne sont pas énormes, la vitesse perçue, la flexibilité et la productivité au quotidien augmentent fortement
  • Claude Code joue le rôle d’un pair programmer de niveau “junior expérimenté et plus” — si l’ingénieur gère la qualité du code, la logique et le contexte, c’est un excellent partenaire
  • Pour les tâches répétitives, la résorption de dette technique ou l’avancement rapide de side projects, il offre une expérience de travail qualitativement différente

8. Une stratégie de « mise en parallèle des implémentations » recommandée aux juniors et aux apprenants

  • Il n’est pas nécessaire de s’obséder excessivement avec les dernières tendances de l’écosystème LLM
  • Pour les développeurs débutants, il est recommandé d’écrire soi-même le code, puis de demander à Claude Code de réaliser la même tâche, afin d’apprendre par comparaison et analyse
    • En s’inspirant des solutions de Claude Code, on peut assimiler rapidement différentes abstractions et patterns de développement réels
    • En utilisant le LLM comme concurrent et mentor, il devient possible de développer à la fois ses compétences pratiques et son intuition des écosystèmes récents
  • Claude Code est comme un téléphone mobile : il n’a pas besoin d’être allumé en permanence
    • L’important, au final, est de garder la maîtrise et de l’utiliser efficacement

9. Explosion des side projects et des expérimentations de courte durée

  • De petites expérimentations, des outils et des améliorations de blog qui étaient auparavant difficiles à tenter faute de temps ou d’énergie peuvent désormais être réalisés en quelques heures avec Claude Code
  • Idée → implémentation immédiate → échec sans coût important — il devient facile de mener en parallèle des expérimentations créatives et des projets personnels en dehors de la production

10. Exemples réels de conversations avec Claude Code et de revues de code

  • Exemples concrets de processus besoin → génération de code → exécution → correction → revue, autour d’un script de nettoyage de base de données, d’un REPL de puzzle, d’une mise en page PDF de mots croisés, etc.
  • Des erreurs du LLM (raisonnement, exagération, hardcoding, etc.) peuvent survenir — l’ingénieur doit impérativement assumer la vérification logique et la responsabilité qualité pour en tirer une réelle valeur

11. La place de Claude Code dans l’ingénierie et conclusion

  • Claude Code excelle à intégrer un contexte large, comme du code de référence, des captures d’écran ou des explications supplémentaires
  • Claude Code est un programmeur assistant de niveau “post-junior” (junior confirmé et au-delà) — grâce à une patience et une vitesse infinies, il se révèle très efficace comme partenaire de travail
  • La conception, la qualité et le contrôle final restent du ressort des ingénieurs humains ; Claude Code élargit fortement le périmètre et la vitesse de l’implémentation, de l’expérimentation et de l’automatisation
  • Il permet de sortir de la contrainte consistant à « devoir coder soi-même ligne par ligne » et rend possible un environnement de développement où l’on se concentre davantage sur la conception, l’assurance qualité et l’innovation

À lire aussi

7 commentaires

 
benjamin 2025-08-08

J’utilise moi aussi Claude Code avec une grande satisfaction.
Je crois que cela fait maintenant environ 6 semaines que je l’utilise.
Je partage l’avis de l’auteur sur la plupart des points.

https://jeho.page/essay/2025/07/15/claude-code.html
 
zxavi 2025-08-07

Je ressens exactement la même chose que l’auteur du billet original haha
J’ai payé 200 $ et j’ai résolu en une heure un casse-tête qui me bloquait depuis 4 ans.
Je n’aurais probablement jamais pu le résoudre tout seul… et avec Cursor, ça ne passait absolument pas.
 
beoks 2025-08-07

Savez-vous s’il y a une différence quand on utilise Claude Code par rapport à Cursor + Claude LLM ?
J’utilise Cursor en ce moment, mais j’hésite à passer à Claude Code.
 
zxavi 2025-08-07

Quand vous parlez du Claude LLM, vous voulez dire la clé API ?
Ou bien vous parlez des modèles Agent qui se trouvent sous la fenêtre de chat ?

J’étais déjà globalement satisfait de Cursor, mais comme je me heurtais souvent aux limites d’usage, même en payant l’offre à 60 $, je vivais dans l’angoisse de me refaire limiter.
Du coup, j’alternais avec gemini cli par précaution, ce qui me stressait pas mal.

Cursor + Claude 4 Sonnet, c’est déjà très bien, mais le plus gros problème, c’était qu’une fois la limite atteinte au bout d’une journée, je ne pouvais plus l’utiliser pendant un mois.

Je n’osais même pas envisager d’utiliser Cursor + Claude 4 Opus.

Comme Claude Code est finalement basé sur le CLI et ne dépend pas des particularités d’un IDE, j’ai décidé de l’essayer.

Au début, j’étais sur l’offre à 20 $, mais il n’y a pas Opus dessus non plus.

Alors, comme j’allais bientôt atteindre la limite, je me suis dit que j’allais tenter un mois, j’ai payé 200 $, et en l’utilisant…

ça a été une vraie révélation. Opus… ce n’est vraiment pas la même catégorie.

Là, ça fait 4 jours que je suis sur l’offre à 200 $, et je suis en train de résoudre tous les problèmes difficiles que je laissais traîner haha
 
zxavi 2025-08-07

Impossible de modifier le post.

Cursor + Claude 4 Sonnet, c’était déjà largement suffisant, mais le plus gros problème, c’était qu’au bout d’une journée on atteignait la limite, et une fois la limite atteinte, on ne pouvait plus l’utiliser pendant un mois.

Je crois que ce n’était pas un mois mais une journée. J’ai vécu dans l’angoisse tout le mois.
Et je me suis beaucoup disputé avec Cursor,
mais beaucoup moins avec Claude Code.
 
beoks 2025-08-07

Oh, merci pour cette réponse détaillée.
Moi aussi, j’ai atteint la limite et j’utilise Cursor en mode Auto faute de mieux, mais il va falloir que je passe le cap.
 
GN⁺ 2025-08-07
Avis Hacker News

  • Après environ deux semaines d’utilisation de Claude Code, alors que j’étais habituellement sceptique vis-à-vis du codage avec l’IA, j’ai été vraiment impressionné. Il y a une petite courbe d’apprentissage pour accumuler de l’expérience, et il est indispensable de fournir le bon contexte ainsi que de découper le travail correctement. Bien sûr, il faut savoir programmer, et si l’on balance tout ce qu’on ne comprend pas à l’IA, cela finit forcément par poser problème. Avec plus de 25 ans d’expérience, j’ai la confiance nécessaire pour relire ce que Claude Code produit et corriger immédiatement quand c’est faux. Il y a 10 à 15 ans, j’imaginais des interfaces neuronales qui permettraient de ne plus écrire le code soi-même, et j’ai l’impression que Claude Code réalise cela en partie. Comme je tombe parfois sur la limite d’usage quotidienne, j’ai surtout essayé Gemini CLI 2.5 pro comme solution de remplacement, mais la comparaison avec Claude Code n’a même pas lieu d’être. Gemini est trop frustrant pour être utilisable. Autrefois, je n’aurais jamais imaginé payer plus de 100 dollars par mois pour des outils de développement, mais j’envisage très sérieusement de passer au forfait Max.

    • Je pense que cet outil convient bien lorsqu’un développeur senior peut conseiller et guider un développeur junior. D’après ce que j’entends autour de moi chez les seniors, beaucoup se plaignent que les juniors produisent avec les LLM du code encore plus étrange, plus lent, vulnérable sur le plan de la sécurité, voire complètement catastrophique, puis ouvrent des PR sans comprendre le code. Ce qui m’est le plus utile, c’est la génération de boilerplate (il suffit de décrire ce qu’on veut pour obtenir même une ébauche de conception de classes), la conversion de JSON en classes ou dans d’autres formats, et des questions du type : « Qu’est-ce qui ne va pas dans ce code ? Comment un ingénieur de niveau Staff le modifierait-il ? » En pratique, Claude Code a même permis de repérer à l’avance des bugs dans du code que j’avais moi-même tapé.

    • Ce qui est intéressant, c’est que les gens sceptiques à l’égard du « vibe coding » ont souvent des attentes extrêmement basses avant d’avoir réellement essayé l’outil. Beaucoup partent du principe que le code produit par un LLM sera nul et considèrent des cas extrêmes comme représentatifs de la moyenne. Mais une fois qu’ils l’utilisent eux-mêmes, ils sont surpris de constater que c’est meilleur que prévu. Bien sûr, il est impossible de créer d’un coup un SaaS valorisé à un milliard de dollars avec une équipe de 10 personnes uniquement grâce à Claude Code, mais beaucoup sous-estiment quand même sa puissance réelle.

    • À vrai dire, à strictement parler, ce que vous faites n’est pas du vibe coding. C’est plus proche de l’ingénierie logicielle assistée par IA. Le vibe coding, c’est accepter tel quel tout code produit par l’IA et continuer sans le comprendre. Comme chacun définit le terme différemment, il vaut mieux ne pas trop s’y fier.

    • Il y a encore quelques mois, je ne payais plus de 20 dollars pour aucun service par abonnement, et maintenant je paie 200 dollars par mois pour le forfait Max 20. Je suis un développeur slovaque installé aux États-Unis avec 20 ans d’expérience, et moi aussi j’en suis surpris. J’ai essayé d’autres outils, mais j’ai rarement ressenti à ce point un gain direct de productivité et d’efficacité. Claude Code est vraiment d’un autre niveau. Bien sûr, il faut continuer à superviser les détails, mais ma méthode consiste à partir du Plan Mode pour définir rigoureusement les exigences et le plan de modification du code, puis, une fois que j’en suis convaincu à 100 %, à le laisser exécuter, avant de faire une revue du résultat. (Les erreurs de compilation, les tests unitaires et les problèmes de lint sont corrigés par l’IA.) Cela donne l’impression d’avoir un ingénieur junior un peu bizarre, mais très cultivé et incroyablement rapide. Le développement logiciel se dirige clairement dans cette direction, et c’est l’avenir.

    • Ces derniers temps, j’ai l’impression que les modèles Claude sont peu fiables dès qu’il s’agit d’écrire ou de modifier du SQL. Par exemple, ils construisent bien les clauses conditionnelles, mais oublient de parenthéser les AND/OR, et Gemini pro détecte correctement cela comme un bug.

  • Je suis profondément d’accord avec l’idée que Claude Code a une vraie avance sur tous les outils concurrents. Je développe moi-même des outils cli de génération de code par IA depuis 2023, et on peut dire que j’ai essayé à peu près toutes les principales options. Je me reconnais fortement dans plusieurs méthodes de l’auteur :

    1. Un monorepo fait gagner énormément de temps.
    2. Commencer avec une spécification claire, et y consacrer suffisamment de temps. Avec un bon plan, l’IA peut rédiger l’essentiel de la spécification.
    3. Il faut impérativement mettre les tests en place dès le départ. C’est le point le plus important. Avec de bons tests et une bonne spécification, l’IA peut explorer récursivement de meilleures solutions. On a l’impression que le TDD est de retour.
    4. Les types et les linters apportent une aide énorme.
    5. Il est utile de ranger la documentation externe dans un répertoire séparé du projet (par exemple : docs/external-deps).
    6. Comme pour tous les outils, il faut un peu de temps pour trouver les techniques qui vous conviennent. C’est plus facile qu’avant, mais il y a encore des choses à apprendre. Les workflows diffèrent légèrement selon les personnes, ce qui donne presque l’impression d’un processus de codage en soi. J’ai récemment créé en vibe coding un serveur GraphQL RBAC ultra-simple appelé Permiso (https://github.com/codespin-ai/permiso). Ce n’est pas encore un projet testé ni relu de façon stable, mais cela peut déjà être utile à ceux qui ont besoin de quelque chose de simple.

    • Sur le deuxième point (commencer avec une bonne spécification), j’aimerais savoir plus concrètement comment vous organisez cette spécification. Est-ce un document Markdown séparé ? Quel niveau de détail faut-il viser ? Je suis aussi d’accord avec l’idée de « prévoir les tests dès le départ », mais en pratique, quand Claude dispose déjà d’un système de test branché, il arrive qu’il saute justement l’étape où il faudrait d’abord créer le code de test et qu’il enchaîne simplement des corrections répétées sans réelle validation des bugs ou des hypothèses. J’utilise parfois un flag pour activer ou désactiver certains comportements liés aux tests.

    • Le monorepo vous fait certes gagner du temps, mais il augmente aussi fortement les appels d’outils et la consommation de tokens de Claude. Je pense qu’une approche à la Aider, où l’on sélectionne seulement les fichiers nécessaires à transmettre à l’IA, est meilleure. Je comprends mal pourquoi Claude est aussi populaire. Aider est un meilleur outil dans presque tous les domaines, et il permet d’intégrer différents LLM.

    • Pour bien utiliser CC, il faut que la structure du projet soit bien en place. Sur un projet Django bien pourvu en tests, types et documentation, CC a très bien géré presque tout, même s’il a fallu le guider par moments. Récemment, je travaille aussi sur un side project visant à faire tourner CC hors ligne sur un modèle local. La première version s’est bien faite avec l’aide de ChatGPT, puis, en passant à CC, j’ai constaté que CC tournait au contraire autour des problèmes centraux, contournait ses erreurs et avait tendance, au lieu de refactoriser le code existant ou de corriger les bugs, à créer sans cesse de nouveaux fichiers ou scripts.

    • Je me demande si vous reformatez directement la documentation externe dans le projet. La plupart des projets n’ont leur documentation que sur un site web, donc je voudrais savoir si vous prenez vraiment le temps de créer à côté des fichiers Markdown propres.

  • La vraie puissance de Claude Code, ce n’est pas seulement le codage, c’est sa capacité à contrôler l’ordinateur dans son ensemble. S’il existe un outil CLI, Claude peut l’utiliser, et même sans cela, on a souvent des surprises en lui demandant. Par exemple, je lui ai confié toutes sortes de tâches annexes : rogner ou redimensionner des images, extraire des mp3 depuis des vidéos YouTube, supprimer les silences d’un fichier audio, etc. Cela me fait gagner un temps énorme. Je ne me souviens même plus comment je faisais avant. Je ne pense pas pouvoir revenir à l’ancienne manière.

    • Il vaut mieux attribuer à Claude un ordinateur séparé plutôt que de le connecter à votre machine réelle (qui n’est de toute façon pas toujours votre machine principale). Dans mon cas, j’ai un IDE qui tourne sur une VM cloud, et j’y connecte Claude via le navigateur (https://brilliant.mplode.dev). À mon avis, c’est l’UX optimale la plus proche d’une véritable exploitation d’agent. Pas besoin de terminal ni de config ssh : il suffit de se connecter, et l’instance est créée ou mise en pause automatiquement. En pratique, cela revient à lancer directement Claude + une instance Linux personnelle + un IDE via un simple lien. À l’avenir, je compte pouvoir lancer plusieurs instances à la demande et contrôler finement les permissions, le système de fichiers et les droits des conteneurs (JWT, etc.). En cas d’incident ou de besoin de revue, il suffit d’entrer directement dans l’IDE pour régler le problème. Il n’y a même pas besoin d’une UI séparée : on peut tout voir dans plusieurs panneaux de l’IDE ou lancer directement l’application web dans le conteneur. Je n’avais pas été aussi excité par l’évolution de la technologie depuis longtemps.

    • Même si tout a l’air formidable, quand on regarde uniquement la production réelle de code, les données montrent très peu de différence avant/après. Même en travaillant avec Claude, le nombre de commits, de PR et de lignes de code ne change pas beaucoup par rapport à avant. Autrement dit, le codage avec l’IA donne l’impression d’une plus grande productivité et la satisfaction de « faire produire quelque chose sans y toucher », mais dans la réalité il faut énormément de revue, de corrections et de re-prompting, et le volume total de sortie reste similaire. Et à force de déléguer les parties difficiles à l’IA, on affaiblit progressivement sa propre capacité de conception et de réflexion. Après un mois à n’utiliser que Claude ou d’autres LLM, si l’on essaie de créer soi-même une petite appli, non seulement le code, mais même la conception globale de la structure paraît plus difficile. À long terme, il y a un vrai risque que la codebase se dégrade lentement et que le bilan devienne négatif (au moins avec la génération actuelle de LLM).

    • Avant, je bricolais moi-même une à une les commandes ImageMagick (mogrify) à l’ancienne. Avec l’aide d’outils d’IA, je gagne un temps fou.

    • J’ai demandé à Claude de diagnostiquer pourquoi mon PC Linux plantait sans arrêt, et il m’a été d’une grande aide en récupérant les logs avec journalctl et en identifiant la cause. C’était une aide très concrète au dépannage.

    • Autre exemple : la génération de sites statiques est devenue extrêmement facile. On peut écrire un texte dans n’importe quelle syntaxe et demander à Claude Code de le convertir au format du blog, et il s’en charge tout seul. Par exemple, il suffit d’écrire « ajoute l’image image.jpeg » pour qu’il le fasse immédiatement. C’est pratique de ne pas être contraint par le Markdown ou le format Hugo.

  • En tant que personne ayant utilisé Claude code entre 12 et 16 heures par jour, voici quelques conseils que j’ai découverts :

    1. Le basculer sur le modèle sonnet dès le lancement (la qualité est très différente d’opus)
    2. Le compacting (compression de l’historique de conversation) fait fortement baisser la qualité en cours de route, donc il faut choisir le bon moment
    3. Le premier prompt est extrêmement important, car il définit la nature de la session. Si l’instance Claude devient hésitante ou peu coopérative, mieux vaut simplement terminer la session et en ouvrir une nouvelle.
    4. Si on formule poliment sa demande, par exemple « C’est peut-être une mauvaise idée, mais j’aimerais implémenter ~ », il a tendance à aider bien plus activement.
    5. En confiant à Claude l’orchestration Docker, j’ai eu l’impression d’un gain de productivité multiplié par 10. En lui déléguant tout le flux — relancer des conteneurs, vérifier les logs d’erreur, supprimer/rebuilder — je peux faire démarrer tout un service avec un seul prompt.

    • Le point 5 peut aussi être combiné, au-delà de Docker, avec un serveur MCP Playwright pour lui faire vérifier directement l’UI et les requêtes. 6. Commencer en plan mode, puis itérer jusqu’à obtenir un plan satisfaisant 7. Exploiter activement les slash commands (/commande) comme mini-prompts pour améliorer continuellement le résultat, fournir du contexte, voire lui demander d’utiliser des outils externes comme gh compacting ne doit surtout pas être déclenché brutalement à 0 %, il vaut mieux l’appliquer à un moment intermédiaire approprié. On peut ne pas être d’accord avec le point 1 (recommander sonnet).

    • J’ai plutôt tendance à éviter Docker, mais le conseil n°5 (utiliser Claude pour l’orchestration Docker) m’intrigue beaucoup. J’aimerais savoir quel format de prompt vous utilisez.

    • J’ai aussi utilisé avec succès une méthode consistant à commencer par un fichier plan.md très détaillé (liaisons entre systèmes, architecture globale, etc.), puis à faire tourner toute la nuit un outil comme claude-loop (https://github.com/DeprecatedLuke/claude-loop), avant de faire des correctifs manuels le matin.

    • Je suis curieux de savoir comment on peut utiliser Claude Code 16 heures par jour.

    • Il arrive que Claude fouille beaucoup trop l’intérieur des conteneurs. Je voulais seulement lui faire comprendre le code, mais il s’est mis à l’exécuter de multiples façons à l’intérieur du conteneur, au point de rendre la situation plus étrange qu’avant. Il lui est déjà arrivé de faire des choses comme envoyer des fichiers dans un pipeline de commandes CLI sans que cela ne produise rien, ce qui illustre une forme de compulsion à vouloir exécuter quelque chose.

  • Je ne sais pas à quel point Claude Code est réellement bon (je ne l’ai pas utilisé moi-même), mais il y a un point qui me fait hésiter personnellement. J’aimerais refactoriser en C# un projet personnel en gdscript (type Python), très lent et désordonné, pour le rendre plus propre et plus rapide. C’est un nouveau défi pour moi, et il y a un aspect très formateur. Si j’utilise Claude, j’ai l’impression de me priver d’une précieuse occasion d’apprendre (ce qui serait utile à long terme pour ma progression personnelle) ; si je ne l’utilise pas, j’ai l’impression d’investir du temps précieux dans une tâche ennuyeuse qui sera de toute façon automatisée à l’avenir. Ce dilemme revient sans cesse.

    • En 35 ans de carrière, j’ai adopté une approche où je confie à l’IA uniquement ce que je pourrais résoudre moi-même mais que je n’ai pas envie de faire, parce que c’est répétitif ou ennuyeux. Par exemple, corriger un schéma Open API 3.0 ne m’apporte aucun apprentissage si je le fais moi-même, donc je l’ai confié à Claude, de même que la génération de code d’exemple. Quand il y a de vrais points d’apprentissage, je les consigne dans des flashcards avec une appli comme Anki SRS ou dans un blog TIL. Je peux aussi implémenter moi-même plusieurs fois des exemples pour les transformer en expérience. L’essentiel, c’est qu’un nouvel apprentissage soit relié au cerveau au moins deux fois pour devenir efficace. C’est comme lorsqu’on apprend un nouveau mot dans une langue naturelle : on l’intègre dans trois phrases différentes.

    • Si vous ne relisez pas vous-même le code généré (autrement dit, si vous ne maîtrisez pas suffisamment le C#), la codebase se dégradera à une vitesse folle. Le code produit avec des LLM a tendance à accumuler les erreurs, donc il faut absolument améliorer cela ; sinon, on obtient rapidement une masse de déchets impossible à maintenir. Des amis à moi disent qu’ils font générer suffisamment de tests par l’IA pour détecter les problèmes très tôt, mais je n’ai pas encore réussi à mettre cette méthode en pratique. Mon code est beaucoup plus orienté logique que pur algorithme, donc l’écriture de tests reste floue.

    • Après 16 ans comme développeur professionnel, j’ai le sentiment que Claude Code m’a aidé à résoudre bien plus facilement des choses sur lesquelles je me serais arraché les cheveux. Quand il faut apprendre rapidement quelque chose de nouveau, les outils d’IA — en particulier le mode « ask » basé sur les questions-réponses — sont efficaces ; j’utilise activement les analogies, les cas pratiques et les moyens mnémotechniques. Si l’objectif est un apprentissage profond par progression lente, mieux vaut la méthode classique, même si elle est plus lente. Mais si l’objectif est d’apprendre vite, recourir à l’IA n’est pas une mauvaise option. Si l’on veut surtout obtenir un résultat, il est important de bien écrire la spécification et de soigner les tests. Au fond, quelle que soit la méthode, je pense que ce qui a du sens, c’est de continuer à construire des choses.

    • Il y a eu à une époque une tendance sur les blogs consistant à dire : « crée ta propre bibliothèque x ». C’est en implémentant soi-même quelque chose qu’on apprend le plus. Par exemple, si vous voulez comprendre un routeur côté client, créez-en un vous-même. À l’ère des LLM, n’importe quoi peut être remplacé par du code de bibliothèque, mais si je veux vraiment apprendre le C#, mieux vaut faire le portage moi-même. Si j’ai simplement besoin du résultat et que je veux me concentrer sur autre chose, je peux le confier à Claude. L’apprentissage comporte forcément une phase de douleur, et si c’est trop facile, en réalité on n’apprend rien.

    • Avant l’IA, le copier-coller régnait en maître. Ceux qui piquaient du code sur Stack Overflow sans en comprendre la raison n’apprenaient finalement rien. Je n’ai aucun problème avec le fait de demander à l’IA des conseils ou des explications de concepts. Mais si on lui demande d’écrire tout à notre place, il n’y aura clairement pas d’apprentissage. Cela dit, protéger son temps en tant que développeur est aussi une démarche intelligente. Il y a tant de choses à apprendre que, si votre objectif est de faire du développement de jeux, le travail de portage de GDscript n’est peut-être pas une expérience indispensable. Bien sûr, on y apprend quand même certaines choses.

  • Après environ trois semaines de codage avec Claude Code, je travaille depuis 10 ans surtout en Python ML et data engineering. J’y vois plusieurs raisons :

    1. Il supprime la douleur du démarrage, donc il n’y a plus de barrière pour écrire la première ligne.
    2. Pendant qu’il exécute, on peut consacrer son esprit entièrement à la réflexion.
    3. On peut mener plusieurs tâches en parallèle.
    4. Si quelque chose me vient à l’esprit que j’aurais dû traiter, je peux immédiatement ouvrir une nouvelle session Claude et le tenter tout de suite (je ne laisse plus de TODO derrière moi).
    5. L’analyse, la visualisation, les graphiques, etc., peuvent aussi être facilement automatisés via des scripts.
    6. Les petits problèmes de lint, de type ou de tests sont réglés automatiquement. Globalement, cela permet de se concentrer uniquement sur l’essence du code : ce qui doit être fait, si le résultat est correct, et comment l’améliorer.

    • Le fait de supprimer la douleur du démarrage est vraiment énorme. Avant, il y avait plein de choses que je me disais vouloir faire « si j’avais le temps » ; aujourd’hui, quelques prompts suffisent pour les exécuter. J’ai par exemple voulu recréer le jeu NYT Connections dans le terminal, et c’était terminé en trois prompts (https://github.com/jleclanche/connections-tui).

    • Le point 4 est particulièrement marquant. Avant, il était normal de laisser des tests ou de la dette technique de côté, mais maintenant il suffit de dire « il faut une suite de tests » pour obtenir automatiquement quelque chose d’assez correct. Ce n’est pas forcément parfait, mais cela permet clairement de traiter des tâches de difficulté intermédiaire.

  • Faisant partie de la petite minorité curieuse qui continue d’essayer le codage basé sur des agents, je me suis demandé pourquoi mon expérience différait autant de celle du courant dominant. L’explication ci-dessous me semble centrale :

    « Avec Claude Code, nous en sommes à l’équivalent, pour la programmation, de l’arrivée de la photographie : l’élan qui poussait à dessiner à la main disparaît simplement parce qu’on peut transformer immédiatement une idée en réalité, puis la sculpter dans la forme désirée grâce à sa capacité de revue et d’édition de code. » Cette analogie est pertinente, mais les gens continuent quand même à peindre, certains paient pour acheter des tableaux, et d’autres aiment coder comme une forme d’art. Pour ma part, coder moi-même est un hobby, et je n’aime pas les code reviews, même si je les fais par nécessité. Si j’ai le choix, je préfère construire directement moi-même (c’est d’ailleurs pour cela que je reste IC). Beaucoup comparent les agents de codage IA à des stagiaires ou juniors, mais moi, je les trouve plutôt inquiétants.

    • Je me demande si nous sommes toujours dans un monde où des gens peignent encore et paient pour des tableaux. La plupart des métiers artisanaux supplantés par des procédés standardisés et industrialisés semblent aujourd’hui tirer leur valeur moins du produit lui-même que de l’expérience mutuelle entre producteur et consommateur, nourrie par l’imagination. On ne commande pas seulement un objet sur Amazon : la relation avec l’artisan et le récit du processus créatif deviennent eux-mêmes des objets de consommation. J’ai l’impression que le codage devra peut-être évoluer dans ce sens pour survivre.

    • Je comprends très bien ce point de vue. Je reconnais l’utilité du codage par agent pour de petites tâches, des corrections de bugs, des brouillons. En revanche, je ne comprends pas l’intensité du débat pour ou contre à propos de multiples interfaces habillant un petit nombre de modèles. Quant à l’impact pour les développeurs juniors, je m’interroge encore. Si l’IA pouvait aussi automatiser la code review, ma vie serait encore plus agréable.

    • Je ne pense pas que l’analogie soit totalement valide. Historiquement, la peinture était l’unique moyen de représenter le monde réel, alors que l’art ne se limite pas à la reproduction mais relève de l’interprétation de son créateur. C’est pourquoi les gens continuent à peindre. Si l’on considère le code comme une forme d’art, on peut continuer ainsi. Mais pour beaucoup, l’objectif est de développer un produit, et le produit lui-même peut être l’art. Si l’IA permet d’atteindre plus vite cet objectif, pourquoi ne pas la choisir ? D’un autre côté, l’époque du « code monkey » me manque un peu parfois. On se dirige peut-être vers une situation où tout le monde devra agir comme un lead developer, en se concentrant sur la direction, la review de code et les décisions techniques. Je trouve un peu regrettable ce recul du travail de code direct au quotidien.

    • Une analogie plus appropriée serait le passage des outils manuels aux outils électriques. L’analogie peinture-photographie ressemble trop à l’apparition d’un nouveau média et me paraît exagérée. Le codage par agent n’est pas révolutionnaire à ce point.

  • J’ai essayé d’utiliser beaucoup Claude Code, mais c’est trop lent, il y a toujours quelque chose qui déraille, et c’est frustrant. Pour la plupart des tâches, je n’ai pas le sentiment d’économiser mon énergie mentale. Il m’a aidé sur quelques cas, mais j’ai aussi eu trop souvent de mauvaises surprises, au point de ne pas avoir envie de l’utiliser fréquemment. Par exemple, je lui ai demandé de convertir un .zshrc en nushell ; après 30 minutes d’efforts, cela ne fonctionnait toujours pas, alors qu’aller lire la documentation officielle m’aurait pris moins de 10 minutes. Ce genre d’expérience décevante me donne vraiment peu envie de revenir à Claude.

    • J’ai eu une expérience assez similaire. J’ai essayé de me faire aider pour écrire des tests, mais j’ai fini à chaque fois par tout réécrire moi-même. Je n’ai jamais obtenu de résultat convaincant en débogage. Cela reste seulement utile pour de très simples conversions de scripts (par exemple parser la sortie d’une commande) ou pour générer le squelette d’un nouveau projet — mais au fond, à quelle fréquence fait-on réellement ce genre de choses ? C’était correct pour de petits portages de code, mais mes échecs ont été bien plus nombreux que mes réussites.

    • Je me demande si vous avez essayé quelque chose comme context7 MCP. Les LLM ont tendance à être faibles sur les langages peu populaires ou les domaines obscurs. Une approche où l’on va chercher directement les références dans des sources récentes, comme avec context7, me semble meilleure.

  • À cause du RSI et du syndrome du canal carpien, j’avais fini par moins coder, mais grâce à Claude, je peux programmer à nouveau, avec une douleur réduite à un dixième. C’était une technologie que j’aurais presque préféré rejeter, mais si je veux poursuivre ma carrière, elle est désormais indispensable.

    • J’ai entendu beaucoup d’histoires similaires. Pour les personnes souffrant de RSI, des outils comme Claude sont de véritables game changers, parce qu’ils rendent bien plus faciles les tâches répétitives les plus pénibles et ennuyeuses, comme le boilerplate. Avant, rien que voir du code répétitif me faisait mal aux poignets et au moral ; maintenant, je n’ai plus à m’en soucier et je peux me concentrer sur des problèmes plus abstraits ou nouveaux, ce qui rend la programmation elle-même plus agréable. Certains craignent que ce genre d’outils puisse mettre fin à leur carrière, mais je pense au contraire qu’ils vont sauver la mienne.

    • Depuis que j’ai commencé à utiliser Claude, mes douleurs liées au RSI ont presque disparu. On peut surtout remplacer beaucoup de tâches répétitives par des instructions très précises et bien formulées. J’ai aussi entendu parler de nombreux usages avec reconnaissance vocale, et cela donne l’impression d’ouvrir une vraie porte en matière d’accessibilité.

    • Je me dis que ce serait encore plus utile si l’on pouvait utiliser Claude Code directement à la voix. Sur MacOS, il existe des options TTS/ASR gratuites, et on peut aussi brancher d’autres moteurs vocaux en BYOK (https://github.com/robdmac/talkito).

    • Si vous utilisez une application de STT / reconnaissance vocale suffisamment précise et pratique, cela peut aussi être très efficace pour transmettre à Claude Code un contexte détaillé. Après avoir essayé plusieurs applis de reconnaissance vocale, celle qui me convient le mieux est Wispr Flow, grâce à son mode mains libres basé sur des raccourcis clavier ainsi qu’à sa précision et sa rapidité. J’aimerais simplement qu’elle prenne aussi en charge les applications locales.

    • J’aimerais savoir si vous saisissez déjà le texte à la voix.

  • Du point de vue de la maintenance, je suis tout à fait d’accord avec l’auteur. Avant, certaines tâches comme le refactoring ou des TODO/tickets servant de rappel étaient simplement notées pour plus tard, alors qu’avec Claude je les implémente immédiatement. Cela réduit énormément les efforts répétitifs. Il devient aussi très facile de tester rapidement des idées de refactoring puis de les abandonner si elles ne plaisent pas. L’énergie d’activation nécessaire pour ce type de travail a nettement baissé. Je suis d’accord aussi sur le fait que faire tourner sans supervision humaine des agents IA en parallèle ou hors ligne à l’aveugle peut au contraire conduire au burnout et à une baisse de la qualité du code ; il faut impérativement rester dans un mode de supervision humaine. J’ai aussi écrit un billet à ce sujet : https://www.modulecollective.com/posts/agent-assisted-coding...