Quelles erreurs les développeurs commettent-ils en codant avec des assistants IA ?

Les assistants IA comme Copilot, Claude et les modèles intégrés de Cursor ont changé la vitesse à laquelle le code s'écrit. Ils n'ont pas changé la rigueur avec laquelle il doit être examiné. La plupart des dégâts que j'ai vus avec le codage assisté par IA viennent d'une poignée d'habitudes reproductibles, pas des modèles eux-mêmes.

Accepter les suggestions sans les lire

La plus grande erreur est d'accepter une complétion à la tabulation parce qu'elle semble plausible et se compile. Plausible n'est pas correct. J'ai vu une requête SQL suggérée silencieusement perdre une clause WHERE lors d'une refonte, et la personne l'a acceptée parce que les noms de variables correspondaient. Si vous ne lisez pas chaque ligne qu'un assistant vous donne à la même vitesse que vous liriez une pull request d'un collègue, vous allez envoyer quelque chose que vous ne comprenez pas. Traitez chaque suggestion comme un premier brouillon d'un développeur junior qui est rapide mais n'a aucune mémoire des conventions de votre base de code.

Lui faire confiance avec du code sensible à la sécurité

Les assistants IA sont entraînés sur d'énormes quantités de code public, et beaucoup de ce code a des problèmes de sécurité intégrés. Demandez un gestionnaire de téléchargement de fichier rapide et vous obtiendrez souvent quelque chose sans vérification d'extension, sans limite de taille, et un chemin construit par concaténation de chaînes au lieu de os.path.join ou d'un appel de bibliothèque sûr. Même histoire avec l'authentification : les assistants adorent suggérer de stocker les JWTs dans localStorage, ou de comparer des secrets avec == au lieu d'une comparaison en temps constant. Rien de cela n'est malveillant, c'est juste statistiquement courant dans les données d'entraînement. Pour tout ce qui touche l'authentification, les I/O de fichiers, la désérialisation ou SQL, écrivez la logique vous-même ou passez la sortie de l'IA à travers les mêmes questions de modélisation des menaces que vous poseriez pour n'importe quel nouveau code : que se passe-t-il avec une entrée hostile, que se passe-t-il si cet appel échoue, qui d'autre peut atteindre ce endpoint.

La laisser inventer des dépendances et des API

Les modèles hallucinent des noms de paquets et des signatures de fonction avec une confiance totale. C'est le problème du « slopsquatting » — les attaquants enregistrent les faux noms de paquets que les modèles suggèrent fréquemment, donc un pip install ou npm install non vérifiés peuvent télécharger quelque chose qui n'est pas du tout votre bibliothèque de journalisation. Avant d'ajouter une dépendance qu'un assistant recommande, vérifiez qu'elle existe réellement sur PyPI ou npm, vérifiez son nombre de téléchargements et sa date de dernière publication, et parcourez la source si elle est assez petite. La même prudence s'applique aux appels API : si l'assistant référence une méthode que vous ne reconnaissez pas, vérifiez la documentation réelle avant de supposer qu'elle existe.

Perdre le modèle mental de votre propre code

Quand vous écrivez du code vous-même, vous construisez une carte mentale de pourquoi chaque élément existe. Quand vous acceptez de grands blocs de code généré par IA au cours d'une session, cette carte devient mince rapidement. Ensuite, un bug apparaît trois semaines plus tard et vous déboguez du code que vous n'avez jamais vraiment écrit et dont vous ne vous souvenez pas complètement. La solution n'est pas d'éviter le code généré par IA, c'est de ralentir assez pour vous expliquer chaque bloc à vous-même, ou à un coéquipier, avant de le fusionner. Si vous ne pouvez pas expliquer ce qu'une fonction fait et pourquoi elle le fait de cette façon, ne la fusionnez pas encore.

Sauter les tests parce que le code