Claude Code au quotidien : produire un changement révisable
Définissez contexte, limites et validation pour une tâche réelle avec Claude Code, de l’enquête initiale au diff et aux tests.
« Améliore ce projet » laisse presque tout indéterminé. L’agent doit deviner priorité, comportement attendu et périmètre. Une demande utile commence par le problème, sa reproduction et le résultat acceptable.
Imaginons un formulaire perdant les données après une erreur serveur. Dans cet exemple fictif, l’objectif est de conserver la saisie et d’expliquer l’échec, sans remplacer la bibliothèque ni refaire l’application.
Établissez le départ avant de modifier
Vérifiez dossier, branche et changements existants. Notez les commandes fonctionnelles. Séparez identifiants et données réelles des éléments de test. Fournissez assez de contexte pour enquêter sans accès inutiles.
La documentation de Claude Code présente le mode planification pour lire et proposer avant modification, via claude --permission-mode plan.
Demandez un diagnostic avec fichiers concernés et hypothèse vérifiable. Si elle n’explique pas la reproduction, poursuivez l’enquête. Un plan convaincant doit correspondre au code découvert.
Donnez des limites au changement
Précisez les comportements à préserver et les modules utiles. Pour le formulaire, demandez de garder les valeurs après erreur, afficher une explication et permettre de réessayer. Incluez un cas réussi pour ne pas réparer un état en cassant l’autre.
Décidez des actions externes exclues. Des tests locaux diffèrent d’un envoi de messages, d’une modification de base partagée ou d’une publication. Les permissions doivent suivre les besoins concrets.
Examinez changement et preuves
Lisez le diff en cherchant modifications sans rapport, duplication et gestion d’erreur masquant seulement l’échec. Demandez les sorties des tests et vérifiez les cas réellement exécutés.
Dans l’exemple, soumettez avec une erreur simulée, vérifiez les champs conservés puis réessayez avec succès. Un test unitaire contrôle une fonction ; la navigation montre ce que perçoit une personne. Utilisez les deux pour des risques différents.
Transmettez un résultat compréhensible
Notez problème corrigé, comportement final, commandes et points ouverts. Si une intégration était indisponible, nommez la partie non vérifiée. Un terminal sans erreur ne prouve pas le fonctionnement du parcours entier.
Le gain utile est un changement arrivant en revue avec contexte et preuves. Moins le développeur suivant doit reconstruire le raisonnement, plus le résultat sera facile à maintenir.
Poursuivez avec quand répartir le travail entre agents.
À propos de l’auteur
Tiago F SantiagoCommentaires
Aucun commentaire pour le moment
Partagez une question ou une expérience en lien avec cet article.
Articles sur le même sujet
