Specsmaxxing : quand les specs sauvent ton IA de la folie
Pourquoi ça compte pour toi
Si tu utilises des agents IA pour coder, tu as remarqué : plus tu ajoutes de contexte, plus ça déraille. Les specs écrites sauvent ta santé mentale ET la qualité du code. L'auteur (dev expérimenté) propose un système concret : numéroter chaque exigence, la référencer dans le code, suivre sa couverture comme du vrai test coverage. C'est du spec-driven development, mais pour l'ère des agents.
Ce qu'il faut retenir
- 1.Les specs en markdown suffisent déjà, mais structurer avec YAML + numérotation (ACIDs) c'est mieux
- 2.Référencer les exigences dans le code (AUTH-1, AUTH-2) crée un lien code↔spec qu'on peut tracer
- 3.Acai.sh : boîte à outils open-source (CLI + dashboard) pour pousser tes specs et les réviser par exigence, pas par fichier
Pourquoi tes agents déraillent (spoiler : c'est ta faute)
Quand tu enchaînes des agents — spec → code → tests → review — tu oublies l'étape 0 : écrire clairement ce que tu veux. Résultat : contexte qui explose, détails perdus, et un agent qui invente ses propres règles.
L'auteur appelle ça « AI psychosis » : tu passes des heures à écrire des PRD soignés, tu crées un agent qui crée des agents qui lisent tes PRD, et au final… c'est toujours un peu pourri. Moment charnière : au lieu de complexifier le pipeline, il a écrit une spec encore plus simple.
Les ACIDs : numérotation = traçabilité
Un jour, l'auteur remarque que son agent a spontanément numéroté les exigences :
AUTH-1: Accepts `Authorization: Bearer <token>` header
AUTH-2: Tokens are user-scoped
AUTH-3: Rejects with 401 Unauthorized
Et ensuite il a référencé AUTH-1, AUTH-2, AUTH-3 dans le code. Première réaction : c'est du couplage serré, dégueulasse. Deuxième réaction : attends, c'est utile. Tu peux naviguer une PR énorme en cherchant « AUTH-3 » et voir exactement où l'exigence est implémentée ET testée.
C'est du acceptance-coverage tracking au lieu du test-coverage. Beaucoup moins de bruit.
Acai.sh : la couche d'outillage
Du coup il a construit une boîte à outils open-source (Apache 2.0) :
- ▸feature.yaml : gabarit pour écrire tes specs en YAML structuré, pas du markdown flou
- ▸CLI : numéroter automatiquement, valider, pousser dans le dashboard
- ▸Dashboard : réviser par exigence, marquer comme Completed/Accepted/Rejected, pas file-by-file GitHub
- ▸JSON REST API : ton CI/CD peut intégrer
acai pushdans une GitHub Action
La version hébergée (app.acai.sh) reste gratuite pour l'instant. Code sur GitHub.
Comment ça s'utilise
Étape 1 : Spécifier Tu écris ton feature.yaml avec des sections (AUTH, ENG, etc.), chaque exigence est numérotée.
Étape 2 : Livrer Tu copies un prompt donné, tu le passes à ton agent. Si l'agent est coopératif, il va spontanément référencer AUTH-1, AUTH-2 dans le code.
Étape 3 : Réviser Tu vas sur le dashboard, tu vois chaque exigence, son statut, le code/test qui la satisfait.
Point honnête
C'est pas une révolution technique. C'est du spec-driven development que tes profs te prêchaient en 2005. Mais en 2026, avec des agents qui peuvent lire YAML et générer du code référencé, ça redevient pertinent.
La vraie leçon : les agents codent mieux si tu leur dis exactement ce que tu veux, plutôt que d'espérer qu'ils devineront. Radical.
Essayer maintenant
Explorer Acai.sh et ses templates →Source
Pour aller plus loin
Cet article t'a donné envie d'approfondir ? Deux formations Noésis t'attendent :
Explorer les thèmes de cet article :