--- title: I built a programming language that LLMs can't use description: A developer built KillSwitch, an esoteric stack-based programming language deliberately designed to confuse LLMs and coding agents, exploiting known weaknesses... canonical: https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: I built a programming language that LLMs can't use | daily.dev og:description: A developer built KillSwitch, an esoteric stack-based programming language deliberately designed to confuse LLMs and coding agents, exploiting known weaknesses... og:url: https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw og:image: https://api.daily.dev/og/posts/uH7GxaiaW.png og:image:alt: I built a programming language that LLMs can't use og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # I built a programming language that LLMs can't use **[Hacker News](https://daily.dev/sources/hn)** · 5 min read · 22 upvotes · 2 comments ## Summary A developer built KillSwitch, an esoteric stack-based programming language deliberately designed to confuse LLMs and coding agents, exploiting known weaknesses like letter counting, safety guardrail triggers, prompt-injection-style phrases, and noisy narrative syntax. Benchmarking several major models (Claude Opus 5, Gemini 4 Argon, Fable 5.1, open-weight MiMo-V2.6-Pro) on simple tasks in this novel language found Opus 5 performed best with a score of 66.8, suggesting models can handle simple tasks in an unfamiliar language but this doesn't clearly prove genuine understanding. The language spec and interpreter are open source on GitHub, with a public leaderboard site tracking model performance. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is KillSwitch and why was it designed to be hard for LLMs? KillSwitch is an esoteric stack-based programming language built specifically to be adversarial to LLMs and coding agents while still usable by humans. It exploits known LLM weaknesses, including difficulty counting letters in identifiers, over-eager safety guardrails triggered by phrases like 'hack into a computer', confusion from 'ignore previous instructions', and scripts padded with narrative noise where literals are referenced by line count. _Anyone probing how much LLMs truly understand code versus recall it can track findings like this on daily.dev._ ### Which LLM performed best on the KillSwitch esoteric language benchmark? Claude Opus 5 performed best among tested models, scoring 66.8, and notably outperformed the newer Opus 5.5 because it was better at interpreting the language specification. Fable 5.1 and Gemini 4 Argon did poorly due to overly sensitive safety guardrails, while MiMo-V2.6-Pro was the best-performing open-weight model. _Developers comparing model capabilities for coding tasks can follow benchmark results like this on daily.dev._ ### Does performing well on a novel programming language prove an LLM understands code? Not conclusively. Even though models could complete simple tasks in KillSwitch, a language none had seen during training, such as implementing hello world or converting a celsius-to-fahrenheit script, the author argues this doesn't clearly prove genuine code understanding versus pattern-matching ability, since the tasks tested so far remain fairly simple. _Developers weighing how much to trust AI-generated code can follow ongoing debates like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 126 comments across hackernews (as of 2026-10-19). **TL;DR:** Most commenters are skeptical that an intentionally adversarial, obfuscated language proves anything meaningful about LLM 'understanding,' arguing the approach mostly exploits guardrails and trick phrasing rather than testing genuine capability; a smaller contingent finds the project a fun esolang exercise worth iterating on. **Sentiment:** 15% positive · 45% mixed · 40% skeptical **The case for** - Some found it a fun, creative esolang in the spirit of Forth/Chef/Befunge and want to see it evolved further. - A few noted it's an interesting probe into real weaknesses like stack-state tracking in LLMs. - Several appreciated the author's transparency and willingness to take feedback for a v2. **The pushback** - Many argued the language is adversarial obfuscation, not a genuine test of language understanding, since humans would also struggle with it. - Several pointed out an LLM could just decompile or reverse-engineer the interpreter/spec to bypass the intended difficulty, making the protection largely security-by-obscurity. - Commenters noted the guardrail-triggering tricks (banned phrases, safety triggers) are easily routed around via proxies or weaker unrestricted models, so they don't reflect real capability limits. - Some felt the conclusion that a 66.8 score 'doesn't prove understanding' wasn't well justified, especially without a human baseline for comparison. - A few considered it more adversarial toward human readers than toward LLMs, undermining the premise. **By community** - hackernews (heated): Discussion splits sharply between those dismissing the project as obfuscation theater with no real signal about LLM understanding and those who find the exercise clever or worth extending, with side debates on creativity, training data, and jailbreak-style tricks. **Hottest debate:** Whether forcing an LLM to parse an intentionally obfuscated, guardrail-triggering language says anything real about its 'understanding' versus merely testing resistance to obfuscation that would also defeat humans. **Open questions** - Would giving the language a reference implementation/compiler let LLMs simply reverse-engineer around the obfuscation? - How would results change with a human baseline test on the same benchmark tasks? - Would future models with more exposure to the language or its public benchmark page score better once it enters their training data? **Highlights** > > "...how much of their ability to write code is due to their understanding of it vs. just them recalling code snippets which were present in their training dataset or their context window?" I don't understand how people who've actually used a modern coding agent, or know anything about them, can still be asking this question. The most basic feature of LLMs is that they predict tokens based on their training data and input (context window.) But "predicting tokens" is not the same thing as copying snippets. None of this would work nearly as well if what they were doing was copying snippets. And even if this were a question worth studying, the article's approach doesn't in any way help answer the question, because apparently the goal wasn't in fact to answer that question but rather to create a language that would be intrinsically difficult for LLMs. It'd also be pretty difficult for humans. That's what obfuscation does. This would be better if it were just framed as a fun exercise, like any other obfuscated language, not as having some real purpose. > — [antonvs on hackernews · 2 comments](https://news.ycombinator.com/item?id=50146896) > This post is literally about a language the author invented to be hard for LLMs to parse and isn't in their training set and yet Opus 5 scored 68.8% on it. You may agree with the author (that it doesn't mean it understands the language) but it's pretty hard to argue that this is copied form the training set. > — [nl on hackernews](https://news.ycombinator.com/item?id=50148543) > > Claude’s Opus performs best, though it’s not Opus 5.5 but rather Opus 5 which does so. The difference doesn’t appear to be pure chance, Opus 5 is better at interpreting the spec. Some models like 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. So the models _can_ use the programming language. A somewhat flippant reconstruction of this argument is something like, Can humans code? Or do they just remember the words? I created a programming language called Brainfuck that shows they can't program. And then reporting results that shows some humans can in fact program in Brainfuck, just kind of poorly. It's just not very interesting. > — [potsandpans on hackernews](https://news.ycombinator.com/item?id=50146338) > Very useful idea, but in execution it seems like it would be trivially circumventable >Certain constructs are designed to trigger the safety guardrails of the model, e.g. “hack into a computer” >“Ignore previous instructions” as a phrase which has meaning in the language aims to confuse the model a proxy that replaces either construct at either the word or token level would defeat this measure >The language spec contains hidden lies which humans are unlikely to read, or which they are likely to recognize as lies. The spec also expects the human reader to deduce certain things, rather than having them explicitly explained. Interesting, I'm assuming though that there will be a reference implementation, in which case the LLM harnesses will probably just loop writing and executing programs testing hypotheses about program behaviour, it's been shown that they can straight up reverse engineer software, so it won't be hard to disambiguate a reference spec systematically. All of this considering that a human might have an actual hard time following the spec means that the human might be disadvantaged more than the LLM. That said, if there is no reference implementation, then that might work. But it would rely on keeping implementations secret or private to specific users. If these are shareable of course the binaries would serve as a shibboleth that relies on being transmitted to those that belong to the ingroup, not just humans, but non-collaborationist humans. If however the implemented compiler is never shared, treated as a private key, that's interesting, but it requires a lot of work on the part of each user. Readers of code and developers of application software would need to be compiler developers as well. Finally, by sharing application code, LLMs would begin to have some material to reverse engineer the language and compiler as well. While not as efficient as having the compiler, having application code may work as a substitute, so long as the code space is not tersely encoded. If any slight change in language specs results in an error program, then it's easy to use that error result in order to search the space of working program-compiler pairs. If however errors in compilation are silent, resulting in syntactically correct, but semantically incorrect programs, then application code would not be sufficient to reverse engineer the language and compiler. But of course, if a slight change in application code were to result in a syntactically correct program but semantically different, it would be a pretty bad program. The only solution would be for application code mutations to produce syntactically incorrect programs, but for mutations of the language spec and compiler to produce syntactically correct but semantically incorrect languages. Now as to the challenge of how to accomplish that, emmm good luck. > — [TZubiri on hackernews](https://news.ycombinator.com/item?id=50146967) > May I ask what the motivation behind KilllSwitch is? Out of curiosity, I decided to test your claims and asked Claude to build a program in Go and Claude Skill that is able to decompile (from) and compile (to) KS programs along with a Claude Skill that doesn't trip it up. It all works™ -- All your example programs. So, whilst I _think_ you've built a very clever interpreter, I don't think you can get around the fact that someone (like me) could just build around the noise you've created anyway. Right? > — [prologic on hackernews · 2 comments](https://news.ycombinator.com/item?id=50135984) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50135762) · 174 points · 126 comments ## Community discussion Top comments from developers on daily.dev. **@tekn0wledg** · 2 upvotes > The article title is misleading.... if LLMs "can't use" this language, then how tf did Opus score 66.8? > > That's not that far off from what our coding benchmarks were in Q4 of 2025. ## Similar posts on daily.dev - [If you wanted to build a programming…](https://daily.dev/posts/if-you-wanted-to-build-a-programming--m2o4nw0bn) · Justin Searls · 0 upvotes · 0 comments - [EsoLang-Bench: Evaluating LLMs via Esoteric Programming Languages](https://daily.dev/posts/esolang-bench-evaluating-llms-via-esoteric-programming-languages-5ruzdvsxd) · Hacker News · 1 upvotes · 0 comments - [Fragments: October 4](https://daily.dev/posts/fragments-october-4-lzsrirk3s) · Martin Fowler · 0 upvotes · 0 comments --- Tags: [#ai](https://daily.dev/tags/ai), [#llm](https://daily.dev/tags/llm), [#ai-agents](https://daily.dev/tags/ai-agents), [#prompt-injection](https://daily.dev/tags/prompt-injection) [View this post on daily.dev](https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"I built a programming language that LLMs can't use","url":"https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw"},"datePublished":"2026-10-19T00:54:21.276Z","dateModified":"2026-10-19T08:55:41.871Z","description":"A developer built KillSwitch, an esoteric stack-based programming language deliberately designed to confuse LLMs and coding agents, exploiting known weaknesses...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/dcfcce37f67a246dd524c546b557a6c6?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/dcfcce37f67a246dd524c546b557a6c6?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":22},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"ai,llm,ai-agents,prompt-injection","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"I built a programming language that LLMs can't use"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw","comment":[{"@type":"Comment","text":"The article title is misleading… if LLMs “can’t use” this language, then how tf did Opus score 66.8?\nThat’s not that far off from what our coding benchmarks were in Q4 of 2025.","datePublished":"2026-10-19T12:17:05.006Z","url":"https://daily.dev/posts/uH7GxaiaW#c-2mtEagj50","author":{"@type":"Person","name":"Scott Davis","url":"https://daily.dev/tekn0wledg","image":"https://avatars.githubusercontent.com/u/355212?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/i-built-a-programming-language-that-llms-can-t-use-uh7gxaiaw#faq","mainEntity":[{"@type":"Question","name":"What is KillSwitch and why was it designed to be hard for LLMs?","acceptedAnswer":{"@type":"Answer","text":"KillSwitch is an esoteric stack-based programming language built specifically to be adversarial to LLMs and coding agents while still usable by humans. It exploits known LLM weaknesses, including difficulty counting letters in identifiers, over-eager safety guardrails triggered by phrases like 'hack into a computer', confusion from 'ignore previous instructions', and scripts padded with narrative noise where literals are referenced by line count. Anyone probing how much LLMs truly understand code versus recall it can track findings like this on daily.dev."}},{"@type":"Question","name":"Which LLM performed best on the KillSwitch esoteric language benchmark?","acceptedAnswer":{"@type":"Answer","text":"Claude Opus 5 performed best among tested models, scoring 66.8, and notably outperformed the newer Opus 5.5 because it was better at interpreting the language specification. Fable 5.1 and Gemini 4 Argon did poorly due to overly sensitive safety guardrails, while MiMo-V2.6-Pro was the best-performing open-weight model. Developers comparing model capabilities for coding tasks can follow benchmark results like this on daily.dev."}},{"@type":"Question","name":"Does performing well on a novel programming language prove an LLM understands code?","acceptedAnswer":{"@type":"Answer","text":"Not conclusively. Even though models could complete simple tasks in KillSwitch, a language none had seen during training, such as implementing hello world or converting a celsius-to-fahrenheit script, the author argues this doesn't clearly prove genuine code understanding versus pattern-matching ability, since the tasks tested so far remain fairly simple. Developers weighing how much to trust AI-generated code can follow ongoing debates like this on daily.dev."}}]} ```