Introduction
Un constat s’impose rapidement lorsqu’on confie des tâches de développement ou de refactoring à des modèles de langage : par défaut, un LLM adore ajouter du code. Pour résoudre un bug de trois lignes, un agent non contraint a tendance à créer une classe abstraite, un fichier de configuration, deux wrappers de compatibilité et des options « au cas où » que personne n’a demandées. En quelques semaines, cette inflation algorithmique transforme un dépôt propre en un labyrinthe illisible.
Pour contrer cette dérive, j’ai intégré Ponytail (neuralsignal/ponytail) (Lazy Senior Dev Mode) au cœur de nos règles d’agents (.agents/rules/ponytail.md et .agents/skills/ponytail/). Le principe est celui d’un développeur senior pragmatique : le meilleur code est celui qu’on n’écrit pas, et la suppression de code mort bat systématiquement l’ajout.
Pourquoi les agents IA sur-ingénierent par défaut
Les modèles sont entraînés sur d’immenses corpus où la verbosité et les patterns académiques sont sur-représentés. Sans garde-fou explicite, trois anti-patterns reviennent systématiquement :
| Anti-pattern observé chez les LLM | Conséquence en production | Règle Ponytail appliquée |
|---|---|---|
Abstractions prématurées (Factory, Adapter, Config) | Multiplication des fichiers et indirection inutile | Pas de wrapper ni d’option non demandée ; garder la structure existante |
Correction symptomatique locale (try/except pass) | Masquage du bug réel et duplication du patch | grep tous les appelants et corriger la cause racine une seule fois |
| Ajout de dépendances tierces pour 10 lignes | Gonflement de la surface CVE (Supply Chain) | Utiliser la bibliothèque standard ou les helpers déjà présents |
| Code « pour plus tard » (flags inutilisés) | Dette technique immédiate et code mort | Élaguer tout ce qui ne répond pas au périmètre strict |
Implémentation concrète dans .agents/rules/ponytail.md
Sur notre infrastructure, Ponytail agit sous deux formes complémentaires :
- En amont (
ponytail) : une règle système chargée dans le contexte de l’agent avant toute écriture de code. - En aval (
ponytail-review) : une passe de revue automatique dugit diffqui vérifie si chaque ligne ajoutée est strictement nécessaire et sûre sous charge réelle.
# 1. Identifier tous les appelants avant de toucher une fonction partagée
rg --line-number "deploy_static_site" src/backend/
# 2. Mesurer l'empreinte réelle du changement (objectif : ratio suppression/ajout favorable)
git diff --stat
# 3. Vérifier qu'aucun import local ou dépendance fantôme n'a été introduit
pytest -q tests/test_architecture_invariants.py
Ce que Ponytail interdit de sacrifier
Être économe en lignes de code ne signifie jamais rogner sur la fiabilité. La spécification Ponytail sanctuarise explicitement quatre frontières non négociables :
- La validation des entrées aux frontières de confiance (trust boundaries).
- La gestion d’erreur qui empêche la perte ou la corruption de données.
- La sécurité Zero-Trust (permissions, secrets, isolation).
- Un test unitaire ou canary dès qu’une logique non triviale (boucle, parseur, sécurité) est modifiée.
| Commande | Description |
|---|---|
`rg -n 'nom_fonction' src/`
| Lister tous les appelants avant de modifier une fonction pour corriger la cause racine une seule fois. |
`git diff --stat`
| Contrôler le volume de lignes ajoutées vs supprimées avant commit. |
`# shortcut:
| Documenter honnêtement un raccourci technique en une seule ligne de commentaire. |
`pytest -q tests/test_architecture_invariants.py`
| Valider l'absence d'imports locaux et la déclaration stricte des dépendances. |
`pytest -q tests/test_canaries.py`
| Exécuter les canaries anti-régression pour prouver que le diff minimal ne casse aucun invariant. |
Conclusion
Associer un modèle de pointe à une contrainte de sobriété comme Ponytail change radicalement la vélocité : les revues de code redeviennent instantanées, les diffs tiennent en quelques lignes lisibles d’un seul coup d’œil, et la dette technique cesse de s’accumuler en silence.
Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome