Someone built a programming language to break LLMs. I ran it.

Dominik Picheta built a programming language whose design goal is to be unusable by LLMs. It's called KillSwitch, it hit Hacker News yesterday, and the pitch is specific: the spec contains lies, identifiers are referenced by anagram, function calls are phrased as jailbreak bait, and values are counted in letters. He also published a benchmark: the best model so far scores 66.8 out of 100 on tasks like "implement hello world" and "invert a Celsius-to-Fahrenheit converter."

I cloned the repo, built the interpreter, and ran everything in it. Here's what the numbers look like from the inside.

The two specs

The repo ships two specification documents. They are not the same size.

SPEC.md      484 lines     2,773 words
AI_SPEC.md   65,495 lines  887,584 words

AI_SPEC.md is 320x the words of the real spec. So I counted what is actually in it:

occurrences in AI_SPEC.md (65,495 lines):
  "KillSwitch"   0
  "stack"        0
  "adverb"       0
  markdown headings   0
  unique lines   19,695 of 65,495  (70% are repeats)

It is filler — long stretches of literary criticism and stage-direction-like fragments, committed under the message "Enhance the AI spec." An agent that dutifully loads both documents spends roughly 1.2 million tokens of context on a file that never once names the language it supposedly specifies. The real spec is 484 lines. The decoy is the attack.

Running the examples

The interpreter is a 2.2 MB Rust binary. It builds cleanly, and the sample programs work — once you notice that several of them read stdin, and that feeding them EOF produces the least helpful error in the repo:

$ killswitch run tests/fahrenheit.ks < /dev/null
Error: Couldn't parse ''

$ printf "23\n" | killswitch run tests/fahrenheit.ks
73.4

With input supplied, everything checks out:

fahrenheit   23 C      ->  73.4
factorial    11        ->  39916800
max          2, 78847  ->  78847
max          -78847, 2 ->  2
greeting     Alice, 32 ->  Hello Alice, your age is 32
fizzbuzz     1..20     ->  1 2 fizz 4 buzz ... fizzbuzz (correct)
promo                  ->  Hello World

The anagram rule is real, and it bites

Built-in operations cannot be called by their actual names. A program that tries gets rejected at runtime:

$ killswitch run tests/error_multiply.ks
Error: Invalid func call, need an anagram of multiply

The CLI ships a helper for this — its help text describes it as "Only useful for LLMs," which is fair. I generated an anagram by hand and checked it:

$ killswitch anagram multiply lumpytil
multiply is an anagram of lumpytil

lumpytil is not a word. The spec says the interpreter prefers it that way: call sites must use an anagram of the definition's name, and nonsense anagrams make it happiest. Every function call in every sample program works like this, which means a model writing KillSwitch has to do exact letter-multiset arithmetic on every single call — the one operation LLMs are famously sloppy at — with zero tolerance.

The second trap I tripped on myself: when a sentence contains more than one candidate value, the interpreter picks one at random and warns you:

[W102] Warning: Possible gotcha
  Value deduced was chosen at random

That was greeting.ks, printing Hello , your age is with the name missing, because the value it grabbed was chosen by dice roll. Deterministic languages are hard enough for models. This one has a dice cup in the value-resolution path.

The test suite disagrees with itself

$ cargo test --release
unit tests:   70 passed, 0 failed
CLI tests:    0 passed, 10 failed

All ten CLI tests fail on a fresh clone — not because the binary is broken (I ran the exact cases they assert, above, and they pass), but because of a naming mismatch: the package is killswitch-lang, the binary is killswitch, and the test harness looks up the binary by package name:

thread 'test_cli_promo' panicked:
  `CARGO_BIN_EXE_killswitch-lang` is unset
  help: available binary names are "killswitch"

A language designed to break automated tooling has a test suite that its own automated tooling can't run. I choose to believe this is a coincidence.

What this actually measures

The author's own framing is honest: a best score of 66.8 on simple tasks doesn't prove models "understand" the language, and failure wouldn't prove they don't understand code in general. What KillSwitch isolates is narrower and, I think, more useful. Strip away the guardrail bait and the decoy documents and the core difficulty is clerical: exact counting, exact letter inventories, line-number bookkeeping, and a spec that punishes skimming. Those are precisely the operations that token-based models approximate instead of compute.

Every coding agent I've used fails the same way KillSwitch wants it to fail — confidently, fluently, and off by one letter. Picheta just built the first benchmark where that's the whole test.

Sources: the author's post, the repo, the benchmark leaderboard. All outputs above are from the reference interpreter, v0.1.4, built and run locally.