Tutorial 4 Prompting and Reviewing fr

Tutoriel 4 · Prompting et revue

Objectif : la méta-compétence. Vous savez désormais construire une fonctionnalité avec un agent — ce chapitre porte sur la façon de le faire sans accroc et de façon reproductible : écrire des prompts qui font mouche du premier coup, passer en revue les diffs efficacement, itérer quand ça dérape et garder l'élan d'une session à l'autre.

← Précédent : Tutoriel 3 Votre première tâche avec l'agent · Suivant : Tutoriel 5 Localisation

---

Rédigez vos prompts comme un lead, pas comme une barre de recherche

L'agent est un ingénieur junior rapide, littéral et enthousiaste. Encadrez-le comme vous encadreriez un bon :

• Énoncez le but et les contraintes. « Ajoute endorse » est faible. « Ajoute endorse en suivant le patron de connect, uniquement le RNG à graine, avec des tests, la barrière reste au vert » est fort. Les contraintes, c'est ainsi que vous obtenez du code qui s'intègre.
• Pointez vers des exemples. « Suis le patron utilisé par renderConnect » vaut mieux qu'un paragraphe de description. Le code existant est la meilleure spéc.
• Demandez un plan avant les modifications pour tout ce qui n'est pas trivial. Rediriger un plan coûte peu ; défaire dix fichiers modifiés coûte cher.
• Une tâche par prompt. Regrouper « ajoute endorse, refactorise aussi le RNG, mets aussi à jour le README » produit un diff emmêlé et difficile à relire.
• Donnez-lui la barrière de tests. « Exécute npm test et ne considère pas que c'est terminé tant que ce n'est pas vert » transforme l'agent en quelque chose qui vérifie son propre travail.

Passez en revue le diff à chaque fois

La vitesse est tout l'intérêt d'un agent — mais la vitesse sans relecture est la façon dont les bugs sont livrés. Construisez un réflexe de revue rapide et régulier :

1. Portée : n'a-t-il changé que ce qu'il devait ? Des lignes sans rapport qui ont bougé sont un signal suspect.
2. Patrons : correspond-il au code environnant, sans nouvelles dépendances ni E/S dans src/ ?
3. Les règles du projet : pour ce dépôt, c'est uniquement le RNG à graine (cherchez Math.random dans le diff), le texte visible par l'utilisateur dans les paquets de langue (pas en dur), et les lignes de carte ne dépassent jamais la largeur à laquelle la mise en page complète.
4. Accessibilité : la nouvelle sortie survit-elle à --accessible ? Exécutez lockedin --accessible <your command> et vérifiez qu'elle se lit comme du texte brut et net — aucun nouveau glyphe décoratif ne se faufilant à travers a11yFilter.
5. Tests : y a-t-il un nouveau test, et échouerait-il vraiment si la fonctionnalité se cassait ? Demandez : « Quelle ligne devrais-je changer pour faire échouer ce nouveau test ? »
6. Exécutez-le : npm test, puis lancez la commande et regardez la sortie.

Vous n'avez pas besoin de comprendre chaque caractère — mais vous devez comprendre chaque décision. Si vous ne pouvez pas expliquer un changement, demandez à l'agent de l'expliquer avant de l'accepter.

Itérez quand ce n'est pas au vert

Une barrière au rouge est une étape normale, pas un échec. La solution, c'est un retour précis :

« npm test échoue avec : [paste the exact error]. Le test de largeur de renderEndorse attend que chaque ligne de carte fasse ≤ 60 colonnes visibles. Corrige-le sans affaiblir le test. »

Collez le texte réel de l'erreur. « C'est cassé » fait deviner l'agent ; la trace d'appel le fait corriger. Et préférez poursuivre la même conversation plutôt que d'en commencer une nouvelle — l'agent a déjà le contexte de ce qu'il vient d'écrire. Si deux ou trois itérations ne convergent pas, prenez du recul et redéfinissez la portée : la tâche est peut-être trop grosse pour un seul prompt.

Gardez l'élan d'une session à l'autre

Le vrai travail s'étale sur plus d'une séance. Deux habitudes gardent un agent efficace dans la durée :

• Mémoire / conventions. Si votre agent prend en charge une mémoire durable ou un fichier d'instructions de projet, notez-y les règles qu'il doit toujours suivre (p. ex. « tout l'aléatoire doit utiliser pick/shuffle », « lance npm test avant de déclarer que c'est terminé »). Vous énoncez une convention une fois au lieu de la répéter à chaque prompt.
• Une note de passation. Ce dépôt conserve un court document d'état, assaini, dans docs/HANDOFF.md : ce qu'est le projet, comment il est construit, comment il est testé et ce qui vient ensuite. Quand vous revenez (ou passez le relais à un coéquipier — ou à un autre agent), cette note reconstruit le contexte en quelques secondes. Demandez à votre agent de la tenir à jour dans le cadre d'un changement.

Des garde-fous à conserver

• La barrière n'est pas négociable. Des tests au vert avant toute livraison. C'est ce qui vous permet d'aller vite et de faire confiance à la sortie.
• C'est vous le relecteur officiel. L'agent écrit ; vous décidez. Accepter un diff signifie que vous vous en portez garant.
• De petites étapes vérifiables valent mieux qu'un bond de géant. Chaque changement accepté devrait laisser l'appli fonctionnelle.

---

✅ Essayez avec votre agent

1. Rédigez une spéc d'un paragraphe pour une commande mentor (« distribue des conseils non sollicités »), contraintes incluses, et faites-la construire par l'agent avec les tests d'abord — plan, tests, code, barrière — en passant en revue à chaque étape.
2. Demandez à l'agent de mettre à jour docs/HANDOFF.md pour mentionner la nouvelle commande.
3. Cassez délibérément quelque chose (p. ex. supprimez une entrée de pool), lancez npm test, et entraînez-vous à donner à l'agent l'échec exact à corriger.

---

Où aller ensuite

• Survolez le vrai code dans src/lockedin.js — vous en connaissez maintenant la forme.
• Lisez docs/HANDOFF.md pour les notes d'état et d'architecture du projet lui-même.
• Profitez des blagues dans la Référence des commandes.

Voilà le tutoriel. Vous pouvez désormais diriger un agent IA pour construire et modifier de vrais logiciels derrière une barrière de tests — avec l'exemple le plus imbu de lui-même que l'on puisse imaginer. D'accord ? 👇