Obtenir de bons résultats avec Claude Code

• Après avoir expérimenté divers agents de programmation LLM ces derniers mois, Claude Code s’est révélé être l’outil le plus satisfaisant
• Grâce à Claude Code, environ 12 programmes et projets ont pu être réalisés en peu de temps, y compris des travaux qui n’auraient normalement pas été lancés faute de temps
• Pour une utilisation réussie, les éléments clés sont la rédaction de spécifications claires, la mise à disposition d’une documentation expliquant la structure du projet ainsi que les commandes de build et de lint, la demande à l’IA d’effectuer sa propre revue de code, et l’usage d’un guide global d’agent personnalisé
• Le code écrit par l’IA pouvant souvent être inexact ou inefficace, il faut impérativement vérifier soi-même tout le code et tous les cas de test, puis ajouter les tests manquants ou demander à l’IA de les écrire avant de les revérifier
• Le guide global d’agent publié en annexe inclut des consignes de développement détaillées : plan d’implémentation par étapes, développement piloté par les tests, philosophie centrée sur la simplicité, la clarté et le pragmatisme, critères de qualité et processus de résolution de problèmes

---

Retour d’expérience et effets de Claude Code

• Ces derniers mois, divers agents de programmation LLM ont été testés, et l’expérience avec Claude Code a été de loin la meilleure
• Même si tout n’est pas parfait, il a été possible de terminer plus de 12 programmes et projets en peu de temps
• Sans Claude Code, il aurait été presque impossible d’accomplir tout ce travail sur la même période
• Nombre de ces tâches n’auraient même pas été tentées en raison du temps qu’elles auraient demandé

Stratégie d’utilisation de Claude Code

• Rédiger des spécifications claires
  • Avant de commencer le projet, documenter clairement les exigences et le contexte pour les fournir à l’agent
  • Cela permet de clarifier l’orientation et le périmètre de l’écriture du code
• Documenter la structure du projet
  • Préparer une documentation incluant la manière d’exécuter le build, le lint et les tests
  • L’agent peut ainsi explorer la base de code et travailler plus efficacement
• Demander une revue de code à l’agent
  • Faire relire par Claude Code le code qu’il a généré permet de découvrir des pistes d’amélioration ou des bugs inattendus
• Utiliser un guide global personnel
  • Maintenir un processus de développement cohérent via ~/.claude/CLAUDE.md, qui contient des règles personnelles sur l’approche de résolution de problèmes, l’application du TDD, le maintien de la simplicité et de la clarté, ainsi qu’une limite de trois tentatives

Validation du code écrit par les LLM

• Le code généré par l’IA présente souvent des problèmes comme des erreurs logiques, des baisses de performance ou des tests incomplets
• L’auteur relit manuellement tout le code et vérifie son fonctionnement
  • il ajoute lui-même les cas de test manquants
  • ou demande à l’IA de les écrire, puis revoit à nouveau le code et les tests
• Il souligne que, dans un environnement professionnel, dès lors que son nom figure sur une PR, la responsabilité finale de la qualité lui revient

Principaux éléments du guide “global” personnel de l’agent

Ce guide est géré dans le fichier ~/.claude/CLAUDE.md

• Philosophie et principes fondamentaux

  • Progression incrémentale : modifier par petites unités, avec compilation et tests toujours au vert
  • Apprendre du code existant : analyser les patterns du code et établir un plan avant l’implémentation
  • Pragmatisme avant tout : adopter une approche flexible adaptée au contexte du projet
  • Clarté avant tout : écrire un code lisible et explicite, en évitant les astuces inutiles

• Définition de la simplicité

  • les fonctions et classes ont une responsabilité unique
  • éviter l’abstraction prématurée
  • réduire la complexité et viser un code qui n’a pas besoin d’être expliqué

• Processus de travail

  • 1. Planification et définition des étapes :
    • les tâches complexes sont divisées en 3 à 5 étapes et consignées dans IMPLEMENTATION_PLAN.md
    • pour chaque étape, préciser l’objectif, les critères de réussite, les cas de test et l’état d’avancement
  • 2. Flux d’implémentation :
    • compréhension → écriture des tests (rouge) → implémentation minimale (vert) → refactorisation → commit
  • 3. Réévaluation après une limite de 3 tentatives :
    • en cas d’échec, consigner les tentatives, les erreurs et leurs causes
    • explorer des alternatives (2 à 3 approches)
    • revoir en profondeur la conception ou la décomposition du problème
    • essayer d’autres patterns ou fonctionnalités

• Standards techniques

  • Composition en priorité, avec recours à l’injection de dépendances
  • Utiliser des interfaces pour faciliter les tests
  • Flux de données explicite
  • TDD recommandé, interdiction de désactiver les tests

• Règles de qualité du code

  • chaque commit doit compiler, passer les tests, inclure des tests pour les nouvelles fonctionnalités et respecter le style du code
  • avant un commit, exécuter le formateur et le linter, faire une auto-revue des changements et écrire un message de commit expliquant le « pourquoi »

• Gestion des erreurs

  • échec rapide avec messages précis
  • fournir le contexte nécessaire au débogage
  • gérer les exceptions au bon niveau, sans les masquer

• Critères de décision

  • 1. facilité de test
  • 2. lisibilité compréhensible encore dans 6 mois
  • 3. cohérence avec les patterns du projet
  • 4. simplicité
  • 5. facilité de modification

• Intégration au projet

  • analyser au moins 3 fonctionnalités similaires
  • réutiliser les patterns et bibliothèques existants
  • utiliser les mêmes utilitaires de test
  • l’introduction d’un nouvel outil doit être solidement justifiée

• Quality gates

  • tous les tests passent
  • respect des règles du projet
  • aucun avertissement du linter
  • message de commit clair
  • implémentation conforme au plan
  • les TODO incluent un numéro d’issue

• Consignes de test

  • des tests centrés sur le comportement plutôt que sur l’implémentation
  • si possible, une seule assertion par test
  • des noms clairs décrivant le scénario
  • réutiliser les utilitaires de test existants
  • les tests doivent être déterministes

• Absolument interdit

  • contourner les hooks avec --no-verify
  • désactiver les tests
  • committer du code qui ne compile pas
  • faire des suppositions sans vérification

• À faire impérativement

  • des commits incrémentaux
  • mettre la documentation à jour en continu
  • apprendre des implémentations existantes
  • réévaluer l’approche après 3 échecs

Projets open source réalisés avec Claude Code

• Reverse proxy prenant en charge HTML/XML (cdzombak/xrp)
• Thème VS Code Solarized (clair/sombre) (cdzombak/dzsolarized-vscode)
• Générateur RSS pour photostream Flickr (cdzombak/flickr-rss)
• Outil de métadonnées pour la photothèque Lychee (cdzombak/lychee-meta-tool)
• Rapport d’état de verrouillage d’écran macOS via MQTT (cdzombak/macos-screenlock-mqtt)
• Définition automatique des titres de photos Bird Buddy dans Lychee (cdzombak/lychee-birb-title)
• Classement automatique de photos basé sur un LLM local (cdzombak/lychee-ai-organizer)
• Automatisation de l’installation groupée de logiciels pour macOS (cdzombak/mac-install)
• Projet de service RSS (cdzombak/rss.church)
• Export complet ou sélectif de photos Flickr avec conservation des métadonnées (cdzombak/flickr-exporter)
• Générateur de galerie HTML statique (cdzombak/gallerygen)