Reins Engineering

Image: AI generated

Un cheval sans rênes

Les outils de codage IA sont devenus rapides. Connexion en 30 secondes. Paiement en 2 minutes. Un MVP sort en trois semaines.

Trois mois plus tard, tout s’effondre.

L’IA « nettoie » la logique de paiement et modifie les calculs de remise. Une demande de refactoring change les noms de champs de l’API publique. L’ajout d’une nouvelle fonctionnalité casse l’authentification. Selon une recherche de Carnegie Mellon (MSR 2026), la complexité du code augmente de manière permanente de 41 % après l’adoption d’outils de codage IA. Le Google DORA Report (2025) montre une baisse de 7,2 % de la stabilité des livraisons pour chaque augmentation de 25 % de l’adoption de l’IA.

Le problème n’est pas que l’IA est stupide. C’est qu’il n’y a pas de rênes.

Le harnais est une clôture

L’industrie a répondu avec le « harness engineering ». Linters, formateurs, CI/CD, structure de projet, conventions de codage. Des clôtures qui empêchent l’agent de sortir du périmètre.

Les clôtures ne fixent pas de direction. Quoi que l’agent fasse à l’intérieur de la clôture — écraser la logique existante, changer les types, sauter des transitions d’état — le linter passe. Le formateur passe. Le CI passe. Le code arrive en production « propre mais faux ».

La selle est en place. Le cavalier est monté. Mais sans rênes, il se tient avec les cuisses et tombe au bout de trois mois.

Reins Engineering

Reins Engineering est une approche d’ingénierie qui donne aux agents IA des contrats déterministes et bloque la progression lorsque les contrats sont violés.

Elle se compose de trois éléments :

1. Feedback déterministe

Donnez à l’agent des faits, pas des opinions. Non pas « ça a l’air bizarre » mais « ligne 41 : nom de champ incompatible, attendu ‘user_id’, obtenu ‘userId’. » Un feedback qui ne laisse aucune place à la sycophancy. Selon l’étude TDAD (arxiv 2026), les instructions procédurales « fais du TDD » aggravent les régressions (6,08 % → 9,94 %), tandis que fournir des fichiers de test spécifiques dans le contexte réduit les régressions de 70 % (6,08 % → 1,82 %).

2. Verrouillage des contrats (Ratchet Pattern)

Quand la vérification passe, verrouillez. Les tests Hurl déclarent le comportement de l’API en texte brut, exécutés à chaque commit dans le CI. Les tests passés ne peuvent pas être supprimés. L’agent peut modifier librement le code, mais ne peut pas modifier le comportement. La dérive est structurellement supprimée.

3. Séparation des décisions et de l’implémentation

Trois choses mélangées dans le code — les décisions utilisateur, la logique métier, les détails d’implémentation — sont séparées. Les décisions vivent dans des spécifications déclaratives (OpenAPI, DDL, diagrammes d’états). L’implémentation est librement générée par l’IA. L’IA ne peut pas confondre les décisions avec les détails et les écraser. La survie des décisions devient indépendante de la taille du modèle.

Évolution

Prompt Engineering      → Bien le dire et ça marche
Context Engineering     → Donner un bon contexte et ça marche
Harness Engineering     → Contenir avec la structure
Reins Engineering       → Diriger avec les rênes

Chaque étape est née des limites de la précédente. Les prompts seuls manquaient de cohérence. Le contexte n’empêchait pas l’agent de dévier. Les clôtures ne pouvaient pas prévenir la dérive à l’intérieur du périmètre.

Reins Engineering n’est pas une clôture — ce sont des rênes. Il ne contraint pas la liberté de l’agent ; il garantit que l’agent atteint la destination.

Pourquoi les plus gros modèles ne sont pas la réponse

« GPT-6 va tout corriger. »

Non. Le problème n’est pas l’intelligence du modèle — c’est le medium. Le code comme medium ne distingue pas les décisions de l’implémentation. N’importe quel modèle lisant du code voit les décisions et les détails mélangés dans le même texte.

Un modèle local de 4,5B paramètres (Gemma4) avec un feedback déterministe + un contexte d’exemples édite les SSOT sans erreur. Un modèle frontier éditant du code brut produit de la dérive. La différence est la structure, pas l’intelligence.

Ne changez pas le modèle. Ajoutez un contrat.

Preuves

yongol est l’implémentation de Reins Engineering. Il valide de manière croisée la cohérence de 10 spécifications déclaratives (SSOT) avec 287 règles et génère du code.

Benchmark ZenFlow — un SaaS d’automatisation de workflows multi-tenant. 32 endpoints, 14 tables, 47 requêtes Hurl. 11/11 étapes réussies. L’ajout de fonctionnalités n’a pas ralenti le processus. Les tests existants ne se sont jamais cassés.

Un backend fonctionnel a été généré avec succès par un modèle local de 4,5B paramètres. Coût : 0 $. Hors ligne. Reins comble le fossé que la taille du modèle laisse.

Un harnais sans rênes n’est qu’une clôture

L’IA est déjà assez puissante. Ce qui manque, c’est la direction.

Construisez des clôtures plus hautes et l’agent dérivera plus vite à l’intérieur. Tenez les rênes et l’agent court vers la destination.

Reins Engineering — une vérification déterministe structurée pour les agents IA.

Liens connexes

References