AI slop

Fran Soto, ingénieur chez Amazon, en a donné la définition la plus précise dans son article de newsletter d'avril 2026 « Developer Taste: Separating Good Code from AI Slop » : du code qui compile, passe les tests, semble correct en surface, et « rend les six prochains mois plus difficiles pour tout le monde ». L'échec n'est pas un build cassé. C'est un jugement défaillant, et le compilateur ne peut pas le détecter.

Philippe Ensarguet a retracé le même schéma dans la gouvernance open source en février 2026, où les dégâts se mesurent en temps de mainteneurs. Puisque l'effort requis pour écrire une contribution signalait autrefois que quelqu'un comprenait le projet, les soumissions générées ont dissocié les deux : un résultat d'apparence plausible sans aucune compréhension derrière. Ghostty a réagi par des bannissements permanents pour le code généré par IA, tldraw ferme automatiquement les PR externes, et cURL a arrêté son programme de bug bounty après avoir été submergé de soumissions vides. La solution proposée par Ensarguet consiste à filtrer sur le contexte démontré plutôt que sur l'effort : la soumission est-elle liée à des issues existantes, les tests sont-ils complets, le code a-t-il réellement été exécuté.

Cobus Greyling formule la même production du côté de l'offre. Dans son argumentaire de novembre 2025 sur l'effondrement du coût du logiciel, le slop est ce qui se produit quand une ressource devient assez bon marché pour être gaspillée, comme l'ont été la bande passante et le stockage avant elle.

La question non résolue se trouve dans la conclusion même de Soto : quand n'importe qui peut générer du code, savoir quel code mérite confiance devient la compétence différenciante, et personne ne sait comment recruter pour cela.