원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Depuis que les outils d'intelligence artificielle se sont infiltrés dans le code de production, le paysage des dépôts de code a changé. Selon une étude de GitClear, une entreprise d'analyse de données de dépôts logiciels, qui a analysé plus de 211 millions de lignes de code de production entre 2020 et 2024, le taux de rotation du code (Code Churn) — c'est-à-dire le pourcentage de code modifié ou complètement supprimé dans les deux semaines suivant sa fusion — est passé de 3,1 % à un pic de 7,1 %. L'analyse empirique de la plateforme de revue de code CodeRabbit montre également que le code généré par l'IA génère 1,7 fois plus de défauts par pull request que le code écrit par des humains. Les défauts de logique métier apparaissent 75 % plus fréquemment, les oublis de gestion des exceptions 2 fois plus, et les vulnérabilités de sécurité 2,74 fois plus. Selon une étude de SmartBear, dès qu'une pull request dépasse 400 lignes de modification, le taux de détection des défauts par le relecteur chute en dessous de 70 %. La méthode traditionnelle consistant à lire ligne par ligne les centaines de lignes de code produites par des juniors provoque une surcharge cognitive et conduit finalement à laisser de côté des défauts structurels critiques.
Pour briser le goulot d'étranglement de la revue manuelle, les responsables de l'ingénierie senior doivent cesser de jouer les inspecteurs de syntaxe et agir en tant qu'architectes système. Considérez une pull request comme un binaire non vérifié émis par un compilateur et lancez un protocole d'examen architectural permettant de juger de la solidité structurelle en 10 minutes. Pendant les 3 premières minutes, comparez la tâche à résoudre dans le texte avec le Diff Delta, c'est-à-dire la liste des fichiers réellement modifiés. Si des modules ou des fichiers de configuration non mentionnés dans la description sont mélangés, rejetez immédiatement la demande sans même lire le détail du code. Pendant les 4 minutes suivantes, vérifiez s'il y a violation des limites de domaine, par exemple si la couche de présentation contourne les services métier pour interroger directement la base de données. Pendant les 3 minutes restantes, surveillez si le système résiste aux pannes d'API externes ou aux conflits de concurrence du point de vue de la garantie des clés d'idempotence et du retour arrière (rollback) des transactions distribuées. Créez un champ dans le fichier .github/pull_request_template.md du dépôt pour y consigner les journaux de décision architecturale et le prompt d'origine, et n'ouvrez même pas le Diff pour les codes qui n'incluent pas de proposition de conception alternative.
Avant qu'un humain ne lise l'intégralité du code, toutes les erreurs détectables par une machine doivent être éliminées. L'entreprise fintech japonaise freee a intégré l'outil de revue de code sémantique CodeRabbit dans 285 dépôts, économisant ainsi l'équivalent de 32,8 semaines de ressources de réviseurs seniors en six mois et atteignant un taux d'acceptation de 54 % pour les signalements de défauts critiques. Les notifications de révision ne sont envoyées aux seniors que pour les pull requests qui ont franchi les filtres d'automatisation en 3 étapes, réduisant ainsi de moitié le temps consacré à l'examen manuel.
Il est nécessaire d'insérer des filtres de vérification séquentiels dans le pipeline CI. Lors de la première étape, l'analyse statique déterministe, ESLint, Biome et Ruff sont exécutés pour transformer les avertissements de l'analyseur en erreurs et fixer la complexité cyclomatique par fonction à 15 maximum. Lors de la deuxième étape, celle des types stricts et des invariants architecturaux, strict: true est activé dans tsconfig.json et dependency-cruiser est utilisé pour bloquer les appels de contournement de couche non autorisés. Lors de la troisième étape, la revue de code LLM sémantique, CodeRabbit ou Qodo sont intégrés pour détecter les défauts P1, P2 et les tests manquants. Si l'étape précédente n'est pas validée à 100 %, l'étape suivante ou l'attribution d'un réviseur humain est totalement bloquée.
Lorsque des agents d'intelligence artificielle sont déployés dans une structure monolithique ou une base de code existante, une contamination du contexte se produit : le modèle ignore les utilitaires communs existants et génère par copie ses propres implémentations. Les fichiers uniques .cursorrules consommant excessivement le contexte du modèle à mesure que le projet grandit, il convient d'utiliser la structure modularisée .cursor/rules/*.mdc. Les fichiers MDC étant injectés de manière conditionnelle uniquement lorsque des motifs de fichiers spécifiques font l'objet du travail, cela réduit la consommation de tokens de plus de 40 % tout en maximisant le taux de respect des règles.
Pour préserver l'intégrité du domaine principal, les répertoires doivent être verrouillés de force. Créez un fichier .cursor/rules/core-boundaries.mdc à la racine du projet et désignez les répertoires clés tels que src/core/ledger/** comme étant en lecture seule avec le paramètre alwaysApply: true. Ajoutez .cursor/rules/api-contracts.mdc pour interdire la suppression de champs de schéma de réponse existants lors des travaux sur la couche API et imposer l'utilisation de classes d'exceptions de domaine. Enregistrez .env* et l'historique des migrations dans .cursorignore pour bloquer à la source toute tentative du modèle d'analyser des informations sensibles. La duplication d'utilitaires par l'agent disparaît ainsi à plus de 90 %.
Lorsqu'un junior demande à l'intelligence artificielle de rédiger des tests unitaires, la couverture des lignes dépasse 90 %, mais des défauts silencieux surviennent car les bogues de la logique métier essentielle ne sont pas détectés. La seule façon de vérifier si les tests fonctionnent correctement est d'utiliser le score de mutation, qui mesure si les tests parviennent à détecter et à provoquer l'échec de défauts de code intentionnellement injectés.
Intégrez le framework de test de mutation Stryker dans le pipeline CI. Créez un fichier stryker.config.json à la racine du projet, ajoutez src/domains/**/*.ts dans l'élément mutate, puis fixez la valeur de thresholds.break à 70. Ajoutez la commande npx stryker run --since origin/main au workflow GitHub Actions .github/workflows/mutation-gate.yml pour n'inspecter de manière incrémentielle que le code modifié. Chaque vendredi, de 15h00 à 18h00, arrêtez le développement de nouvelles fonctionnalités pour vous concentrer sur l'élimination des mutants survivants et l'intégration du code dupliqué. Si le score de mutation du nouveau code tombe en dessous de 70 %, le pipeline renvoie immédiatement une erreur et bloque la fusion.
Le plus grand problème lors de l'adoption de l'intelligence artificielle est la fracture entre la passivité du senior et la dépendance aveugle du junior. Chez Shopify, même si 95 % du code a été rédigé par un modèle de langage, l'ingénieur dont le nom figure sur la pull request est tenu pour 100 % responsable de chaque ligne. Le lead doit mettre en place une routine pour briser la naïveté du junior et transmettre le savoir-faire en matière d'injection de contexte.
Pour affiner les compétences de manipulation de prompts des juniors, organisez une clinique intensive de 30 minutes chaque semaine. Pendant les 10 premières minutes, où le junior apporte un ticket de sprint, partage son écran avec le senior et donne des instructions à l'agent, observez s'il formule des exigences ambiguës. Pendant les 10 minutes intermédiaires, le senior fait une démonstration d'ingénierie contextuelle en imposant comme contraintes, au moment de la saisie du prompt, les règles de gestion des erreurs et le niveau d'isolation des transactions du projet. Pendant les 10 dernières minutes, apprenez à l'IA non pas à donner une seule réponse définitive, mais à comparer plusieurs modèles d'architecture avant de contre-interroger avec des cas de test pour les conditions limites manquantes. Grâce à ce processus, le taux d'erreur de prompt des juniors diminue de plus de 60 %.
