SimpleOne a montré pourquoi Claude et les relecteurs AI ne distinguent pas le code généré par AI du code humain

SimpleOne a proposé un simple test : distinguer le code humain du code généré par l'IA. Il s'est avéré que c'est difficile non seulement pour les développeurs, mais aussi pour l'examinateur d'IA lui-même, qui vérifie le code selon les mêmes modèles selon lesquels il a été créé.

Pourquoi c'est Difficile

Dans l'article, l'équipe a rassemblé plusieurs paires de fonctions : validation d'email, requête API, chargement de configuration et calcul de remise. Dans chaque paire, une version a été écrite par un humain, l'autre par un modèle. Sur le papier, la tâche semble simple : le code d'IA a généralement plus de typage, de commentaires et de pseudo-précision.

En pratique, c'est pire. Certains exemples se trahissent vraiment par une correction excessive, mais dès la troisième ou quatrième paire, il devient clair : on ne peut pas toujours distinguer l'auteur par le style seul. L'exemple le plus frappant est la fonction de calcul de remise, où la différence entre les versions disparaît presque.

Les deux fragments sont fonctionnels, passent tous deux les vérifications statiques, semblent tous deux raisonnables. Mais la véritable erreur se cache non pas à l'intérieur de la fonction, mais à l'endroit où elle est appelée. Si la remise doit être fixée au moment de la validation de la commande, il ne faut pas la recalculer chaque fois que la page est ouverte.

Ce n'est plus une question de syntaxe ou de bonnes pratiques, mais de logique métier et de contexte du projet, que l'examinateur automatique n'a généralement pas.

Ce Qui Trahit le Synthétique

SimpleOne met en évidence plusieurs signes par lesquels le code d'IA peut parfois encore être détecté. Il ne s'agit pas d'erreurs flagrantes, mais plutôt d'un style suspecieusement « parfait » : le code semble soigné, mais se comporte comme s'il essayait d'impressionner l'examinateur plutôt que de résoudre une tâche spécifique de production. De tels signaux apparaissaient le plus souvent dans les exemples avec email, API et config.

• Des docstrings excessivement détaillées avec énumération des Args, Returns et de chaque exception même pour une minuscule fonction.
• Des cas limites inutiles et des vérifications que personne n'a demandées et qui ne découlent pas de l'énoncé du problème.
• Des entités inventées autour du code : des exceptions personnalisées, des loggers ou des champs obligatoires qui n'existent pas dans le projet.
• Des fallbacks « sûrs » comme data.get('user', {}), qui n'échouent pas immédiatement mais masquent le vrai problème.

De là vient le principal risque : l'IA écrit souvent non pas du code franchement mauvais, mais du code qui paraît convaincant. Il est typé, formaté, commenté et tient compte de nombreux scénarios. Mais certains de ces scénarios sont inventés, et certaines des constructions défensives ne font que compliquer le débogage. Un tel code est facile à accepter comme de haute qualité si vous regardez la forme et ne vérifiez pas comment il s'intègre dans un système spécifique.

Où l'Examen Échoue

Le problème que SimpleOne décrit ne se résume pas à la qualité d'un seul modèle. Si Claude génère du code et qu'un autre outil d'IA le vérifie selon les mêmes modèles, l'équipe obtient une boucle fermée de confiance synthétique. Tout semble vert : il y a des types, il y a la gestion des erreurs, il y a des commentaires. Mais l'examen peut ne pas remarquer que UserFetchError n'existe pas dans le projet, que secret_key apparaît soudainement sans exigences, et qu'un retour « silencieux » d'un dictionnaire vide consommera ensuite plusieurs heures à la recherche d'un bug.

« L'examinateur d'IA en a trouvé 2 sur 5 ».

L'équipe l'a testé sur de vrais bugs de production. L'examinateur automatique n'a attrapé que deux cas simples : une variable inutilisée et un contrôle null manquant. Ce qui a été manqué, c'étaient des choses qui nécessitaient le contexte du projet : une erreur logique dans le calcul, une condition de course avec des requêtes parallèles et un ordre de migration incorrect. La conclusion est pratique : l'IA fonctionne bien comme premier filtre, mais ne remplace pas un humain dans les zones critiques où il est important de comprendre la logique métier et les conséquences des changements.

Ce Que Cela Signifie

L'utilisation généralisée de l'IA dans le développement change non seulement la vitesse d'écriture du code, mais aussi le processus de contrôle qualité lui-même. Vérifier le code généré avec un autre outil génératif est utile, mais insuffisant. Si l'équipe ne teste pas l'examinateur sur les anciens bugs et ne garde pas un humain dans la chaîne de prise de décision, elle risque d'obtenir non pas de la qualité, mais une imitation très convaincante de celle-ci.