Specsmaxing : Lutter contre la psychose de l'IA avec des spécifications YAML et ACAI

Le dernier article de blog d'Acai.sh, « Specsmaxxing – Surmonter la psychose de l'IA, et pourquoi j'écris les specs en YAML », aborde le problème des agents IA qui déraillent lorsque les fenêtres de contexte se remplissent ou que les sessions expirent. L'auteur partage un workflow pratique : écrire des specs structurées en YAML au lieu de seulement en markdown, et utiliser des exigences numérotées (par exemple, AUTH-1, AUTH-2) que les agents peuvent référencer directement dans le code. Cette méthode, appelée Critères d'Acceptation pour l'IA (ACAI), est née lorsqu'un sous-agent a automatiquement numéroté les exigences et les a référencées dans l'implémentation, améliorant la traçabilité et réduisant les régressions.

L'article décrit un processus en quatre étapes : Spécifier (écrire les exigences en YAML), Livrer (laisser les agents implémenter), Réviser (vérifier le code par rapport aux specs), et Itérer. L'auteur admet avoir abusé des specs en markdown (PRD, TRD, docs d'architecture) et souffert de « psychose de l'IA » — passant plus de temps à construire des harnais d'IA qu'à développer des produits. L'approche YAML vise à être plus légère et plus exploitable par les machines.

Point clé : un simple README.md et AGENTS.md améliore déjà considérablement les résultats des agents. L'article soutient que le « Peak Slop » est dépassé et que les specs structurées sont la prochaine évolution. Un extrait de code illustre le modèle :

# Requirements
AUTH-1: Accepte l'en-tête `Authorization: Bearer <token>`
AUTH-2: Les tokens sont limités à l'utilisateur, donnant accès à toutes ses ressources
AUTH-3: Rejette avec 401 Non autorisé

// AUTH-1
const authHeader = req.headers["authorization"];
// AUTH-2
const isAuthorized = verifyBearerToken(authHeader);
// AUTH-3
if (!isValid) return res.status(401).json({ error: "Non autorisé" });

L'article passe également en revue des alternatives : GitHub SpecKit, OpenSpec, Kiro, Traycer.ai — et liste les raisons pour lesquelles acai.sh pourrait ne pas vous plaire (par exemple, surcharge, format dogmatique). C'est un point de vue pragmatique pour les développeurs qui veulent que leurs agents IA livrent du code fiable sans boucles constantes d'ajustements.

À qui cela s'adresse : Aux développeurs utilisant des agents de codage IA (Claude, Copilot, etc.) qui rencontrent des limites de contexte et recherchent une couche de spécifications légère pour garder les agents sur la bonne voie.