Creator here. This started as a dumb question while using Claude Code: "Why is Claude writing TypeScript I'm supposed to read?"
40% of code is now machine-written. That number's only going up. So I spent some weekends asking: what would an intermediate language look like if we stopped pretending humans are the authors?
NERD is the experiment.
Bootstrap compiler works, compiles to native via LLVM. It's rough, probably wrong in interesting ways, but it runs.
Could be a terrible idea. Could be onto something. Either way, it was a fun rabbit hole.
I like the idea, but this is going be a very very long journey to develop a completely new machine-friendly language like this while LLMs still have many limitations now.
Now that we know code is a killer app for LLMs, why would we keep tokenizing code as if it were human language? I would expect someone's fixing their tokenizer to densify existing code patterns for upcoming training runs (and make them more semantically aligned).
Interesting. I've had a similar idea for some time, but originating from near opposite intent. I'd like to see LLMs generate natural language that can be executed by machine, but remains very readable by someone who's never learned a programming language.
I think the idea is solid, but the specifics are more involved than just making sure that it maps nicely to tokens.
One thing in particular that I've noticed is that many of language features that enable concise code - such as e.g. type inference - are counter-productive for LLMs because they are essentially implicit context, and LLMs much prefer such things to be explicit. I suspect that e.g. forcing the model to spell out the type of every non-trivial expression in full would have an effect similar to explicit chain-of-thought.
Similarly I think that the ability to write deeply recursive expressions is not necessarily a good thing, and an LLM-centric language should deliberately limit that and require explicit variables to bind intermediate results to.
The single biggest factor though seems to be the ability to ground the model through tooling. Static typing helps a lot there, as do explicit purity annotations for code, and so does automated testing, but one area that I would particularly like to explore for LLM use is design-by-contract.
On New Year's Eve I announced NERD - a language built for LLMs, not for human authorship. The response was unexpectedly overwhelming. Questions, excitement, discussions, roasting - all of it.
But one question struck me: "What use case is this language built for?"
Fair. Instead of a general-purpose language covering all features - some of which may not even be relevant because we're not building apps the old way anymore - I picked one: agent-first.
What this means - you can now run an agent in NERD with one line of code:
-- Nerd code
llm claude "What is Cloudflare Workers?"
No imports. No boilerplate. No framework.
The insight from working with agents and MCP: tools are absorbing integration complexity. Auth, retries, rate limiting - all moving into tool providers. What's left for agents? Orchestration.
And orchestration doesn't need much:
→ LLM calls
→ Tool calls
→ Control flow
→ That's it.
Every language today - Python, TypeScript, Java - was built for something else, then repurposed for agents. NERD starts from agents.
tokens are tokens, shorter or larger, they are tokens
in that sense I don't see how this is more succinct than phyton
it is more than typescript and c#, of course, but we need to compete with the laconic languages
in that sense you will end up with Cisc vs Risc dilemma from the cpu wars. you will find the ability to compress even more is adding new tokens to compress repetitive tasks like sha256 being a single token. I feel that's a way to compress even more
One major disadvantage here is the lack of training data on a "new" language, even if it's more efficient. At least in the short term, this means needing to teach the LLM your language in the context window.
I've spent a good bit of time exploring this space in the context of web frameworks and templating languages. One technique that's been highly effective is starting with a _very_ minimal language with only the most basic concepts. Describe that to the LLM, ask it to solve a small scale problem (which the language is likely not yet capable of doing), and see what kinds of APIs or syntax it hallucinates. Then add that to your language, and repeat. Obviously there's room for adjustment along the way, but we've found this process is able to cut many many lines from the system prompts that are otherwise needed to explain new syntax styles to the LLM.
That looks to me like Forth with extra steps and less clarity? Not sure why I'd choose it over something with the same semantic advantages ("terse english" but in a programming language), but just agressively worse for a human operator to debug.
> Do you debug JVM bytecode? V8's internals? No. You debug at your abstraction layer
In the fullness of time, you end up having to. Or at least I have. Which is why I always dislike additional layers and transforms at this point.
(eg. when I think about react native on android, I hear "now I'll have to be excellent at react/javascript and android/java/kotlin and C++ to be able to debug the bridge; not that "I can get away with just javascript".)
I can’t be alone in this, but this seems like a supremely terrible idea. I reject whole heartedly the idea that any sizeable portion of one’s code base should specifically /not/ be human interpretable as a design choice.
There’s a chance this is a joke, but even if it is I don’t wanna give the AI tech bros more terrible ideas, they have enough. ;)
> Do you debug JVM bytecode? V8's internals? No. You debug at your abstraction layer. If that layer is natural language, debugging becomes: "Hey Claude, the login is failing for users with + in their email."
I debug at my abstraction layer because I can trust that my compiler actually works, LLMs are fundamentally different and need to produce human readable code.
Uh, I think every form of (physical or virtual, with some pedagogic exceptions) machine code beats Nerd as an earlier “programming language not built for humans”.
I have the exact opposite prediction. LLMs may end up writing most code, but humans will still want to review what's being written. We should instead be making life easier for humans with more verbose syntax since it's all the same to an LLM. Information dense code is fun to write but not so much to read.
Would it make more sense to instead train a model and tokenise the syntax of languages differently so that white space isn’t counted, keywords are all a single token each and so on?
I was going to try and resist posting for as long as possible in 2026 (self dare) and here I am on day 1 -- this is a pretty bad idea. are you going to trust the llm to write software you depend on with your life? your money? your whatever? worst idea so far of 2026. wheres the accountability when things go wrong?
I can't speak for the author, but I do often do this. IMO it's a misleading comparison though, you don't have to debug those things because rarely does the compiler output incorrect code compared to the code you provided, it's not so simple for an LLM.
A curly brace is multiple tokens? Even in models trained to read and write code? Even if true, I’m not sure how much that matters, but if it does, it can be fixed.
Imagine saying existing human languages like English are “inefficient” for LLMs so we need to invent a new language. The whole thing LLMs are good at is producing output that resembles their training data, right?
the real question isn't "should AI write readable code" but "where in the stack does human comprehension become necessary?" we already have layers where machine-optimized formats dominate (bytecode, machine code, optimized IR). the source layer stays readable because it's the interface where human judgment enters.
maybe AI should write better readable code than humans. more consistent naming, clearer structure, better comments. precisely because humans only "skim". optimize for skimmability and debuggability, not keystroke efficiency.
‘So why make AI write in a format optimized for human readers who aren't reading?’ well yo’ll do when you needed to. sooner or later. but i like the idea anyway
If you're going to set TypeScript as the bar, why not a bidirectional transpile-to-NERD layer? That way you get to see how the LLM handles your experiment, don't have to write a whole new language, and can integrate with an existing ecosystem for free.
Seems like engagement bait or a thought exercise more than a realistic project.
> "But I need to debug!"
> Do you debug JVM bytecode? V8's internals? No. You debug at your abstraction layer. If that layer is natural language, debugging becomes: "Hey Claude, the login is failing for users with + in their email."
Folks can get away without reading assembly only when the compiler is reliable. English -> code compilation by llms is not reliable. It will become more reliable, but (a) isn’t now so I guess this is a project to “provoke thought” (b) you’re going to need several nines of reliability, which I would bet against in any sane timeframe (b) English isn’t well specified enough to have “correct” compilation, so unclear if “several nines of reliability” is even theoretically possible.
This is a 21st-century equivalent of leaving short words ("of", "the", "in") out of telegrams because telegraph operators charged by the word. That caused plenty of problems in comprehension… this is probably much worse because it's being applied to extremely complex and highly structured messages.
It seems like a short-sighted solution to a problem that is either transient or negligible in the long run. "Make code nearly unreadable to deal with inefficient tokenization and/or a weird cost model for LLMs."
I strongly question the idea that code can be effectively audited by humans if it can't be read by humans.
63 comments
[ 2.7 ms ] story [ 79.7 ms ] thread40% of code is now machine-written. That number's only going up. So I spent some weekends asking: what would an intermediate language look like if we stopped pretending humans are the authors?
NERD is the experiment.
Bootstrap compiler works, compiles to native via LLVM. It's rough, probably wrong in interesting ways, but it runs. Could be a terrible idea. Could be onto something. Either way, it was a fun rabbit hole.
Contributors welcome if this seems interesting to you - early stage, lots to figure out: https://github.com/Nerd-Lang/nerd-lang-core
Happy to chat about design decisions or argue about whether this makes any sense at all.
What about something like clojure? It’s already pretty succinct and Claude knows it quite well.
Plus there are heavily documented libraries that it knows how to use and are in its training data.
Your big idea seems to be changing the tech so that developers have an excuse to be even less responsible than they already are.
Considering their experience, this saves them time to think beyond coding. :)
One thing in particular that I've noticed is that many of language features that enable concise code - such as e.g. type inference - are counter-productive for LLMs because they are essentially implicit context, and LLMs much prefer such things to be explicit. I suspect that e.g. forcing the model to spell out the type of every non-trivial expression in full would have an effect similar to explicit chain-of-thought.
Similarly I think that the ability to write deeply recursive expressions is not necessarily a good thing, and an LLM-centric language should deliberately limit that and require explicit variables to bind intermediate results to.
The single biggest factor though seems to be the ability to ground the model through tooling. Static typing helps a lot there, as do explicit purity annotations for code, and so does automated testing, but one area that I would particularly like to explore for LLM use is design-by-contract.
For a start, now have llms.txt to aid models while developing nerd programs.
https://www.nerd-lang.org/llms.txt
Eg:
Write a function that adds two numbers and returns the result Use https://nerd-lang.org/llms.txt for syntax.
On New Year's Eve I announced NERD - a language built for LLMs, not for human authorship. The response was unexpectedly overwhelming. Questions, excitement, discussions, roasting - all of it.
But one question struck me: "What use case is this language built for?"
Fair. Instead of a general-purpose language covering all features - some of which may not even be relevant because we're not building apps the old way anymore - I picked one: agent-first.
What this means - you can now run an agent in NERD with one line of code:
-- Nerd code llm claude "What is Cloudflare Workers?"
No imports. No boilerplate. No framework.
The insight from working with agents and MCP: tools are absorbing integration complexity. Auth, retries, rate limiting - all moving into tool providers. What's left for agents? Orchestration.
And orchestration doesn't need much: → LLM calls → Tool calls → Control flow → That's it.
Every language today - Python, TypeScript, Java - was built for something else, then repurposed for agents. NERD starts from agents.
Fully story here: https://www.nerd-lang.org/agent-first
in that sense I don't see how this is more succinct than phyton
it is more than typescript and c#, of course, but we need to compete with the laconic languages
in that sense you will end up with Cisc vs Risc dilemma from the cpu wars. you will find the ability to compress even more is adding new tokens to compress repetitive tasks like sha256 being a single token. I feel that's a way to compress even more
I've spent a good bit of time exploring this space in the context of web frameworks and templating languages. One technique that's been highly effective is starting with a _very_ minimal language with only the most basic concepts. Describe that to the LLM, ask it to solve a small scale problem (which the language is likely not yet capable of doing), and see what kinds of APIs or syntax it hallucinates. Then add that to your language, and repeat. Obviously there's room for adjustment along the way, but we've found this process is able to cut many many lines from the system prompts that are otherwise needed to explain new syntax styles to the LLM.
In the fullness of time, you end up having to. Or at least I have. Which is why I always dislike additional layers and transforms at this point.
(eg. when I think about react native on android, I hear "now I'll have to be excellent at react/javascript and android/java/kotlin and C++ to be able to debug the bridge; not that "I can get away with just javascript".)
There’s a chance this is a joke, but even if it is I don’t wanna give the AI tech bros more terrible ideas, they have enough. ;)
I debug at my abstraction layer because I can trust that my compiler actually works, LLMs are fundamentally different and need to produce human readable code.
No LLM has seen enough of this language vs. python and context is now going to be mostly wordy not codey (e.g. docs, specs etc.)
It is so annoying to realise mid read that a piece of text was written by an LLM.
It’s the same feeling as bothering to answer a call to hear a spam recording.
I can't speak for the author, but I do often do this. IMO it's a misleading comparison though, you don't have to debug those things because rarely does the compiler output incorrect code compared to the code you provided, it's not so simple for an LLM.
Imagine saying existing human languages like English are “inefficient” for LLMs so we need to invent a new language. The whole thing LLMs are good at is producing output that resembles their training data, right?
maybe AI should write better readable code than humans. more consistent naming, clearer structure, better comments. precisely because humans only "skim". optimize for skimmability and debuggability, not keystroke efficiency.
> "But I need to debug!"
> Do you debug JVM bytecode? V8's internals? No. You debug at your abstraction layer. If that layer is natural language, debugging becomes: "Hey Claude, the login is failing for users with + in their email."
Folks can get away without reading assembly only when the compiler is reliable. English -> code compilation by llms is not reliable. It will become more reliable, but (a) isn’t now so I guess this is a project to “provoke thought” (b) you’re going to need several nines of reliability, which I would bet against in any sane timeframe (b) English isn’t well specified enough to have “correct” compilation, so unclear if “several nines of reliability” is even theoretically possible.
It seems like a short-sighted solution to a problem that is either transient or negligible in the long run. "Make code nearly unreadable to deal with inefficient tokenization and/or a weird cost model for LLMs."
I strongly question the idea that code can be effectively audited by humans if it can't be read by humans.