J'ai audité le code IA de mon équipe. Voici ce que nous avons découvert.

Mon équipe a utilisé l'IA pour générer du code à une vitesse record. Nous avons déployé des fonctionnalités en un tiers du temps habituel. Notre vélocité semblait excellente. Notre couverture de tests a atteint 91 %.

Puis, nous nous sommes heurtés à un mur.

Nous avons été confrontés à des bugs en production difficiles à corriger. Un simple refactoring a pris quatre semaines au lieu de quatre jours. Une nouvelle recrue m'a dit que le code était propre, mais impossible à comprendre.

Nous avons passé trois semaines à auditer la base de code. Nous avons découvert une dette technique qu'aucun scanner ne pouvait détecter. Cette dette était architecturale. Elle était comportementale.

Les outils d'IA résolvent le problème immédiat de votre prompt. Ils optimisent pour la tâche locale. Ils ne comprennent pas l'ensemble du système. Ils ne savent pas quels services vous prévoyez de supprimer prochainement. Ils ne connaissent pas vos modèles de données à long terme.

Le résultat est un code qui est localement correct, mais globalement fragile.

Nous avons identifié quatre modèles spécifiques :

  1. Cas limites cachés (Hidden Edge Cases) L'IA écrit du code qui passe les tests que vous lui donnez. Elle n'est pas douée pour écrire des tests pour ses propres erreurs.
  • La solution : Un ingénieur doit expliquer le code à un collègue sans le regarder. S'il ne peut pas l'expliquer, il ne peut pas le fusionner.
  1. Le théâtre de la couverture de tests (Test Coverage Theater) L'IA génère des tests qui couvrent le code existant. Elle n'écrit pas de tests sur la manière dont le système devrait réellement se comporter.
  • La solution : Chaque suite de tests générée par l'IA doit passer une revue contradictoire (adversarial review). Un second ingénieur doit tenter de faire planter le code.
  1. Couplage invisible L'IA ajoute des dépendances pour résoudre un prompt rapidement. Elle pourrait entremêler la logique de notification avec vos modules de facturation ou d'utilisateurs. Cela rend impossible la séparation des services ultérieurement.
  • La solution : Un ingénieur senior doit approuver toute nouvelle dépendance introduite par l'IA.
  1. Gestion d'erreurs superficielle L'IA écrit souvent des blocs d'erreur qui semblent complets, mais qui ne parviennent pas à gérer les véritables défaillances du système.
  • La solution : Nous utilisons un test de changement. Nous mesurons combien de fichiers sont impactés lorsque nous effectuons une petite modification. Un impact élevé signifie un couplage élevé.

L'IA n'est pas l'ennemie. Vous devez traiter l'IA comme un ingénieur junior. Vous devez lui fournir des directives, fixer des attentes et utiliser votre jugement pour passer outre ses résultats.

Les outils sont excellents pour les tâches. Ils ne sont pas excellents pour le métier.

Source : https://dev.to/emilywoodsnyc/i-spent-3-weeks-auditing-my-teams-ai-generated-code-here-is-what-we-found-1kj5

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi