Killing the LLM instinct

Writing code is probably something large language models have excelled at more than any other task. But how much of their ability to write code stems from genuine understanding versus simply recalling snippets that appeared in their training data or context window? That question motivated the creation of a programming language that is usable for humans but deliberately difficult for LLMs and coding agents.

The language, called KillSwitch, is esoteric by design. Its spec contains hidden lies that a human reader is unlikely to encounter or would recognize as false; the specification also expects the reader to deduce certain things rather than having everything explicitly explained. One of the most striking features is that counting letters in identifiers is crucial—the interpreter refuses to execute code that does not abide by rules based on character counts.

Certain constructs are designed to trigger the safety guardrails of a model, for example phrases like "hack into a computer." Another aimed-to-confuse phrase is "ignore previous instructions," which has meaning within the language. Scripts are mostly noise, being mostly composed of stories that can embed syntactically relevant instructions but do not need to. Literals can be placed anywhere within a script and then referenced using line counts.

Fundamentally, KillSwitch is a stack-based interpreted language with only a limited set of constructs including functions, variables and if statements. Those aspects should feel familiar to any LLM—and to any human. The language does not attempt to be completely unlike anything that has been created before; rather, it exploits known weaknesses of current models as a first attempt.

Most text inside a script is ignored by the interpreter. In the case where the goal is to push "Hello World" onto the stack, the instruction "value 2 lines above" does the job. The example shown is only a small snippet; a full Hello World example is available on the project website.

The interpreter and language specification of KillSwitch are open source and available on GitHub. Those who wish to learn more can examine the code and the detailed specification.

Benchmarking against models

To measure how well various models handle the language, a set of tasks was devised and run against major LLM models and coding agent harnesses. The results provide a useful leaderboard for LLM performance on this novel, adversarial language.

Claude's Opus performs best, though it is Opus 5 rather than any 5.5 variant. The difference does not appear to be pure chance—Opus 5 is better at interpreting the spec. Some models, such as Fable 5.1 and Gemini 4 Argon, do poorly due to their overly sensitive safety guardrails. The best open-weight model is MiMo-V2.6-Pro.

The best performing model scores 66.8. Does this prove LLMs can "understand" the code? I would argue that the answer is no. So far the tasks given as part of these benchmarks are fairly simple: "implement hello world," "explain what this script will output" (for a script printing the maximum of two numbers), and "modify an existing script converting Celsius to Fahrenheit, to do the inverse conversion." It is impressive that they can solve these tasks for a novel language built to confuse them, but it is not a clear signal that they understand the language. At the same time, I cannot help but wonder what an even more difficult language might show. For now I am eager to see how well soon-to-be-released models handle the current set of tasks, and if they complete them all successfully, another task set which is more complex will be devised.

If nothing else, it is encouraging that model performance on this simple set of tasks correlates with other model benchmarks that are out there.

What the language does well

KillSwitch achieves its goal of being adversarial to LLMs in several ways. The hidden lies in the spec force the reader—whether human or model—to look more carefully at what is actually being said rather than absorbing text at face value. Letter counting in identifiers means that even a small mistake in naming will cause the interpreter to reject the code. Safety guardrail triggers such as "hack into a computer" make models hesitate or refuse, even when the intent is purely educational or demonstrative. The "ignore previous instructions" phrase creates confusion because models are trained to follow user prompts literally. And the noisy-script structure, where most text is story-like and only certain lines carry syntactic weight, means that simple pattern-matching based on training data is less effective.

These features together make it significantly harder for a model to simply retrieve and reproduce code without actually parsing and understanding the language's rules.

Limitations of the current benchmark

The tasks released so far are intentionally narrow. They test basic operations like printing hello world, reasoning about output, and performing a conversion task. These are the kinds of problems that models frequently solve by pattern completion rather than deep reasoning. The fact that some models score well does not mean they have achieved genuine language understanding; it may mean they have internalized enough of the spec's patterns to guess correctly on these particular examples.

The author acknowledges that the current benchmark is a starting point. More complex tasks are planned, and the community is invited to contribute ideas for measuring whether an LLM has truly internalized a programming language or is merely recalling memorized snippets.

Taking the idea further

One can definitely imagine creating a completely different programming language paradigm that could confuse LLMs even more. A different paradigm—perhaps one based on entirely different control flow, type systems, or execution models—might reveal more about the boundary between memorization and understanding. For now, KillSwitch stands as a functional experiment in that direction.

Those who want to try the language themselves can find the interpreter, specification, and benchmark results on the project's GitHub and at the benchmarking website. The author welcomes anyone building something similar or wanting to steal ideas to reply and share their work.