Pour ne pas être submergé par le code généré par l'IA, il faut commencer par isoler l'architecture
TuBrief 편집팀
2026년 7월 7일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
La vitesse à laquelle l'IA générative produit du code est effrayante. Mais les ingénieurs seniors et les leads techniques sont confrontés à un problème bien plus réel : la surcharge cognitive provoquée par la nécessité de vérifier et d'intégrer dans les systèmes existants du code produit par une machine en une seconde. Le rapport DORA 2025 de Google Cloud indique que si l'adoption de l'IA augmente la fréquence des déploiements, elle accroît également l'instabilité des systèmes. Cela signifie que des humains passent leurs nuits à colmater des brèches créées par le copier-coller aveugle de code généré. La méthode manuelle, où l'on lit et débogue chaque ligne de code, ne peut plus suivre ce rythme. Pour éviter que le code ne se transforme en déchets, il est impératif de construire une architecture qui, dès le départ, ne fait pas confiance à la logique générée par l'IA et d'automatiser sa validation.
Le code suggéré par l'IA ignore le contexte métier. Bien qu'il puisse paraître correct en apparence, il viole souvent les règles subtiles du domaine. Par conséquent, la logique produite par l'IA doit être traitée comme un système externe susceptible de tomber en panne à tout moment. C'est pourquoi il faut concevoir, dès l'étape de planification, une couche anti-corruption définissant des interfaces d'abstraction claires pour empêcher les agents contaminants de pénétrer dans le domaine existant.
Il ne suffit pas de séparer l'architecture logicielle. Le risque que le code de l'IA importe des bibliothèques malveillantes ou compromette le système de fichiers local est permanent. L'exemple de Stripe, qui, lors de la conception de son système d'agents autonomes "Minions", a exécuté le code généré par l'IA dans des machines virtuelles isolées de la machine hôte et bloqué l'accès réseau au niveau du protocole, est très instructif. Pour protéger l'environnement de production, il est nécessaire d'introduire des dispositifs de contrôle au niveau du noyau dans le pipeline CI/CD.
Il faut mettre en place un environnement d'exécution Zero Trust qui empêche le code non fiable de sortir de sa zone. La réduction du temps de réponse aux incidents système n'est qu'un avantage supplémentaire qui en découle.
Il est dangereux pour un développeur de vérifier manuellement des centaines de lignes de code produites par l'IA. Lorsque le cerveau est fatigué, un biais d'automatisation s'installe, poussant à valider des codes qui semblent corrects. Les défauts de la logique produite par la machine doivent être détectés par des tests exécutables, et non par des humains. Il faut inverser l'ordre des choses : avant de demander à l'IA d'écrire le code d'implémentation réel, il faut l'obliger à créer des cas de test définissant les spécifications de fonctionnement. Il s'agit d'une règle imposant de définir d'abord cinq catégories : flux normal, conditions aux limites, gestion des exceptions, entrées anormales et scénarios de récupération après erreur.
La couverture de code obtenue par des prompts manuels n'est pas très élevée. Selon les données opérationnelles des agents de Diffblue, la couverture de test obtenue par des ingénieurs humains dialoguant avec l'IA n'était que de 32 % en moyenne. En revanche, lorsque l'analyse statique du code source et les builds en sandbox d'exécution ont été couplés à des agents de test automatisés, une couverture de tests de régression de 81 % en moyenne a été atteinte sans intervention humaine. Une structure où une machine surveille une machine est beaucoup plus rigoureuse.
Pour une logique difficile à comparer ligne par ligne, comme les résultats de traduction en langage naturel ou les objets JSON dynamiques, on utilise la technique LLM-as-a-Judge. On intègre des frameworks comme AgentProctor dans l'infrastructure de test et on injecte des modèles de critères d'évaluation dans le modèle de jugement. Si l'on force le modèle à évaluer si le code renvoyé enfreint les contraintes de sécurité via une note quantitative, et qu'on met en place des garde-fous bloquant le build en cas de résultat insuffisant, on s'épargne la souffrance humaine de devoir examiner le code brut.
À mesure que la quantité de code produit par les machines augmente, une dette cognitive s'accumule dans le système. On se retrouve dans une situation étrange où le code fonctionne, mais où personne ne sait pourquoi. Les outils d'IA se concentrent uniquement sur la résolution des problèmes locaux immédiats, ce qui entraîne des coûts énormes lors du refactoring global du système quelques mois plus tard. Pour préserver l'intention de conception cachée derrière la base de code, il faut adopter comme standard d'équipe le processus de dossier de décision d'agent. Il s'agit de laisser une trace sous un format lisible par la machine expliquant pourquoi telle structure a été choisie et quelles alternatives ont été écartées.
La mémoire humaine étant peu fiable, l'automatisation de l'indication que le code a été écrit par une IA doit être intégrée dans le pipeline. En utilisant des outils comme la bibliothèque d'extension git-ai, il est possible d'enregistrer les notes de contribution de l'agent dans un chemin de métadonnées indépendant refs/notes/ai, sans polluer le corps des messages de commit. Les étapes de construction du pipeline Git sont claires :
pre-commit hooks dans l'environnement de développement local et le dépôt du serveur CI.AI-Footprint: model=gpt-4o) et les informations sur le co-auteur dans les métadonnées.En accumulant ces métadonnées, il est possible de générer en temps réel des statistiques sur la chaîne d'approvisionnement pour identifier, par exemple, quelle version de modèle d'IA a produit en masse des défauts ou des vulnérabilités de sécurité. C'est une mesure de sécurité qui évite de se retrouver dans l'enfer de devoir examiner des dizaines de milliers de lignes de code sans documentation de transfert.
Lorsque du code généré de manière anarchique commence à s'accumuler dans la file d'attente des pull requests, la revue de code manuelle est paralysée. Pour maintenir la productivité, il faut séparer le processus de revue en un portail de feedback déterministe centré sur la machine et une évaluation de l'impact structurel centrée sur l'humain. Un portail d'assurance qualité en 3 étapes fonctionnant dès que le code est téléchargé dans l'environnement CI est une alternative.
Premièrement, un portail de linting ultrarapide évalue la validité de la structure syntaxique et la correspondance des indices de type en moins de 5 secondes. S'il est recalé ici, le code est immédiatement rejeté. Deuxièmement, on effectue un test d'impact sélectif qui n'exécute rapidement que les tests unitaires affectés par les fichiers modifiés (environ 2 %). Troisièmement, en cas d'échec des tests, on active une boucle de correction autonome qui renvoie la pile d'erreurs en contexte à l'agent pour qu'il se corrige lui-même jusqu'à deux fois.
Seuls les morceaux de code propres ayant réussi cette boucle de correction autonome apparaissent sur l'écran du développeur senior humain. Le relecteur humain ne perd plus son temps à chercher des fautes de frappe ou à souligner des conventions. Le temps de l'ingénieur senior doit être consacré au contrôle macroscopique : vérifier que la frontière du domaine n'est pas rompue par un couplage direct entre composants, s'assurer qu'une contre-pression (backpressure) est prévue pour protéger la couche de persistance en cas de pic de trafic, et analyser l'économie du système et de l'infrastructure, comme les surcoûts de performance liés aux requêtes SQL N+1. C'est la seule façon de protéger le système de production face au flot incessant de code.