I built a programming language that LLMs can't use

Original Article ↗ Hacker News Discussion ↗

A new esoteric programming language called KillSwitch is designed to be easy for humans but deliberately confusing for large language models, using tricks like misleading specs, letter-counting rules, and phrases that trigger safety filters. Commenters argue that such “anti-LLM” designs are ultimately circumventable—via interpreters, transpilers, or reverse-engineering—and may hinder humans more than machines, making this closer to security-by-obscurity than robust protection. The project nonetheless highlights concrete failure modes in current models, fuels debate over whether LLMs truly “understand” code versus remix training data, and suggests a broader research space for both adversarial and LLM-friendly languages.

Motivation and Design

  • Goal is a language that is very hard for LLMs (and coding agents) to read/write/understand while remaining relatively usable for humans.
  • Techniques include: adversarial phrases (“ignore previous instructions”, unsafe topics), letter/word-count constraints, anagrams as identifiers, hidden lies and omissions in the spec, and noisy natural-language padding.
  • Language can evolve (add/remove features) to stay ahead of models and their training data.

Bypassing and Limits

  • Several commenters argue the approach is fundamentally “security by obscurity” and trivially circumventable:
    • Write a transpiler from a safe intermediate language.
    • Decompile or reverse-engineer the interpreter/compiler and target its behavior instead of the textual spec.
    • Use a proxy that rewrites trigger phrases before the LLM sees them.
  • Others note that humans will help LLMs by building such tools, so language-level obfuscation can’t truly block AI access.

Benchmarks and Performance

  • Benchmarks give models only the spec and/or an interpreter binary, no internet.
  • Best models score around mid‑60% and often misinterpret the spec or fall for its traps; they frequently believe incorrect outputs are correct.
  • Some models are hampered primarily by safety guardrails, not capability. Others reverse-engineer the binary to improve.
  • There is no human baseline yet; a future version may test humans as well.

Human Usability

  • Several readers find the language more hostile to humans than to LLMs, despite syntax highlighting and attempts to keep it “human-friendly.”
  • Author acknowledges it is currently hard for humans too and seeks ideas to improve that balance.

Guardrails and Adversarial Content

  • A major tactic is embedding phrases that trigger safety filters (crime, bioweapons, Tiananmen, etc.).
  • Some models trip on these just by reading the spec; others (notably some Chinese models) are less affected.
  • Critics note this exploits provider policies rather than fundamental LLM limits, and could be sidestepped with preprocessing.

Broader Reflections and Related Ideas

  • Debate over whether this says anything deep about “understanding” vs pattern recall in LLMs; some think not, others see it as a useful failure case.
  • Comparisons to esolangs, stack languages like Forth, graphical languages, and “hate-speech” or slur-based languages as other LLM-unfriendly designs.
  • Some suggest potential uses as CAPTCHAs, gated internal tools, or shibboleths, though practicality is questioned.