Lui faire confiance : vérifier les exécutions non supervisées
Vous avez confié une tâche à Claude et l'avez laissé s'exécuter sans surveiller chaque étape. Il indique maintenant avoir terminé. Avant de livrer ce travail, vous avez besoin d'un moyen de vérifier quelque chose que vous n'avez même pas supervisé. C'est cette vérification qui rend fiable l'utilisation de Claude Code en mode autonome.
L'idée ici est simple : vérifiez proportionnellement à la liberté que vous avez accordée à l'exécution. Si vous avez suivi les messages défiler lors d'une courte session, un coup d'œil rapide suffit. Mais une exécution sans surveillance, ou une tâche lancée en intégration continue sans personne pour la suivre, nécessite une vérification réelle. Personne n'a vu ce qui s'est passé, vous devez donc le reconstituer après coup.
Voici une façon de se le représenter. Moins vous avez surveillé, plus vous devez vérifier.
Gardez les exécutions sans surveillance en mode auto
Lorsqu'une exécution se déroule sans surveillance au travail, gardez-la en mode auto plutôt qu'en mode de contournement des autorisations. En mode auto, le classificateur continue d'examiner la plupart des actions pour détecter les dangers. C'est un filet de sécurité qui vaut la peine d'être conservé.
Mais soyez clair sur ce que ce filet fait et ne fait pas. Le classificateur ne juge jamais si le code est réellement correct. Il ne fait que signaler les actions dangereuses. Votre seuil de vérification reste donc exactement le même qu'avant. Fixez ce seuil en fonction du degré de non-supervision de l'exécution.
Commencez par le diff, pas par le résumé
Ne commencez pas par le résumé que Claude fait de ce qu'il a fait. Commencez par le diff lui-même.
- Exécutez
/code-reviewpour parcourir les modifications et signaler les problèmes. - Puis posez vos propres yeux sur
git diff.
Le piège, c'est un résumé bien ficelé qui se lit parfaitement, alors que le diff réel a touché un fichier que vous ne vous attendiez honnêtement pas à voir modifié. Le résumé ne vous le dira pas. Le diff, si.
Lisez donc ce qui a changé. Lisez d'abord les fichiers qui faisaient partie du plan, puis cherchez tout ce qui en sort. Un compte rendu soigné n'est pas une preuve de code propre.
Transformez les tests en verrou, pas en promesse
Le véritable verrou sur une exécution non supervisée, c'est de savoir si les tests sont passés, et si Claude les a réellement exécutés ou s'est contenté de l'affirmer. Ne laissez pas cela à la confiance. Câblez-le sous forme de hook pour que Claude ne puisse pas le contourner.
Deux hooks font l'affaire :
- Un stop hook qui exécute vos tests et refuse de terminer le tour en cas d'échec.
- Un post-tool-use hook qui effectue le linting et la vérification de types après chaque modification.
Le détail clé, c'est le code de sortie. Un hook qui se termine avec exit 2 renvoie directement l'échec à Claude. Claude lit cet échec et le corrige sans que vous ayez à le demander. Mieux encore, la vérification se déclenche à chaque exécution, que vous pensiez ou non à la demander.
Obtenez un second avis impartial
La revue de code par sous-agent que vous exécuteriez avant une pull request fonctionne aussi ici. Appliquez-la à une exécution non supervisée.
Ouvrez une nouvelle session ou un nouveau sous-agent et faites-lui examiner le code modifié sans aucune mémoire de la façon dont le code a été construit. N'ayant aucun enjeu dans l'approche, il repère ce que l'exécution d'origine a fini par se convaincre d'accepter. Un second relecteur avec un regard neuf trouve ce que l'auteur a rationalisé.
Pour résumer
Rendez la vérification aussi rigoureuse que l'exécution était non supervisée :
- Lisez le diff vous-même.
- Transformez les tests en hook qui verrouille le tour.
- Vérifiez les exécutions en mode headless à partir de leur résultat JSON et de leur code de sortie.
- Obtenez un second avis impartial sur tout ce qui compte.
Faites cela, et « Claude l'a fait pendant que je ne regardais pas » ne relève plus de la foi.