Accélérer l’exploration
Je m’en sers pour comparer des approches, reformuler un problème, préparer des tests ou découvrir rapidement les zones d’un code que je connais moins. Le gain vient surtout de la vitesse avec laquelle je peux confronter une première idée.
Ne pas déléguer le jugement
Une réponse convaincante peut être fausse, incomplète ou inadaptée au contexte. Je vérifie le code, les documentations et les effets réels. Les tests et la relecture restent indispensables.
L’outil devient particulièrement utile lorsque je lui donne un objectif clair, les contraintes du projet et la possibilité d’inspecter les éléments nécessaires. Il complète l’expérience ; il ne la remplace pas.
Des usages très concrets dans une journée
Je peux lui demander de dresser la liste des conséquences possibles d’un changement avant de toucher au code, de proposer des cas limites pour un test ou de transformer des notes techniques en explication destinée à un client. Il m’aide aussi à maintenir le fil lors d’une tâche composée de nombreuses petites vérifications.
Pour une base de code existante, je préfère qu’il inspecte d’abord les conventions et les tests. Une solution générique, même correcte, devient un mauvais changement si elle ignore l’architecture du projet.
Ce que je refuse d’automatiser aveuglément
Je ne confie pas sans contrôle une migration de données, une décision de sécurité ou une action irréversible. Je ne colle pas non plus d’informations confidentielles dans un outil sans connaître le cadre dans lequel elles seront traitées.
Mon objectif n’est pas de produire davantage de code. C’est de réduire le temps passé sur les tâches mécaniques pour consacrer plus d’attention à la compréhension, à la qualité et aux conséquences d’une décision.