« Améliore cette page » laisse beaucoup de décisions ouvertes. La mise en page, les textes, les interactions, les dépendances. Codex peut proposer quelque chose de cohérent et passer à côté de ce que l’on voulait vraiment.
Avant de lui demander de coder, je préfère rendre le résultat attendu assez concret pour pouvoir le vérifier.
Décrire le résultat
Pour un formulaire de newsletter, « ajoute la gestion des erreurs » reste flou. Que voit la personne quand le service ne répond pas ? Son adresse reste-t-elle dans le champ ? Peut-elle réessayer ?
Ces questions donnent une consigne beaucoup plus utile.
Dans le formulaire de newsletter, affiche un message si l’inscription échoue.
Conserve l’adresse saisie et permets de réessayer.
Pendant l’envoi, empêche une seconde soumission.
Garde la mise en page et les dépendances actuelles.
Commence par lire le composant et la route serveur.
Vérifie le succès, l’erreur réseau et un double clic.
Ne fais aucun envoi réel, commit ou déploiement.
Le prompt décrit un comportement observable. On peut ouvrir la page, provoquer une erreur et regarder si le résultat correspond. Il indique aussi ce qui doit rester en place et ce qui n’est pas autorisé.
Donner le contexte qui manque
Un chemin de fichier, une capture et un exemple existant peuvent éviter beaucoup d’interprétation. Si une autre page utilise déjà le bon formulaire, autant le préciser. Si un visuel doit venir du projet, autant donner son emplacement.
Les règles qui reviennent à chaque tâche ont leur place dans un fichier AGENTS.md : les commandes de vérification, les conventions du dépôt et les opérations à ne pas effectuer. Les détails propres à une modification restent dans la demande.
Je garde aussi les secrets hors des prompts. Pour expliquer une intégration, les noms des variables et le comportement attendu suffisent généralement.
Relire le changement
Dans un dépôt Git, ces commandes permettent de commencer la revue. Les scripts pnpm sont ceux de ce portfolio. Adapte-les à ton projet. Elles ne créent pas de commit et n’envoient rien sur le dépôt distant.
git status --short
git diff --stat
git diff
pnpm build
pnpm typecheck
pnpm test
git diff ne montre pas le contenu des nouveaux fichiers non suivis. La première commande sert aussi à les repérer pour les ouvrir séparément. Et un script du dépôt reste du code à vérifier avant de l’exécuter.
Un message « terminé » n’est pas une preuve. Il faut regarder les fichiers modifiés, comprendre les nouvelles dépendances s’il y en a et essayer les cas qui peuvent échouer.
Des tests qui passent donnent une information utile, mais ils ne disent pas si un texte déborde sur mobile ou si un bouton est difficile à trouver. Pour une interface, je veux aussi voir la page et l’utiliser.
Quand une tâche devient difficile à relire, je préfère la découper. Corriger un état d’erreur, puis vérifier. Ajouter une interaction, puis vérifier. Chaque étape laisse une décision que l’on peut encore comprendre et reprendre.