Freebuff en pratique : lire du code écrit par un agent avant de le merger

Une suite de tests verte n’est pas une relecture

Les tests vérifient les cas auxquels quelqu’un a pensé. Un agent qui modifie un comportement peut laisser tous les tests verts, parce qu’ils ne vérifiaient l’ancien comportement que vaguement, ou parce que rien ne couvrait ce chemin. Le vert prouve que le changement s’exécute, pas qu’il est juste.

Le résumé soigné n’y change rien : la description de ce que l’agent a fait est une affirmation du système qui a fait le changement. Lisez le diff, pas la note de couverture, et traitez les tests comme un signal parmi d’autres.

Partir d’un état propre et réversible

Avant le premier prompt : commitez ou stashez votre travail, créez une branche et sachez précisément comment revenir. Un agent de code avec accès au terminal peut lancer des migrations, réécrire la configuration et supprimer des fichiers ; un point de départ réversible transforme un accident en désagrément.

Si la tâche touche des données réglementées ou confidentielles, utilisez une copie jetable du projet et une conversation sans secrets. Les conditions et la documentation sur les données de l’éditeur décident de ce qui quitte votre machine : lisez-les au lieu de supposer la frontière.

Lire le diff dans l’ordre où ça fait mal

Un gros changement généré se relit plus sûrement dans un ordre choisi que de haut en bas.

• Points d’entrée : routes, gestionnaires, permissions et tout ce qui change qui accède à quoi.
• Données : schéma, migrations, sérialisation et requêtes, surtout ce qui supprime ou réécrit.
• Configuration : variables d’environnement, étapes de build, CI et réglages de déploiement.
• Le reste : nommage, structure, duplication et les retouches cosmétiques qui gonflent le diff.

Lisez ensuite les tests ajoutés et demandez ce qu’ils ne couvrent pas. Un agent qui a écrit le code et le test peut inscrire deux fois la même erreur de compréhension.

Dépendances, secrets et les lignes que personne ne lit

Les nouvelles dépendances sont le risque le plus discret d’un patch généré : un nom de paquet familier, une version sortie de nulle part, un lockfile réécrit en entier. Vérifiez ce qui a été ajouté, pourquoi, et si le projet n’avait pas déjà l’équivalent.

Cherchez les identifiants, jetons et URL internes qui ne devraient pas être commités, et vérifiez que les logs n’exposent pas de données clients. Ce sont les lignes qu’on survole — et précisément celles pour lesquelles un agent n’a aucune raison d’être prudent : il optimise pour la demande, pas pour votre modèle de menace.

Quand tout jeter

Si le diff est plus gros que la tâche, si vous ne pouvez pas expliquer un bloc sans deviner, ou si le changement traite le symptôme plutôt que la cause, supprimez la branche. Repartir avec une demande plus étroite coûte moins cher que maintenir du code que personne ne comprend.

La même règle vaut pour votre prompt : la liste de relecture de notre guide Manus et les conseils de structure de notre guide Prompt Cowboy raccourcissent tous deux le diff. Pour le produit, commencez par notre présentation de Freebuff, et notre façon de traiter les liens de parrainage est décrite dans la mention d’affiliation.