I am already using low code tooling with agents for some projects, in iPaaS products.
I have the opposite opinion. As LLM become ubiquitous and code generation becomes cheap, the choice of language becomes more important.
The problem with LLM for me is that it is now possible to write anything using only assembly. While technically possible, who can possibly read and understand the mountain of code that it is going to generate?
I use LLM at work in Python. It can, and will, easily use hacks upon hacks to get around things.
Thus I maintain that as code generation is cheap, it is more important to constraint that code generation.
All of this assume that you care even a tiny bit about what is happening in your code. If you don't, I suppose you can keep banging the LLM to fix that binary blob for you.
As a very practical problem the assembly would consume the context window like no other. And another is having some static guardrails; sometimes LLMs make mistakes, and without guard rails it debugging some of them becomes quite a big workload.
So to keep things efficient, an LLM would first need to create its own programming language. I think we'll actually see some proposals for a token-effective language that has good abstraction abilities for this exact use.
I think, changes to languages/tooling to accomodate Agentic loops will become important.
> All of this assume that you care even a tiny bit about what is happening in your code. If you don't...
I mean, as software engineers, we most certainly do. I suspect there'll be a new class of "developers" who will have their own way of making software, dealing with bugs, building debugging tools that suit their SDLC etc. LLMs will be to software development what Relativity was to Astrophysics, imo: A fundamental & permanent shift.
IMO Rust will strike a very strong balance here for LLMs.
Hardly much different than dealing with traditional offshoring projects output.
I don't understand what you mean. Beat any language at what? Correctness? I don't think that's true at all, but I also don't see how that's relevant, it definitely doesn't address the fact that Rust will virtually always produce faster code than the majority of other languages.
> Hardly much different than dealing with traditional offshoring projects output.
I don't know what you mean here either.
But testing in Python is so easy to abuse as LLM. It will create mocks upon mocks of classes and dynamically patch functions to get things going. Its hell to review.
I've been doing a few projects that are definitely outside my comfort zone with LLMs and its fine. I can read the code but I just don't have the muscle memory to produce it.
I see the opposite. New languages have more difficulty breaking into popularity due to lack of enough existing codename and ecosystems.
