Développeur Passe des Spécifications aux Propositions pour les Sessions de Code Parallèle Claude

Le problème de l'approche par spécifications d'abord

Le développeur a rencontré des problèmes où la rédaction de spécifications détaillées au préalable conduisait à un code généré par l'IA qui était techniquement correct mais contextuellement erroné. La spécification disait "ajouter une limitation de débit aux points de terminaison d'authentification" mais n'incluait pas le contexte sur les approches précédemment rejetées (comme les jetons de crédit) ou les décisions d'implémentation (comme choisir Redis plutôt que Cloudflare pour la mise en scène). Cela créait des situations où l'IA faisait des choix raisonnables qui rouvraient des décisions déjà prises.

Mettre à jour les spécifications est devenu un mini-projet en soi, et au moment où les spécifications mises à jour étaient examinées, la base de code avait déjà dérivé. La spécification capturait le "quoi" mais perdait le "pourquoi"—tout le raisonnement, les alternatives rejetées et le moment des décisions étaient manquants.

L'alternative par propositions d'abord

Au lieu d'écrire des spécifications au préalable et de coder pour les respecter, le développeur rédige des propositions—de courts documents qui capturent pourquoi un changement se produit, ce qui a été considéré et rejeté, et ce qui est inclus ou exclu du périmètre. La spécification est mise à jour après que le code est intégré pour refléter ce qui a réellement été construit.

Exemple de comparaison :

• Une spécification dit : "Le système doit prendre en charge la limitation de débit."
• Une proposition dit : "Attaques par force brute détectées en production. Ajout d'une limitation de débit via fenêtre glissante + Redis (Cloudflare non disponible en mise en scène). Rejet du jeton de crédit en raison de problèmes de trafic en rafale. Périmètre : connexion + réinitialisation du mot de passe uniquement."

La proposition donne à l'IA (et aux futurs développeurs) une vue d'ensemble complète.

Flux de travail par propositions parallèles

Le développeur exécute plusieurs sessions Claude Code simultanément, chacune travaillant sur une proposition différente. Parfois, il crée des propositions concurrentes résolvant le même problème sous différents angles.

Flux de travail typique :

• Travailler sur 2-3 fonctionnalités/bogues/problèmes en même temps
• Créer 1 ou 2 propositions pour différentes approches par problème
• Lancer des sessions Claude Code pour chaque proposition à exécuter en parallèle
• Chaque session produit une PR GitHub
• Les PR GitHub servent de plateforme d'examen des propositions
• Examiner l'approche et le code ensemble
• Si deux propositions abordent le même problème différemment, choisir la meilleure et fermer l'autre
• Une fois les PR approuvées intégrées, demander à Claude d'implémenter les propositions
• Mettre à jour la spécification pour refléter les changements de code pour une référence rapide dans les futures propositions

La spécification devient un document vivant qui correspond toujours à la réalité au lieu d'un document aspirational qui dérive dès le premier jour.

Cycle PACE

Le développeur appelle ce cycle PACE (pour se souvenir des étapes) :

• Proposer : Rédiger une courte proposition avec contexte et raisonnement
• Approuver : Examiner sur la PR GitHub, approche (approuver, réviser, rejeter)
• Coder : L'IA implémente exactement ce qui a été proposé, rien de plus
• Évoluer : Mettre à jour la spécification pour refléter la nouvelle réalité