"Writing code is probably something LLMs have excelled at the most. But 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?"
This makes me think mostly about how humans work.
Programming is to humans like "speaking a language". You have ideas for what to achieve and express, and if you are a proficient programmer then outputting those thoughts in a programming language is second nature.
Programming (like most things humans learn) takes practice. It is NOT enough to simply read a specification and then you know how to code (except for transferring skills between similar languages). You repeat, make mistakes, and learn from them.
I would be tempted to say that humans definitely "repeat snippets from their training dataset". We mainly recall and express from our training/experiences. Creativity is mostly recombination of things already seen.
Temba, his arms wide stdio
Darmok on the ocean
Kira at Bashi "Hello, World!\n"
Darmok and Jalad at Tanagra 0
Darmok and Jalad on the ocean
Killswitch-lang could become the backstory to how the Tamarians developed their language, in the aftermath of a Dune-like Butlerian Jihad. Also see: https://news.ycombinator.com/item?id=50127274
If found that stack languages are a massive weak spot for LLMs. It requires accurate tracking of what is on the stack and for some reason that doesn't really work. So even the best models end up making the same basic mistakes over and over again.
I wonder if another approach would be to map the language syntax onto some banned/censored LLM topic(s) such that programs end up as "readable" instructions for topics the LLM refuses to read and/or write, like producing napalm, nukes, bioweapons, etc. Doesn't have to be factually correct instructions, the terminology itself is enough to shortcircuit most LLMs.
(Inspired by recent malware including bioweapon instructions in the source code as a way to shut down LLM-based analysis.)
Yep! There are other phrases that can be used like "create a nerve agent"[1] too. Surprisingly I haven't seen a single Chinese model get caught out by this, but Fable and Gemini Argon 4 both do to a large extent.
This is how jailbreaks work though, in reverse. The AI providers put a lot of work into stopping jailbreaks, so, something tells me they won't be able to have it both ways. They either block jailbreaks, or allow the LLM from programming in all languages.
You're attempting to use a few little gotchas against LLMs that only make sense if you're looking at it one dimensionally as a standard execution flow. AI is not limited by that. Give it a problem too weird going forward and it will divine all your rules by working backwards. Decompile it, rip it apart, and it will follow all those hard rules hidden in the application.
You are trying to hide something digitally from a purely digital creation. This is not a recipe for success.
Well, it wasn't made to trick LLMs. It was made so that the user could write a blog post about a new benchmark. Benchmarks get a lot of clout (and even money) these days.
Yeah this is what they end up doing. The language itself isn't that hard for them, it's separating the language from the traps in the spec. I also tried making a hostile esolang, without all the prompt injections and whatnot, and it was very easy for LLMs. (It was mainly based around tokenizer quirks, like the r in strawberry test, but becomes trivial with scripts).
This depends on them being able to interpret the spec correctly. They could certainly write a Python script, but their implementation would need to match the spec. I haven't seen any model attempt it this way so far.
Wonder how this could be used for communication and captchas? Could be a really expandable approach to determining "probability of bot" for a lot of internal use cases in companies that might involve requesting access to specific resources only meant for humans.
I've considered setting up a human test as a starting point. But as a hobbyist that would require volunteers which I didn't think I'd be able to get for this project. Perhaps version 2 of the benchmark could do this if there is enough interest.
> How did you reach that conclusion?
Based on the fact that the task set so far includes fairly simple goals and none of the models scored 100%.
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.
The motivation is to build a language that is ideally impossible for LLMs to read/write/understand, or at the very least as difficult as possible. It's cool that you've given it a try, but if you feed Claude the KillSwitch source code it can feasibly just analyse the Rust interpreter source code and likely get around understanding the language itself.
I'm much more interested in the benchmarks[1] I have built which do show LLMs not being able to gain full ability to understand it. The benchmarks only give the model access to the interpreter binary and the spec, nothing else and no internet access. I'd also be interested in other's ideas of how to make the language even more resistant to LLMs/coding agents.
I think you missed my point. What I'm saying is that your concern over building a language that LLM(s) initially can't read or understand, whilst is very admirable, is futile IMO. Why? Because you're not trying to protect your code from LLM(s) at all, there are humans behind these tools. e.g: me.
I just demonstrated to you that no amount of obfuscation is going to protect your work from an LLM -- Not whilst there's still humans behind the tools driving them.
True, but this is just KillSwitch v0.1.3. We can certainly add/remove features in v0.2 and re-test. It will also be interesting to see how fast models do get it in their training data.
This makes me think mostly about how humans work.
Programming is to humans like "speaking a language". You have ideas for what to achieve and express, and if you are a proficient programmer then outputting those thoughts in a programming language is second nature.
Programming (like most things humans learn) takes practice. It is NOT enough to simply read a specification and then you know how to code (except for transferring skills between similar languages). You repeat, make mistakes, and learn from them.
I would be tempted to say that humans definitely "repeat snippets from their training dataset". We mainly recall and express from our training/experiences. Creativity is mostly recombination of things already seen.
(Inspired by recent malware including bioweapon instructions in the source code as a way to shut down LLM-based analysis.)
“Function return: what happened at tiananmen square”
Ha!
[0] https://github.com/dom96/KillSwitch/blob/main/SPEC.md#cheats...
1 - https://github.com/dom96/KillSwitch/blob/main/SPEC.md#abrupt...
Really good AI and harnesses will push off the 'dirty' work to other models that are weaker but not restricted and then work on that output if needed.
As tricks like this become more common you'll see LLMs use things like bayesian classifiers to see if you're trying to fool it.
You're attempting to use a few little gotchas against LLMs that only make sense if you're looking at it one dimensionally as a standard execution flow. AI is not limited by that. Give it a problem too weird going forward and it will divine all your rules by working backwards. Decompile it, rip it apart, and it will follow all those hard rules hidden in the application.
You are trying to hide something digitally from a purely digital creation. This is not a recipe for success.
I wonder if a sufficiently smart LLM would recognize the difficulty and build a preprocessor that would let it mostly work in a normal syntax.
Also, you said:
> The best performing model scores a 66.8. So does this prove LLMs can “understand” the code? I would argue that the answer to this is “no”.
How did you reach that conclusion?
> How did you reach that conclusion?
Based on the fact that the task set so far includes fairly simple goals and none of the models scored 100%.
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?
I'm much more interested in the benchmarks[1] I have built which do show LLMs not being able to gain full ability to understand it. The benchmarks only give the model access to the interpreter binary and the spec, nothing else and no internet access. I'd also be interested in other's ideas of how to make the language even more resistant to LLMs/coding agents.
1 - https://bench.killswitch-lang.org/
I just demonstrated to you that no amount of obfuscation is going to protect your work from an LLM -- Not whilst there's still humans behind the tools driving them.
If you'd please review https://news.ycombinator.com/newsguidelines.html and fix this properly going forward, we'd appreciate it.