I'm using AssemblyScript inside a Rust host for most things (game prototypes). I never would have made this choice if coding by hand. I am not interested in anything without static types, and I want something to perform great both natively and in the browser, and further I want the compiler to work great in the browser as well and to be built into the products with no external dependencies. As a stretch goal I hope for my applications to be easily modified by the user in realtime, from an agentic harness built in.
Anyway. I have been surprised at how good the LLMs are at AssemblyScript, I'm barely aware of the memory model. It just hasn't caused problems.
I also build everything as client/server with a library for managing state that makes it so it's basically impossible for the LLM to make a mess in certain ways (making a spaghetti meal out of
the UI and state), and also makes it very easy for the LLM to write tests and to operate and inspect the program state and to replay sessions. I think there might be something to this sort of regime.
In short, the more deterministic, automated, checks the better. AI can deal with a pedantic language. I intend to add statically verified structured concurrency, units of measure, contracts, and eventually more and more formal methods into the language so it can be a familiar TYpeScript-like base with as many static guarantees as we can fit in.
I also think that fine-grained isolation, which Zena gets via Web Assembly, is critical for limiting the capabilities of generated code and the blast radius of bugs, vulnerabilities, and non-aligned behavior.
I do have an optimistic hope that a language also optimized for humans, readability and simple semantics especially, has value in the future, even when most code is generated. We'll see about that.
I think starting with a familar typescript-like base language is a good approach to this. This should be familiar enough for LLMs for the most part as long as additional features can be explained in a succinct system promopt/skill.
From experience with Zena, this is not true at all. Opus, Fable, Gemini Flash and Pro all barely make any syntax mistakes after a little is in context, and those are caught extremely early.
The one thing I do see sometimes is that agents sometimes don't take advantage of added features, but that's partially because the Zena code base doesn't use them as much yet. I'm working on skills and linter-based suggestions to use better patterns.
You should have working programs that demonstrate the features you want them to use, and then the skills. Working programs they can mutate in an RL gym.
You are essentially training your agent to learn Zena, it probably even helped you create Zena, anyone can do this, invent their own language with their agent. That language will not be battle tested and other peoples agents will have to be individually trained/taught about Zena. Unless you have codebases with significant amount of lines of code, blogs, books, videos, subreddits, stack-overflow answers etc somewhere on the net for LLMs to scrape and learn Zena, people will have to individually teach it their agents, which IMO is why I see programming languages designed for agents are trying to boil the ocean.
> bc agents will naturally be bad at it due to a lack of examples.
Can we please as a community stop parroting these false premises as a basis of every argument against doing anything new? It's plainly obvious to anybody that uses LLMs on a regular basis that it's not true.
Agree, new language will not suitable for LLM because there is not enough documents about it on the internet. LLM should learn the usage of the langauge from documents. Yes, it can use new language but it's not natural as existing(which have a lot of documents) languages.
So my opinion is language is no matter anymore. Just prompting(describe the spec) matters. And there is babo language for this.
https://github.com/armbox/babo
They should find the limitation of the natural language somehow, and use and distribute babo language will help find how it will works(or not). LLM model eveolves yet, so there is no such a approach, but the speed of evolution is decreased lately. So now is good time to dig into identify the limitation and boundary of the LLM.
This is easy to find out, name any new JavaScript framework that got pupular since the advent of vybe coding. We used to have new js libraries every week (anyone still remembers substack the nodejs hacker good old times)
This is absolutely not the case in my experience. I am building a very large embedded domain specific language for describing distributed systems. It looks like a small subset of Elixir, but with object-oriented syntax in a lot of places. (It’s called a choreography; there exist many other choreographic programming languages.)
Even though this programming language is absolutely nowhere in any large language model’s training set, they have so far done extremely well at extrapolating from the small set of examples I’ve given it when I need an agent to generate some tests or whatever for me.
Agents are fairly good even at languages designed to trick them. I built one[1] and it does make for a good benchmark[2] to see which LLMs are actually good. I think that a language which is largely similar to others will be a piece of cake for most and any advantage that an existing language will have will be minor enough to not matter.
Btw if folks have ideas of how to make Killswitch even harder for LLMs I’d appreciate them.
I love this. I was thinking about a "cleaned up" typescript for a while now, and this seems to be it. I believe this can work better as an "ai-first" language than some other attempts I've seen that try to reinvent the language from scratch.
One thing I would love to have as a feature is native compilation.
Why not languages that are designed in that way, like Ada. Or if one wants less of rigidness then a static typed language that makes it hard to shoot in your foot like Rust,Java, C#?
JS derivatives are that, a derivative to a scripting language.
Ironically, since AI can build an STL and tooling (up to a full OS!), I think now presents an opportunity for a language that does start from scratch, at least targeting hobbyists (besides those specifically looking for novel languages).
I think I get your point but I think it's reductionist to the point of being incorrect. Of course LLMs are better at some semantics than others. Programming languages don't have random semantics, they have what matches the world and what matches our languages and so on. And the current frontier LLMs aren't so generic that they can construct (predict) any phrase no matter the content and grammar reflected in the phrase -- concretely I mean some languages are harder to reason about (predict) than others.
The strenghts and weaknesses of LLMs are changing, so starting a long-term project like a PL with them in mind sounds like a good way to end up with something obsolete before it is even usable.
I don’t know how stupid of a suggestion this is, but if no one is reading the code anymore (I do, but I hear many in much more elite shops than mine do not), then should we not just be using AI to write binary or machine code?
Machine code isn't especially expressive per line or unit of code. Lower level languages takes up more of an LLM's context than higher level ones.
To be effective in using low level languages, LLMs would have to build higher level constructs like subroutines from scratch every program.
It's not that different from why we almost never use assembler for anything more than code islands: even a modest subroutine can overwhelm our own mental context window.
LLMs are good at optimizing towards local goals. Getting types right at compile time is a local goal. Entry and exit assertions are local goals. Unit tests are local goals. So those constructs all help AI-generated code.
Matching a desired output is a global goal, but even that sometimes works now.
Someone sent me a LLM-generated JPEG 2000 decoder. They got Fable to generate a decoder that uses a GPU to get the same answer as the reference implementation gets on the GPU.
LLMs are generally more tolerant of tedium than humans, but they make mistakes more often on repetitive mechanical tasks. I've had Claude write PTX directly once, and Claude just wrote majority of it and commented something along the line of "repeat this block 7 more time with these minor changes" instead of writing them out, so the code didn't work.
So, no, replacing compilers with LLMs is probably a worse option than having them code a compiler/programming language.
Oct is the first programming language that I made with Codex. It started out as "Octave Modern" and was never intended to be a language for LLMs in the first place, but rather a teaching language that I've been thinking about for a decade because of my frustration with academic code and specifically reproducibility, with Python and Matlab in particular.
But it turns out the same design choices that was made to prevent bad patterns from academic code also made it pretty good for LLM coding: statically typed, immutable by default, GC'd with fast compile and runtime because it compiles to Go, along with features designed for scientific compute like SI units and builtin graphing etc.
But now it just took a life of its own, so it has extra features like templates/concepts, iterators, async/await, database query, build system for C/C++, SystemVerilog/WASM(WIP) codegen, LaTeX/pdf generation etc. None of them were features that were developed in isolation of "what an LLM agent might want to write" but to address a specific problem that I had encountered or to address specific failure modes that Codex/Claude actually had.
That's why I think Oct is probably one of the better languages for AI to write/generate, not because it was designed to be AI friendly in abstract, but that it's developed against how AI actually writes code, even though again, it is still very much a work in progress.
Thanks. The fun thing about the name "Oct" is how many dumb puns I can make with it. For example, the LaTeX/PDF generation functionality is called Oct-cument.
> I've been thinking about for a decade because of my frustration with academic code and specifically reproducibility, with Python and Matlab in particular.
I'm with you there, I think I starred Oct when I came across it. I've been on that quest since 2014, we should collaborate! I'll be presenting this work at IROS tomorrow, I'd love to hear what you think: https://mech-lang.org/iros-r4r-2026/index.html
Yeah, we definitely should collaborate on something, since I think we both came to the same conclusion that explicit state machines should be the primitives of a programming language.
So here is my experiment with Kalman filters here.
It's been a while, but I think the findings there are mostly that Kalman filters are relatively heavy and fairly narrow in application in that it's good at filter Gaussian noise out but not much else, and it's kind of branchy so it doesn't run on the GPU very well, you can try to see if a simpler feedforward like Smith predictor can work as well.
Also, something to try out: the explicit state machine stacks/pushdown automata are only half of the equation, the other （and imo more important） half is argmax/utility AI based transition instead of traditional state machine graph.
But yeah, if your target is embedded/bare-metal application for robotics, since Oct really isn't designed for it, maybe you would like to check out what I'm currently working on, the Concept programming language?
I'm also making a language. Of course, it's a project no one will use, and I'm building it with AI, but I enjoy translating my thoughts into it.[1]
Personally, I think new languages will end up taking a form similar to the grammar of existing languages, but with different semantics. That's because when I tried a completely new grammar, the AI couldn't generate code well, so I ended up spending time bringing in TypeScript's grammar and converting it into my language's mental model.
My language isn't anywhere near as sophisticated as the languages the developers here boast about creating (it's actually lower), but these days it at least runs, even if it's full of bugs. So sometimes I think that many people like me will develop languages, and that programming might end up becoming fragmented.
I’d love for language environments to support encouraging LLMs to specify more when they write code. Why should they first write a complex function or a class and later bolt on a test?
I’d love for a class in this future language to come packaged with tests, invariants, fuzzer parameters, profile targets / performance budgets with realistic inputs (on this 100 element array this should take no more than X clock cycles), race condition stress tests etc.
The compiler (or even linter) should optionally run some / all of these checks and succinctly report back (with knobs so the LLM can manage wall clock time).
Adding each of these should not be follow on steps.
Beyond this, debug hooks should be trivial to set (in code itself), so the LLM can trivially say show me the stack after the 9th time this function is called on this input to the program.
41 comments
[ 2.1 ms ] story [ 29.5 ms ] threadAnyway. I have been surprised at how good the LLMs are at AssemblyScript, I'm barely aware of the memory model. It just hasn't caused problems.
I also build everything as client/server with a library for managing state that makes it so it's basically impossible for the LLM to make a mess in certain ways (making a spaghetti meal out of the UI and state), and also makes it very easy for the LLM to write tests and to operate and inspect the program state and to replay sessions. I think there might be something to this sort of regime.
---
- Correct by construction: the language makes invalid states or programs hard or impossible to express.
- Statically established: types, proofs, and static analysis establish properties before execution.
- Runtime-enforced: memory management, isolation, capability boundaries, and other runtime enforced properties.
- Empirically validated: program validation through tests, property-based testing, and fuzzing.
---
Along with being familiar, so it's easy to generate, is a huge part of why I'm building Zena: https://zena-lang.dev/
I don't have the AI-first rationale put into the public docs well just yet, but I mention some of it here: https://zena-lang.dev/guide/why-zena/#familiar-to-humans-and...
along with a doc in the repo on this topic: https://github.com/elematic/zena/blob/main/docs/design/ai-fi...
In short, the more deterministic, automated, checks the better. AI can deal with a pedantic language. I intend to add statically verified structured concurrency, units of measure, contracts, and eventually more and more formal methods into the language so it can be a familiar TYpeScript-like base with as many static guarantees as we can fit in.
I also think that fine-grained isolation, which Zena gets via Web Assembly, is critical for limiting the capabilities of generated code and the blast radius of bugs, vulnerabilities, and non-aligned behavior.
I do have an optimistic hope that a language also optimized for humans, readability and simple semantics especially, has value in the future, even when most code is generated. We'll see about that.
"Dart-style constructors, Swift-style pattern matching and Strings, Trio-style async cancellation, Scala-style sealed classes"
The future is cooked
The one thing I do see sometimes is that agents sometimes don't take advantage of added features, but that's partially because the Zena code base doesn't use them as much yet. I'm working on skills and linter-based suggestions to use better patterns.
Can we please as a community stop parroting these false premises as a basis of every argument against doing anything new? It's plainly obvious to anybody that uses LLMs on a regular basis that it's not true.
They should find the limitation of the natural language somehow, and use and distribute babo language will help find how it will works(or not). LLM model eveolves yet, so there is no such a approach, but the speed of evolution is decreased lately. So now is good time to dig into identify the limitation and boundary of the LLM.
Even though this programming language is absolutely nowhere in any large language model’s training set, they have so far done extremely well at extrapolating from the small set of examples I’ve given it when I need an agent to generate some tests or whatever for me.
Btw if folks have ideas of how to make Killswitch even harder for LLMs I’d appreciate them.
1 - https://killswitch-lang.org
2 - https://bench.killswitch-lang.org
Haha
One thing I would love to have as a feature is native compilation.
One reason I haven't explored that is that I want to tailor the language for the more constrained environment of Wasm GC first.
JS derivatives are that, a derivative to a scripting language.
Implement whatever abstractions you think LLMs should work in terms of in whatever language is handy, and have your LLM use those abstractions.
To be effective in using low level languages, LLMs would have to build higher level constructs like subroutines from scratch every program.
It's not that different from why we almost never use assembler for anything more than code islands: even a modest subroutine can overwhelm our own mental context window.
Matching a desired output is a global goal, but even that sometimes works now. Someone sent me a LLM-generated JPEG 2000 decoder. They got Fable to generate a decoder that uses a GPU to get the same answer as the reference implementation gets on the GPU.
I'm keen to run it.
LLMs are generally more tolerant of tedium than humans, but they make mistakes more often on repetitive mechanical tasks. I've had Claude write PTX directly once, and Claude just wrote majority of it and commented something along the line of "repeat this block 7 more time with these minor changes" instead of writing them out, so the code didn't work.
So, no, replacing compilers with LLMs is probably a worse option than having them code a compiler/programming language.
Plugging my own thing to use as example:
https://github.com/yuechen-li-dev/oct
Oct is the first programming language that I made with Codex. It started out as "Octave Modern" and was never intended to be a language for LLMs in the first place, but rather a teaching language that I've been thinking about for a decade because of my frustration with academic code and specifically reproducibility, with Python and Matlab in particular.
But it turns out the same design choices that was made to prevent bad patterns from academic code also made it pretty good for LLM coding: statically typed, immutable by default, GC'd with fast compile and runtime because it compiles to Go, along with features designed for scientific compute like SI units and builtin graphing etc.
But now it just took a life of its own, so it has extra features like templates/concepts, iterators, async/await, database query, build system for C/C++, SystemVerilog/WASM(WIP) codegen, LaTeX/pdf generation etc. None of them were features that were developed in isolation of "what an LLM agent might want to write" but to address a specific problem that I had encountered or to address specific failure modes that Codex/Claude actually had.
That's why I think Oct is probably one of the better languages for AI to write/generate, not because it was designed to be AI friendly in abstract, but that it's developed against how AI actually writes code, even though again, it is still very much a work in progress.
I'm not proud of that pun.
I'm with you there, I think I starred Oct when I came across it. I've been on that quest since 2014, we should collaborate! I'll be presenting this work at IROS tomorrow, I'd love to hear what you think: https://mech-lang.org/iros-r4r-2026/index.html
So here is my experiment with Kalman filters here.
https://github.com/yuechen-li-dev/oct/tree/main/Experiments/...
It's been a while, but I think the findings there are mostly that Kalman filters are relatively heavy and fairly narrow in application in that it's good at filter Gaussian noise out but not much else, and it's kind of branchy so it doesn't run on the GPU very well, you can try to see if a simpler feedforward like Smith predictor can work as well.
Also, something to try out: the explicit state machine stacks/pushdown automata are only half of the equation, the other （and imo more important） half is argmax/utility AI based transition instead of traditional state machine graph.
But yeah, if your target is embedded/bare-metal application for robotics, since Oct really isn't designed for it, maybe you would like to check out what I'm currently working on, the Concept programming language?
https://github.com/yuechen-li-dev/Concept/
Personally, I think new languages will end up taking a form similar to the grammar of existing languages, but with different semantics. That's because when I tried a completely new grammar, the AI couldn't generate code well, so I ended up spending time bringing in TypeScript's grammar and converting it into my language's mental model.
My language isn't anywhere near as sophisticated as the languages the developers here boast about creating (it's actually lower), but these days it at least runs, even if it's full of bugs. So sometimes I think that many people like me will develop languages, and that programming might end up becoming fragmented.
[1]https://github.com/srtdog64/PergyraLang
Some of us now have to deal with tools like Boomi, Workato, Opal, Sitecore AI, Power Platform,....
Eventually some microservices might be written in "legacy" languages for MCP tools.
This is how "programming languages" look like in 2026 for internal corporate development.
I’d love for a class in this future language to come packaged with tests, invariants, fuzzer parameters, profile targets / performance budgets with realistic inputs (on this 100 element array this should take no more than X clock cycles), race condition stress tests etc.
The compiler (or even linter) should optionally run some / all of these checks and succinctly report back (with knobs so the LLM can manage wall clock time).
Adding each of these should not be follow on steps.
Beyond this, debug hooks should be trivial to set (in code itself), so the LLM can trivially say show me the stack after the 9th time this function is called on this input to the program.