Contexte et pression de la génération automatisée
Les agents d'IA capables de créer ou de modifier du code en quelques secondes réduisent le coût de production d’un changement. Cette réduction pousse la validation du résultat vers les étapes en aval du pipeline, notamment le build, les tests et le contrôle de la conformité. L’auteur rappelle son expérience chez Uber, où il a géré le monorepo, le système de build et la file d’attente CI, puis a entraîné des modèles sur le même code. Le constat est que la facilité de génération augmente la charge sur les mécanismes qui certifient la sécurité et la stabilité du code.
Standardisation des critères de goût via le versionnage
Le « goût » en ingénierie correspond à des standards qui définissent ce qui rend une modification compatible avec le système. Ces standards ne doivent pas rester dans la tête des développeurs ; ils sont écrits sous forme de règles et de guides de revue, stockés dans le même dépôt que le service qu’ils gouvernent. Ainsi, chaque modification déclenche un diff qui inclut à la fois le code et les règles, permettant une révision simultanée. Cette approche transforme les standards en artefacts versionnés, soumis aux mêmes processus de revue que le code.
Discernement et vérifications déterministes
Le problème majeur identifié est le « code qui compile mais qui est erroné pour le système ». Sonar a constaté que 61 % des développeurs estiment que l’IA produit souvent du code qui semble correct mais qui n’est pas fiable, et 53 % déclarent que cela a déjà alourdi leur dette technique. Le modèle propose des constats, mais la décision finale est calculée dans le code à partir de ces constats, via des contrôles déterministes appliqués au diff. Cette séparation empêche le modèle de « dés‑résoudre » un problème déjà résolu par la revue humaine.
Jugement et gouvernance des déploiements
Le jugement humain décide ce qui peut être expédié. Il s’appuie sur des connaissances opérationnelles – chemins d’exécution, couverture de tests réelle, comportement du service en production – que l’on ne retrouve pas dans un prompt. Le processus recommandé progresse de la détection à la remédiation, puis à l’approbation sous critères écrits, avant le merge. Les autorisations sont limitées au niveau de l’outil : l’agent ne peut pas pousser une branche ou fusionner sans que le système le permette explicitement. L’approbation automatique ne peut que valider, jamais demander de modifications, et elle échoue en mode ouvert, de sorte qu’une mauvaise décision entraîne simplement une perte de commodité, pas un déploiement erroné.
