Donnez toujours à Claude un moyen de vérifier son propre travail, qu'il s'agisse de tests, d'une build ou d'une comparaison de captures d'écran. Une session vérifie son propre travail et corrige ses propres erreurs avant qu'un ingénieur ne les voie.
La boucle de rétroaction ne doit pas être confondue avec un sous-agent vérificateur (Étape 3 : Construire). La boucle de rétroaction s'exécute tout au long de la tâche, autant de fois que le travail l'exige. Le sous-agent vérificateur, quant à lui, est une façon de conditionner la vérification finale en exécutant une nouvelle fenêtre de contexte une fois que la session estime que le travail est terminé. Ainsi, le verdict n'est pas influencé par les hypothèses qui ont produit le code.
Ce qui change
| Traditionnel | Natif IA |
|---|---|
| Le signal indiquant que le code fonctionne arrive tard. L'intégration continue (CI) quelques minutes plus tard, un testeur quelques jours plus tard, la production quelques semaines plus tard. Avec un agent produisant le code, un signal tardif signifie qu'une personne doit vérifier l'ensemble de sa production, et cette personne devient le goulot d'étranglement. | La session dispose d'un moyen de vérifier son propre travail avant qu'une personne ne le voie. Exécutez les tests, exécutez la build, prenez la capture d'écran. Claude itère jusqu'à ce que la vérification réussisse, de sorte que ce qui parvient à l'ingénieur l'a déjà franchie. La mise en place de la boucle incombe à l'ingénieur qui exécute la session, et les étapes ci-dessous sont rédigées à son intention. |
Pour commencer
- Prérequis : Aucun.
- Infrastructure : Une suite de tests et une build qui s'exécutent localement avec une seule commande chacune. Pour le travail sur l'interface utilisateur, il est crucial que Claude dispose d'un moyen de voir le résultat, que ce soit un outil de navigateur ou un utilitaire de capture d'écran connecté via MCP.
Comment l'exécuter
- Si la vérification du travail nécessite aujourd'hui une séquence de commandes et une certaine connaissance de l'environnement, regroupez-la dans une cible unique telle que
make testounpm testqui se termine avec un code non nul en cas d'échec. - Dans la section Commands du
CLAUDE.md, listez chaque commande avec un exemple de sortie saine. - Définissez un objectif et rendez-le quantifiable afin que Claude puisse vérifier le travail sans vous le demander, par exemple : « Tous les tests de
test_status.pypassent », « la capture d'écran correspond à la maquette jointe », ou « le endpoint renvoie 200 avec le nouveau champ ». - Pour les corrections de bugs, écrivez d'abord le test qui échoue. Demandez à Claude de reproduire le bug sous forme de test, de l'exécuter, et de confirmer qu'il échoue pour la raison attendue. Validez (commit) ce test. Ce n'est qu'ensuite que vous demandez à Claude de le faire réussir sans modifier le test, le hook sur les fichiers de test de la dernière étape faisant respecter cette restriction. Un test qui existait avant la correction, et que l'agent n'a pas pu réécrire, constitue la preuve que le bug a disparu.
- Pour le travail sur l'interface utilisateur, bouclez la boucle avec une vérification visuelle. Donnez à Claude un navigateur ou un outil de capture d'écran, donnez-lui la maquette, et laissez-le itérer. Implémenter, capturer, comparer et ajuster. Deux ou trois cycles sont normaux, et le résultat devrait s'améliorer à chaque fois.
- Faites de la vérification une partie intégrante du « terminé ». L'instruction se trouve dans
CLAUDE.md: « Exécutez les tests avant de signaler qu'une tâche est terminée, et montrez la sortie. » - Enfin, la boucle elle-même doit être protégée, car un agent qui corrige du code ne doit pas pouvoir affaiblir la vérification de ce code. Un hook qui bloque les modifications des fichiers de test pendant une tâche de correction permet cela. L'alternative consiste à vérifier le diff lors de la revue et à rejeter toute modification qui touche un test.
À quoi cela ressemble
Bloc de vérification CLAUDE.md :
markdown
## Verifying your work
- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)
Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.Considérations de gouvernance
- Ce qui est imposé : La vérification avant qu'une tâche ne soit signalée comme terminée, et le blocage de l'agent modifiant les fichiers de test pendant une tâche de correction, tous deux implémentés sous forme de hooks là où l'organisation souhaite les garantir.
- Ce qu'est la preuve : La sortie littérale de
make test, le journal de build, ou la comparaison de captures d'écran que Claude a exécutée et collée, de sorte que la preuve provient de la chaîne d'outils. - Où cela est consigné : Dans la transcription de la session, que l'export OpenTelemetry transmet à la pile d'observabilité de l'organisation, et dans l'exécution de vérification de la PR, où le relecteur et tout auditeur ultérieur peuvent tous deux la consulter.
- Qui approuve : Le propriétaire du code qui relit la PR, et qui peut se concentrer sur l'intention et le risque car la preuve mécanique est déjà jointe.
Comment le mesurer
- Indicateur avancé : Le taux de réussite de la CI dès la première tentative pour les modifications écrites par l'agent, que le système de CI prend déjà en charge.
- Indicateur retardé : Le temps de revue par PR (à partir des métadonnées de la PR), qui devrait diminuer une fois que les tests détectent ce que les relecteurs détectaient auparavant, ainsi que le taux d'échec des modifications issu d'un outil de suivi des incidents.