[jerf]

I think there's a core of a good idea here, but as others have pointed out, letting the LLM be your "weaver" is going to be very tricky.

It's possible that what you have here is an idea for what I consider to be eventually very likely, which is a computer languages still built for humans to be able to understand and debug it, but more primarily for LLMs to write it. Write a language designed to be an aspect-oriented language from the beginning. Equip it with the ability to run something like a language server and point it at a system and get all the "aspects" running and you might have something.

But I'm skeptical of bodging this on to an existing language.

One of the reasons I suggest making it a new language is that AOP was hampered by being able to use only what languages already supported. The need for a "weaver" is a smell anyhow. Something where the aspect code is the native representation and the "weaving" simply dissolves into the compilation process would not only make the whole thing more appealing in general, I think it would also allow for some things that even code generation might have found a challenge, like aspects that can maintain guarantees because the whole process is more aspect-aware and not broken by the embedded "payload" code written by a human.

[w10-1]

re: dissolving into compilation, I think the machine/human separation has been at work for some time. Modern languages (e.g., rust, swift) are already pioneering tracking aspects like effects, lifetimes, regions, etc. and then using whole-program optimization at compile- and link-time, largely based on intermediate languages like LLM IR/SIL, which are surfaced as user-visible features when they compose well with other user-visible language features. LLM training on these languages makes them suitable for generative AI; I doubt LLM's could pick up some new language, particularly if it weren't analogous to existing ones.

[jerf]

For what it's worth, the last time a language exploded on to the scene so quickly that people were picking it up commercially at a large scale before there was any sort of code base that LLMs could train on was Java. (Yes, there were no LLMs at the time, but I can back-project that as a measure OK.) And that was a money-infused attempt by Sun to buy their way into dominance on the Internet. It ultimately worked for Java, but not so much for Sun.

Any new language, of any kind, optimized for LLMs or not, is going to intrinsically take multiple LLM training cycles to grow anyhow. Net-net I would still expect AI adoption to accelerate those things and at least make it easier for hobbyiests to play with at some useful scale and get more feedback faster. Of course they'll also face increased competition from the other languages riding the same waves, which is possibly the bigger problem for anyone thinking of doing this.

[TuringTest]

I believe the sweet spot that makes it practical and reliable will be combining LLMs with formal verification, although I doubt current hardware is up to the task (yet).

LLMs basically solve the classic Frame problem that prevented general problem solvers to be able to reason logically about the real world; however on their own they are utterly unpredictable and unreliable.

However if the database of weights is merely used as a heuristic to guide the logical reasoning engine to promising regions of the problem space, and the program itself is written to specification directly by an inference engine, the result would be classic software not affected by hallucinations.

The LLM could even help debugging the specifications by pointing out unclear or contradicting requirements, improving the process without compromising the integrity of the result.