Contexte et motivations

Le texte provient d’un ingénieur senior qui a intégré un générateur de code basé sur un grand modèle de langage (souvent appelé « clanker ») dans son flux de travail depuis quelques années. Il souligne que, même si l’outil produit du code fonctionnel environ 95 % du temps, il reste responsable du pull‑request et du on‑call. Cette double responsabilité crée une tension entre la rapidité de génération et la nécessité de garantir la qualité.

Mécanismes des générateurs de code IA

Le modèle optimise uniquement un score de probabilité de token, sans compréhension du problème sous‑jacent. Son fenêtre de contexte limitée empêche la prise en compte de l’ensemble du projet, ce qui conduit à des ajouts locaux plutôt qu’à une refactorisation globale. L’auteur note que l’outil ne possède ni curiosité ni capacité d’apprentissage post‑déploiement ; il ne peut donc pas corriger ses propres erreurs au fil du temps.

Le processus de génération se résume à « compléter la tâche demandée », comparable à un chiot qui mâche un jouet. Le résultat peut être correct, mais il manque souvent les vérifications de sécurité, de performance ou de maintenabilité que l’ingénieur aurait intégrées.

Analyse des risques et limites observés

Plusieurs scénarios concrets sont décrits : suppression de composants critiques, modifications de bibliothèques sans contrôle, création de tests unitaires qui atteignent 100 % de couverture sur des conditions erronées, et duplication massive de fonctions (le même code ré‑implémenté plus de quatorze fois). Ces pratiques augmentent la dette technique et rendent le code difficile à diagnostiquer lorsqu’une panne survient.

L’auteur mentionne également la présence de « thousands upon thousands » de tests qui, malgré leur nombre, ne garantissent pas la validité fonctionnelle. Le phénomène d’« addition continue » conduit à un code « partout », avec des commentaires superflus et une documentation souvent incorrecte.

Recommandations pour la revue humaine

Face à ces limites, la lecture attentive du code reste indispensable. L’ingénieur doit vérifier chaque modification, même si elle provient d’un modèle IA, afin d’éviter les dérives décrites. Il suggère d’instaurer des processus formels : revues de code strictes, critères de qualité mesurables, et contrôles de sécurité automatisés. Aucun système de prompts ou d’instructions contextuelles n’a, à ce jour, démontré une amélioration fiable du comportement du modèle.

En conclusion, l’utilisation d’un générateur de code IA peut accélérer le développement, mais elle ne supprime pas la responsabilité humaine. La vigilance, la revue systématique et la mise en place de garde‑fous techniques restent les seules garanties contre les défauts introduits par ces outils.