TL;DR
La nuit du 30 septembre, l'agent de Jah a produit 5 884 lignes de documentation et 20 lignes de code de production — un rapport de 290 pour 1. Aucun lot n'est arrivé en ligne. Le diagnostic est écrit et assumé. Ce qui manquait, on est allé le chercher chez trois méthodes qui, elles, livrent : Claude Code, Codex et aider. Elles se rejoignent sur six points, dont deux qui font mal : le contexte a un budget, et un excès dégrade le résultat ; une revue porte un diff ou la prod, jamais un plan. Jah adopte huit règles outillées et remet la livraison d'abord. Quatre documents et une skill en sortent.
Le problème, chiffré
Du 29 septembre 23 h 27 au 30 septembre 06 h 45, sur la branche principale :
| Mesure | Valeur |
|---|---|
| Lots livrés en production | 0 sur 22 |
Lignes ajoutées au code produit (src/, ui/, migrations/) | +20 |
Lignes ajoutées aux plans, fiches, prompts, audits, STATUS, CHANGELOG | +5 884 |
| Ratio documentation / code | ~290 pour 1 |
| Audits successifs, tous sur le plan | 10 |
| Nombre de vagues, selon la source citée | 10, puis 9, puis 11, puis 7 |
Sept endroits disaient « où on en est », et ils ne disaient pas la même chose. Deux relais écrits à 33 minutes d'écart se contredisaient, et l'un des deux recommandait une suppression qui aurait détruit trois fichiers uniques.
Ce n'est pas un problème d'intelligence : les audits ont trouvé trois vrais défauts qui auraient cassé la production. C'est un problème de méthode.
Ce que font Claude Code, Codex et aider
On a lu leurs dépôts et leurs docs, pas leurs slogans. Chaque affirmation a son fichier.
Claude Code plafonne ses propres fichiers
Sa documentation de skills dit, mot pour mot : garder le fichier de skill entre 1 500 et 2 000
mots, et déplacer le détail dans des fichiers de référence, les exemples dans examples/, les
outils dans scripts/. Sa description de skill s'écrit à la troisième personne, avec des
phrases de déclenchement explicites.
Son outil de revue lance quatre agents qui notent chaque constat et ne publient que ceux au-dessus de 80 de confiance. Et sa consigne est plus intéressante encore : « si vous n'êtes pas certain qu'un problème est réel, ne le signalez pas — les faux positifs érodent la confiance et font perdre du temps au relecteur ». Les agents reçoivent le titre et la description de la pull request « pour aider à comprendre l'intention de l'auteur ».
Ses hooks couvrent un événement qui nous aurait servi : PreCompact, dont la fonction déclarée est
« préserver le contexte ». Le passage en contexte long n'est pas un accident : c'est un événement
traité.
Codex dit « remplacer », pas « empiler »
Codex concatène tous les fichiers d'instructions, de la racine du projet jusqu'au dossier courant. Mais quand la portée change, il prévient le modèle que les nouvelles instructions remplacent les précédentes, en toutes lettres.
C'est exactement notre maladie. Nos sept sources d'état ne se remplaçaient pas : elles s'empilaient, et l'agent devait deviner laquelle était vraie.
Codex a aussi deux mécanismes pour ne pas polluer le fil principal : /fork ouvre un fil dérivé,
et /side ouvre « une conversation latérale dans un fil temporaire sans polluer le fil
principal ». Son inventaire de coûts classe d'ailleurs chaque chose : tel élément est injecté à
chaque tour, tel autre seulement à l'appel d'outil.
Et son générateur de fichier d'instructions refuse d'écraser : « s'il existe déjà, ne le remplacez pas et ne le modifiez pas ». Nous avons fait l'inverse cette nuit — trois nouveaux fichiers de règles et un article pour les expliquer.
aider chiffre le contexte, et prévient quand il y en a trop
aider envoie une carte du dépôt avec un plafond de tokens réglable. Sa propre sortie affiche cet avertissement : « trop de code non pertinent peut troubler les modèles ». C'est la seule des trois méthodes qui écrit noir sur blanc qu'un excès de contexte dégrade le résultat.
Sa boucle est courte : le message de commit est généré depuis le diff, en une ligne, à l'impératif, 72 caractères maximum. Le lint tourne après chaque édition, pas à la fin du lot. Et aider mesure : ses rapports de benchmark sont reproductibles, et ses notes de version annoncent un chiffre (« aider a écrit 77 % du code de cette version »).
Nous n'avons aucun chiffre équivalent.
Ce que les trois disent ensemble
C'est là que ça devient difficile de discuter :
| Point | Claude Code | Codex | aider |
|---|---|---|---|
| Fichier de règles court, lu tôt | oui | oui | oui |
| Le détail vit ailleurs, à la demande | references/ | skills séparées | carte à budget |
| Le contexte a un coût | PreCompact | /side, inventaire | avertissement explicite |
| La revue porte un diff ou la prod | seuil ≥ 80 | régressions, diff entier | benchmark |
| L'exploration sort du fil principal | sous-agents | /fork, /side | --subtree-only |
| Boucle courte : éditer, vérifier, commiter | hooks | bac à sable | lint + commit auto |
Et une chose qu'aucune des trois ne fait : planifier 22 lots avant d'en livrer un.
Les huit règles que Jah adopte
Chacune est outillable — c'est la leçon la plus solide de la nuit : une règle outillée tient, une
règle écrite ne tient pas. Le lint a attrapé l'interdiction de || true que le plan interdisait
déjà en prose.
| Règle | Ce qui la fait tenir |
|---|---|
| Le contexte always-on est plafonné à 120 lignes par fichier | le lint le compte |
| Un état périmé se date et s'annule en tête | en-tête obligatoire |
| Un constat d'audit sans fichier, ligne et commande ne se publie pas | gabarit à trois champs |
| Un gros plan se lit dans un sous-agent | la session qui code n'ouvre qu'une fiche |
| Le lint tourne après chaque édition | pas de lot dit « fini » sans lint vert |
| Commit d'une ligne, impératif, 72 caractères, avec l'agent en trailer | relecture de l'historique |
| La planification plafonne à 15 % du temps | compteur dans le journal de vague |
| Un seul indicateur : le délai entre la demande et la mise en ligne | une colonne dans STATUS |
Et trois cases pour classer un travail, décidées en cinq minutes : bug-prod (moins d'une heure,
on le fait tout de suite, sans fiche), petite-feature (une demi-journée, un ticket et un test,
sans fiche technique), projet (plus d'un jour, ou touchant une migration ou la sécurité : fiche
courte et une décision humaine). Sur les 22 lots de la nuit, deux étaient des correctifs.
Le geste de fin de session, désormais obligatoire
C'est la vraie leçon de la nuit. Une session ne se termine pas sur « c'est fait ». Elle se termine
par six livrables, dans cet ordre : le code et son test, la release, STATUS et CHANGELOG dans
le commit de release, le commit de clôture, le relais — et l'article de blog.
Les deux derniers sont ceux qu'on saute, et ce sont eux qui coûtent le plus cher : sans eux, la session suivante repart de zéro et re-planifie. C'est le mécanisme exact de la nuit du 30.
Ce qui sort de cette veille
Quatre documents, une skill, et un plan de fond :
- une veille comparée avec ses sources et ses citations ;
- une discipline de livraison d'une page ;
- une skill « livrer » qui exécute la boucle d'un lot ;
- une file de lots suivants, un par un, avec leurs dépendances et leurs décisions ouvertes ;
- et la règle qui manquait : on écrit le plan du lot suivant pendant que la CI tourne, jamais avant de commencer.
Un mot d'honnêteté pour finir. Au moment où cet article est écrit, STATUS annonce une version
alpha.12 mais l'empreinte du paquet porte encore alpha.11 et aucun tag alpha.12 n'existe.
La leçon sur les sources d'état qui mentent vient de s'appliquer à nous, ce matin encore. La
prochaine étape n'est donc pas un document de plus : c'est de finir la fusion des deux lots déjà
écrits, de les mettre en ligne, et de noter le délai réel entre la demande et la mise en ligne.
Le fond de tâches est prêt. La discipline est écrite. Il ne reste qu'à livrer.