This creates an interesting tension. Coding agents could dramatically reduce the cost of building an ecosystem while simultaneously weakening one of the forces that causes ecosystems to form in the first place.
This is deeply unintuitive but AI negates language specific ecosystems, while strengthening language agnostic ecosystems.
Pick whatever your favourite programming language is and its ecosystem. With AI someone can take your ecosystem and just port it to their language.
This means the only way you can protect your ecosystem is to play on all language fronts at the same time so porting the software to another language becomes a meaningless exercise.
I’m not sure. my read of this was that AI weakens human ecosystems in general because we don’t need to work together as much when we are all just working with AI separately, but maybe you have specific examples of language agnostic ecosystems in mind? I’m struggling to imagine what that would look like
With AI someone can take your ecosystem and just port it to their language.
I don't think its that "just". Examples of porting we seen had some prerequisites: being self contained with very strong tests coverage, so AI could iterate N millions times and fix bugs in new implementation. Otherwise such porting could be very buggy and unmaintainable.
Don't all of "serious" programming languages meet that bar? Java, C#, Go, Python, etc all have enormous test suites. Once you get into the third party, things become much more uneven, but if you can restrict yourself to say the top N packages in a language, those are going to have better than average development practices which makes that plausible.
Why even assume that the most optimal programming languages for agentic coding are the ones that humans use? Maybe operate on ASTs directly? Some other form of programming that humans would find hard but that is a good fit for LLMs?
Yes, because that code was never written to be understood by machines, merely to be mechanically translated. Software is a very messy set of layers of leaky abstractions trying to express reasonably well defined ideas. Humans can't write code without mistakes, in spite of all the examples out there. If they could compilers wouldn't have to emit error messages.
LLM's are trained on human code though. Converting the code to its ast tree and training ai on that would be trivial of course, but I imagine there would be information that explains why something exists that would be missed.
I don't care if it's optimal for them. It's clearly good enough. We have, in hand, the ultimate in auditable AI output. We may not be able to audit how it got to the code it delivered, but it is really quite good at delivering code we can read. It would be very silly for us to give it up so that they can be somewhat more efficient or something, if they even would necessarily be that much more efficient.
To the point that I would support banning the creation of an AI-only language that can't be read by humans. Huge, huge, huge step in the wrong direction.
AI negates language specific ecosystems ... Pick whatever your favourite programming language is and its ecosystem
I think this is only true when it comes to LLM raw output. There's also the concern of checking its work. A compiler that can check many aspects of correctness (static types, null) is a huge boost to AI. It can use the compiler directly to check its own work.
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.
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.
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.
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.
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?
Even when no(human)body is reading the code, AI is still reading the code in order to "understand" it. Languages that can express high level concepts, use structured programming for recognizable control flow patterns instead of inscrutable jumps, and assign names to things have the same benefits for the AI-coders and AI-reviewers that they always have for humans.
Personal responsibility will always exist at the touchpoints of software and human activity. Concentration and scope of responsibility may vary, and the degree to which that person needs to understand the code will vary as a result, but the need for a human to be able to read and understand code is going to be around for a very long while still.
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.
This is deeply unintuitive but AI negates language specific ecosystems, while strengthening language agnostic ecosystems.
Pick whatever your favourite programming language is and its ecosystem. With AI someone can take your ecosystem and just port it to their language.
This means the only way you can protect your ecosystem is to play on all language fronts at the same time so porting the software to another language becomes a meaningless exercise.
I’m not sure. my read of this was that AI weakens human ecosystems in general because we don’t need to work together as much when we are all just working with AI separately, but maybe you have specific examples of language agnostic ecosystems in mind? I’m struggling to imagine what that would look like
maybe more like an ecosystem around a framework implemented in multiple language SDKs, here are two I use
https://adk.dev/
https://docs.dagger.io/reference/sdks
both can invoke modules written in other languages from your language of choice
Kubernetes is likely an interesting ecosystem to consider under this lens too
I don't think its that "just". Examples of porting we seen had some prerequisites: being self contained with very strong tests coverage, so AI could iterate N millions times and fix bugs in new implementation. Otherwise such porting could be very buggy and unmaintainable.
Don't all of "serious" programming languages meet that bar? Java, C#, Go, Python, etc all have enormous test suites. Once you get into the third party, things become much more uneven, but if you can restrict yourself to say the top N packages in a language, those are going to have better than average development practices which makes that plausible.
year, that's usually what is referred as ecosystem.
Why even assume that the most optimal programming languages for agentic coding are the ones that humans use? Maybe operate on ASTs directly? Some other form of programming that humans would find hard but that is a good fit for LLMs?
Because human review is a serious bottleneck and optimizing something that isn't the bottleneck isn't helpful
AI still makes mistakes on code with a trillion billion examples, but let’s invent a DSL that only AI can read and hope for the best?
Yes, because that code was never written to be understood by machines, merely to be mechanically translated. Software is a very messy set of layers of leaky abstractions trying to express reasonably well defined ideas. Humans can't write code without mistakes, in spite of all the examples out there. If they could compilers wouldn't have to emit error messages.
Right on every count except that it needs to be bad for people
LLM's are trained on human code though. Converting the code to its ast tree and training ai on that would be trivial of course, but I imagine there would be information that explains why something exists that would be missed.
I don't care if it's optimal for them. It's clearly good enough. We have, in hand, the ultimate in auditable AI output. We may not be able to audit how it got to the code it delivered, but it is really quite good at delivering code we can read. It would be very silly for us to give it up so that they can be somewhat more efficient or something, if they even would necessarily be that much more efficient.
To the point that I would support banning the creation of an AI-only language that can't be read by humans. Huge, huge, huge step in the wrong direction.
...
Naturally, it is probably inevitable.
But it's still a terrible idea.
I think this is only true when it comes to LLM raw output. There's also the concern of checking its work. A compiler that can check many aspects of correctness (static types, null) is a huge boost to AI. It can use the compiler directly to check its own work.
This part:
---
- 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.
A programming language for agents seems ill-conceived in my opinion.
Agents will naturally be bad at it due to a lack of examples.
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.
Explaining the additional features as bits of other languages is exactly what helps LLMs:
"Dart-style constructors, Swift-style pattern matching and Strings, Trio-style async cancellation, Scala-style sealed classes"
This keep getting repeated. So were just stuck with whatever we have at the point of training the magic plagiarism machine?
The future is cooked
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.
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.
It seems plainly obvious to me that an agent trained on zillions of TypeScript examples is going to be better at TypeScript compared to novel langs.
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.
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.
Native compilation should be doable already with a Wasm compiler like Wastrel.
One reason I haven't explored that is that I want to tailor the language for the more constrained environment of Wasm GC first.
Languages for AI era should be more explicit so reviewers can read it faster.
There's no point to try to adapt our languages to the strengths of LLMs when the strength of LLMs is working in terms of our languages.
Implement whatever abstractions you think LLMs should work in terms of in whatever language is handy, and have your LLM use those abstractions.
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?
Even when no(human)body is reading the code, AI is still reading the code in order to "understand" it. Languages that can express high level concepts, use structured programming for recognizable control flow patterns instead of inscrutable jumps, and assign names to things have the same benefits for the AI-coders and AI-reviewers that they always have for humans.
I think that just like humans, AI will make logical mistakes at some rate linked to lines of code.
Like I remember reading human studies that people make 1.5 - 5 errors per 100 loc.
If AI works in a similar way then we should stick to higher level languages that minimize loc
Personal responsibility will always exist at the touchpoints of software and human activity. Concentration and scope of responsibility may vary, and the degree to which that person needs to understand the code will vary as a result, but the need for a human to be able to read and understand code is going to be around for a very long while still.
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.