Erreurs des assistants de programmation IA et comment les éviter

La plupart des erreurs des assistants de programmation IA commencent avant la génération du code : la tâche est vague, les contraintes sont cachées ou personne ne définit comment le résultat sera validé. La prévention ne consiste pas à éviter l’IA. Elle consiste à donner à l’assistant un meilleur problème d’ingénierie à résoudre.

Voici les schémas d’échec qui rendent risquées des modifications techniquement valides, ainsi qu’une habitude concrète qui prévient chacun d’eux.

« Déplace le bouton dans la barre latérale » indique à un assistant où placer quelque chose, mais pas pourquoi l’emplacement actuel échoue.

Prévention : indiquez d’abord le problème utilisateur et le résultat.

Problème : le sélecteur de sujet entre en concurrence avec la navigation globale,
alors que les utilisateurs l’emploient pour comparer des leçons dans un même cours.

Résultat : rends le changement de sujet facile à trouver près de la navigation du
cours sans modifier les actions globales de la barre de navigation.

L’assistant peut maintenant remettre le choix de l’emplacement en question si un autre modèle pour les petits écrans est plus sûr.

« Nettoie le flux d’authentification » invite à un diff important. L’assistant peut modifier des providers, des routes, des tests et des appels d’API parce qu’il ne voit aucune limite.

Prévention : nommez la première limite et les éléments hors objectif.

Inspecte uniquement le callback de connexion et ses tests directs. Ne modifie pas
la liaison de compte, la facturation ni les gardes de route, sauf si les preuves
montrent que le callback ne peut pas être corrigé de façon isolée.

Si le travail traverse réellement une limite, l’assistant doit expliquer pourquoi avant de l’élargir.

Un assistant ne peut pas déduire chaque règle produit à partir d’un composant. Il peut introduire un chemin réservé au serveur dans une application statique, casser une route qui préserve la locale ou dupliquer un rédacteur d’état.

Prévention : placez les invariants essentiels dans le prompt ou dans des consignes de projet pérennes.

Préserve l’exportation statique, la navigation qui conserve la locale active, les
noms d’événements d’analytique existants et l’unique rédacteur actuel pour les
préférences de notifications.

Gardez la liste courte et précise. Une longue liste de souhaits est moins utile que quelques contrats applicables.

Le code généré peut compiler tout en ayant une mauvaise transition d’état, un mauvais chemin d’erreur, un comportement d’accessibilité inadapté ou une mauvaise limite de sécurité.

Prévention : exigez un plan de validation avant l’implémentation.

Liste les tests ciblés, la vérification de types et le scénario manuel qui
prouveraient cette modification. Explique quel comportement couvre chaque
vérification et ce qui reste non vérifié.

Exécutez les vérifications. Examinez le diff. Parcourez le chemin utilisateur. La sortie de l’IA est une proposition, pas un critère de publication.

Un diff important masque la correction effective du bug. Il est difficile à examiner et presque impossible à annuler en toute sécurité.

Prévention : demandez une séquence de petits points de contrôle.

Reproduis et explique d’abord l’échec. Applique ensuite uniquement le correctif
d’état et ajoute le test de régression. Ne refactorise pas les composants liés
tant que le test ciblé ne passe pas et que le diff n’est pas examiné.

La modification plus petite peut révéler que la refactorisation prévue n’était pas nécessaire.

« Rends cette page plus rapide » peut produire une mise en cache, une mémoïsation ou un découpage du code qui masque le véritable goulot d’étranglement et crée de nouveaux risques d’invalidation.

Prévention : demandez des mesures et des alternatives.

Identifie si le ralentissement vient du réseau, du calcul ou du rendu. Indique la
mesure, la référence et l’impact attendu avant de proposer une optimisation.
N’ajoute pas de cache persistant tant que la fraîcheur et l’invalidation ne sont
pas définies.

Le travail de performance doit modifier un coût mesuré, pas simplement ajouter une technique connue.

Un assistant peut supprimer une barre latérale de bureau pour améliorer la mise en page mobile, ou simplifier un flux dont les utilisateurs dépendent. Le code peut être propre alors que le produit se dégrade.

Prévention : nommez les personnes, le flux de travail et le comportement qui doivent rester.

Les apprenants sur mobile ont besoin de davantage d’espace horizontal. Les
apprenants sur ordinateur dépendent de la barre latérale pour naviguer dans le
cours. Améliore la mise en page mobile tout en préservant le flux de travail de
bureau et son parcours au clavier.

Cela transforme « supprimer la barre latérale » en véritable contrainte de conception.

Les incidents de production créent de l’urgence, mais l’urgence ne justifie pas de laisser un assistant deviner à partir d’un symptôme.

Prévention : utilisez la séquence des preuves à la validation :

Preuves -> hypothèses -> vérification -> plus petit correctif -> test de régression ->
vérification de déploiement sûre

Incluez des journaux dont les valeurs sensibles sont supprimées, les étapes de reproduction, l’environnement, les modifications récentes, le comportement attendu et le comportement observé. N’appliquez pas aveuglément des correctifs générés en production.

Problème : [Qui est touché et que se passe-t-il ?]
Périmètre : [Que faut-il inspecter en premier ?]
Résultat : [Quel résultat observable est nécessaire ?]
Contraintes : [Qu’est-ce qui ne doit pas changer ?]
Preuves : [Test, journal, capture d’écran, sortie de commande ou reproduction.]
Critères d’acceptation : [Comment saurons-nous que cela a fonctionné ?]
Validation : [Tests, contrôles manuels ou mesures.]

Remets l’hypothèse en question avant de modifier. Si la solution demandée n’est
pas étayée par les preuves, explique l’alternative plus sûre.

Pour une analyse complète de cette structure, lisez comment écrire de meilleurs prompts d’IA. Pour des modèles d’implémentation quotidiens, utilisez l’ingénierie des prompts pour les développeurs. Lorsqu’un incident est en cause, suivez les modèles de prompts pour déboguer des problèmes en production.

La sortie de terminal est aussi une preuve. Exercez-vous à un flux de travail en ligne de commande dans le navigateur avant de l’intégrer à un rapport de bug, un test ou un prompt d’automatisation.