J'ai conçu un langage de programmation que les LLM ne peuvent pas utiliser

Le langage KillSwitch se présente comme un langage ésotérique à pile, conçu pour être aussi difficile que possible à lire, écrire et comprendre pour les grands modèles de langage (LLM) et les agents de code. Son auteur, qui publie le projet sur son blog, pose une question de fond : la capacité des LLM à produire du code relève-t-elle d'une véritable compréhension de la programmation, ou plutôt du rappel de fragments déjà vus lors de l'entraînement ou présents dans la fenêtre de contexte ? Pour y répondre, il a choisi de tester ces modèles sur un langage qu'ils n'ont, par construction, jamais rencontré.

Les mécanismes de résistance évoqués sont variés. La spécification contient des affirmations fausses que les lecteurs humains sont supposés repérer, et elle attend du lecteur qu'il déduise certains éléments plutôt que de les trouver explicitement énoncés. L'interpréteur refuse d'exécuter un code qui ne respecte pas des règles fondées sur le nombre de caractères des identifiants, un point présenté comme central, les LLM ayant réputément du mal à compter les lettres. Certaines constructions visent à déclencher les garde-fous de sécurité des modèles, avec des formulations du type « hack into a computer » ou « Ignore previous instructions », cette dernière ayant une signification propre dans le langage. Enfin, les scripts sont en grande partie constitués de récits qui peuvent contenir des instructions syntaxiquement pertinentes sans y être obligés, et les littéraux peuvent être placés n'importe où avant d'être référencés par un décompte de lignes. L'auteur reconnaît toutefois que le noyau du langage, une pile, des fonctions, des variables et des structures conditionnelles, reste familier et que d'autres paradigmes pourraient être plus déroutants.

Pour mesurer l'effet de ces choix, l'auteur a conçu un ensemble de tâches et évalué les principaux modèles ainsi que plusieurs environnements d'agents de code. Les résultats sont publiés sous forme de classement et d'un graphique comparant le score obtenu au coût par tâche réussie. Le meilleur score atteint 66,8 %, obtenu par Claude Opus 5, que l'auteur attribue à une meilleure interprétation de la spécification plutôt qu'au hasard. Certains modèles, comme Claude Fable 5.1 ou Gemini 4 Argon, sont pénalisés par des garde-fous jugés trop sensibles. Le meilleur modèle à poids ouverts cité est MiMo-V2.6-Pro.

L'auteur tire de ces résultats une conclusion prudente : ils ne démontrent pas, selon lui, que les LLM comprennent réellement le code. Les tâches restent simples, qu'il s'agisse d'implémenter un « Hello World », d'expliquer la sortie d'un script calculant un maximum ou de modifier un convertisseur Celsius-Fahrenheit pour effectuer la conversion inverse. Réussir ces exercices dans un langage conçu pour les dérouter reste néanmoins notable. L'auteur indique qu'il prévoit de concevoir un jeu de tâches plus complexe si les prochains modèles réussissent l'ensemble actuel. Il relève aussi que les performances obtenues sur ce test corrèlent avec d'autres benchmarks existants, ce qui constitue, selon lui, un signal encourageant pour la validité de la méthode.

Plusieurs questions restent ouvertes. La première concerne la difficulté : rien n'indique aujourd'hui où se situe le seuil à partir duquel un langage inédit cesserait de distinguer compréhension et mémorisation. La seconde tient à la part respective des garde-fous de sécurité et des capacités proprement techniques dans les échecs observés, un point que les résultats publiés ne permettent pas de trancher à eux seuls. Le code de l'interpréteur et la spécification sont disponibles sur GitHub, ce qui permettra à d'autres d'évaluer la méthode et de reproduire les tests.