Une fois que la puissance de calcul a ouvert la voie à la génération de candidats, un nouveau défi surgit :à quel titre les modifications générées automatiquement par un Agent peuvent-elles être intégrées à la branche principale du projet ?Le mécanisme rigoureux de validation et d'héritage historique dissocie totalement lagénérationdel'adoption— tout code soumis par un Agent n'est qu'unpatch candidat (candidate patch), qui doit d'abord franchir une série de barrières de validation pour avoir le droit d'être reconnu comme partie intégrante de l'historique du projet.
Principe du statut candidat par défaut
La sortie de l'Agent est considérée par défaut comme uneentrée non fiable: elle est strictement isolée des versions adoptées en matière de droits, de stockage et de références ; elle ne peut ni lire ni écrire directement dans la branche principale, ni être utilisée par d'autres modules comme dépendance stable. L'unique objectif de ce principe est d'interdire toute « intégration automatique de la génération ». Ce n'est qu'après avoir franchi toutes les barrières qu'un patch candidat acquiert un statut équivalent à celui de la branche principale.
Filtrage progressif en quatre niveaux : coût croissant, échec précoce
- Compilation: compilabilité au niveau de la syntaxe et des interfaces. Coût minimal et élimination la plus rapide : on écarte d'emblée les modifications manifestement non viables.
- Tests: réussite des tests unitaires et d'intégration, couvrant les contrats existants.
- Vérification comportementale: cohérence sémantique et comportementale, incluant tolérance numérique, équivalence et comparaison de régression, afin de prévenir spécifiquement la « dérive comportementale malgré des tests réussis ».
- Validation de haut niveau: arbitrage final orienté vers les objectifs de la tâche et les contraintes d'ingénierie, incluant des jugements sur la performance, le gain de vitesse, la maintenabilité, etc.
Les barrières sont ordonnées par coût croissant, de sorte que la grande majorité des modifications invalides soient écartées dès les étapes peu coûteuses, réservant l'évaluation onéreuse de haut niveau à un petit nombre de candidats de qualité — c'est là toute l'économie de l'« échec précoce ».
La valeur du rejet et l'héritage historique
Les tentatives non validées n'intègrent pas la branche principale, mais peuvent être conservées commearchives d'échec / échantillons négatifs, à des fins de diagnostic, de déduplication et de prévention des explorations redondantes — le rejet constitue en soi un filtrage du bruit. Quant aux modifications validées, elles deviennent la nouvelleversion de base, sur laquelle les exécuteurs suivants continuent d'évoluer, formant une chaîne d'évolution à accumulation monotone plutôt qu'une reconstruction à partir de zéro à chaque cycle. En tant que règle de fusion et contrat qualité pour la collaboration multi-Agents et la décomposition récursive des tâches, la passerelle de validation définit « qui peut écrire dans l'historique », déterminant ainsi si le résultat de la collaboration converge ou génère de l'entropie. Dans des scénarios à fortes contraintes de correction, tels que la refactorisation de compilateurs et la mise à niveau de logiciels scientifiques, ce mécanisme fait preuve d'une fiabilité extrêmement élevée et apporte des gains de vitesse d'exécution considérables.
Quatre barrières de validation et isolation des candidatsDans le schéma, les modifications générées par l'Agent sont d'abord isolées en tant que patches candidats non fiables, puis franchissent successivement les quatre barrières de compilation, de tests, de vérification comportementale et de validation de haut niveau. Les barrières sont ordonnées par coût croissant, de sorte que les modifications invalides échouent au plus tôt dès les étapes peu coûteuses. Celles qui passent deviennent une nouvelle base héritée par la suite, tandis que les rejetées sont conservées comme archives d'échec et échantillons négatifs, à des fins de diagnostic et de prévention des explorations redondantes.
