Le plan d’abord : réviser et orienter le plan de l’agent

Une mauvaise direction coûte une phrase à corriger dans un plan, et une heure à corriger dans un diff. C’est tout l’argument pour planifier d’abord.

Pour toute tâche plus grosse qu’un correctif rapide, je demande à l’agent de lire le code et de proposer un plan avant de toucher à un fichier. Ensuite, je révise le plan comme je réviserais l’approche d’un collègue au tableau blanc.

La boucle « plan d’abord »

1. 📋BriefObjectif et critères d’acceptation
2. ↓→
3. 🔎PlanL’agent lit le code, propose des étapes, sans modifier
4. ↓→
5. 🧐RevueVous vérifiez l’approche et les signaux d’alarme
6. ↓→
7. 🎯OrienterDes corrections courtes et précises
8. ↓→
9. ⚙️ExécuterL’agent bâtit selon le plan approuvé

↺ Replanifier quand la réalité contredit le plan

Certains agents ont un mode de planification dédié, en lecture seule. Si le vôtre n’en a pas, demandez-le simplement en mots clairs.

Lis le brief ci-dessous. Avant de modifier quelque fichier que ce soit,
explore le code pertinent et réponds avec un plan :

1. Ce que tu as trouvé : les fichiers et patterns qui comptent, en 3 à 6 puces
2. Ton approche, en étapes numérotées assez petites pour un commit chacune
3. Les fichiers que tu vas créer ou modifier
4. Tes hypothèses et tes questions pour moi
5. Comment tu vas vérifier chaque critère d'acceptation

N'écris pas de code tout de suite. Attends mon go.

[brief]

La partie « hypothèses et questions » est la plus précieuse. C’est là que l’agent vous dit ce qu’il a dû deviner.

Signaux d’alarme dans un plan

Retournez les cartes. Chaque recto est quelque chose que je vois souvent dans les plans d’agents, chaque verso, ce que j’en fais.

🃏 Signaux d’alarme d’un plan

Touchez une carte pour la retourner

Il invente un nouvel utilitaire alors qu’un existe déjàPointez l’existant par son chemin : « Utilise plutôt formatMoney dans src/lib/money.ts. »Il touche à des fichiers inattendusDemandez pourquoi. Soit il a trouvé quelque chose qui vous a échappé, soit il sort du périmètre.Aucune mention des testsDemandez comment chaque critère d’acceptation sera vérifié, et où iront les nouveaux tests.Des étapes vagues comme « mettre à jour la logique »Demandez les fonctions précises et le changement de comportement attendu.Zéro question, zéro hypothèseLouche sur une tâche non triviale. Demandez : « Qu’est-ce que tu as dû supposer? »Il ajoute une dépendanceVérifiez qu’elle est nécessaire. Souvent, la librairie standard ou un package existant fait déjà le travail.Une seule étape géante à la fin : « implémenter la fonctionnalité »Demandez-lui de la découper en commits que vous pourriez réviser un à la fois.

Orienter en quelques lignes

Quand le plan est bon à 80 %, ne le réécrivez pas. Répondez à ses questions, corrigez les points précis, puis approuvez.

Une fois l’exécution lancée, le plan n’est pas sacré. Si l’agent tombe sur quelque chose que le plan n’avait pas prévu, je veux qu’il s’arrête et le dise, pas qu’il improvise en silence. J’ajoute une ligne au brief : « Si le plan n’a plus de sens, arrête-toi et dis-le-moi. »

Avant de continuer

✅ À retenir

0 / 5 complété

• Pour les tâches non triviales, j’obtiens un plan avant qu’un seul fichier soit modifié.
• Je demande les hypothèses et les questions, et je les lis en premier.
• Je cherche les signaux d’alarme : utilitaires réinventés, fichiers surprises, pas de tests, étapes vagues.
• J’oriente avec des corrections courtes et précises au lieu de réécrire le plan.
• Je demande à l’agent de s’arrêter et de me le dire quand le plan n’a plus de sens.

↺ Réinitialiser