Maybe this will be a good way for users to communicate to the LLMs, but I wonder if it would be better for LLMs to generate code in a more disciplined language. Something like Eiffel with pre/post invariants or Lean/Rocq for provable correctness. Then a rigorous compiler can check the LLM emitted what it promised. The verbosity is unpleasant for conventional human programmers, but it's almost a non-issue for the LLM.
LLMs can only predict the next word, I don't know if it's an advantage to use a language with provable correctness or dependent types, especially when training data is scarce.
>“So instead of writing three applications, you write it in a special programming language, which is basically English, which describes how you want to see this application in a very specified way, and then AI agents [...] will generate the code of all of these platforms"
While I think the idea of LLM-based tooling and languages co-evolving is interesting, from this limited description, I think this isn't a helpful direction.
> “So instead of writing three applications, you write it in a special programming language, which is basically English, which describes how you want to see this application in a very specified way, and then AI agents, together with JetBrains tooling, will generate the code of all of these platforms,”
Is the process of generating code for each platform from the high-level specification deterministic, predictable, and obeying some natural invariants? Or is it a stochastic and unpredictable? If Alice publishes her open source project with the specification code, and Bob has access to a slightly different set of models at a later date, will Bob be able to reproduce the same generated artifacts that Alice did?
If you _can_ make everything deterministic and well-behaved, does it need to involve AI agents? Or can this effectively turn into an DSL which happens to be English-like, and a code-generation tool?
Please don’t have it run in a virtual machine. Or at least the JVM. All of Jetbrains products would be 10x better if not written in Java. Native is best.
About 80% of the code in our repos is language or framework baggage, delivers fuck all ROI and the LLM leverage is making about 25% of what is left go away, badly and without any determinism.
Whether or not this is the solution, I don't know, but it feels like the right direction.
I wish they would focus on providing a better IDE experience and fixing existing bugs (and preventing releasing bugs) and keeping up with supporting their existing tooling.
I have difficultly determining what this company wants to deliver. I know what I actually give them money for.
That is another waterfall fantasy paired with Applescript/UML delusions. Perhaps they are seeking vibe investors or they'll indeed offer a toy IDE for vibe coders alongside with their real product.
"So-called "natural language" is wonderful for the purposes it was created for, such as to be rude in, to tell jokes in, to cheat or to make love in (and Theorists of Literary Criticism can even be content-free in it), but it is hopelessly inadequate when we have to deal unambiguously with situations of great intricacy, situations which unavoidably arise in such activities as legislation, arbitration, mathematics or programming." -Dijkstra
This sounds to be in the same area as their post on the OCaml forum last year https://discuss.ocaml.org/t/a-next-generation-ide-for-ocaml/... , though it seems they are going for a natural language approach instead of something like AST editing (which is what I had in mind when reading their original outreach message).
Work on making Junie a viable competitor to Claude Code instead. While I love its accuracy, its equivalent to CC launching a sub agent per file, takes just as long, and probably burns tokens similarly - except there's no way to disable that approach in Junie.
I'd always assumed that was what MPS was about, but I guess that's about developing more precise DSLs than having one single language to rule them all. But I'm sure that approach will work this time by just throwing AI and gigawatts worth of handwaving at it :-|
> So instead of writing three applications, you write it in a special programming language, which is basically English, which describes how you want to see this application in a very specified way, and then AI agents, together with JetBrains tooling, will generate the code of all of these platforms
i take it to mean no more kotlin multiplatform if ai will just generate platform specific code....?
I admit that I'm kind of intrigued. On the one hand, this is a standard vaporware concept that people have promised time and again almost since the dawn of programming. On the other hand, LLMs that write and maintain code currently have to do it using tools designed for humans, and that's probably leaving some amount of value on the table.
Right now I think I'd bet that whatever this is won't ultimately impress me much, but not at very extreme odds.
31 comments
[ 2.5 ms ] story [ 47.0 ms ] thread> “So instead of writing three applications, you write it in a special programming language, which is basically English, which describes how you want to see this application in a very specified way, and then AI agents, together with JetBrains tooling, will generate the code of all of these platforms,”
Is the process of generating code for each platform from the high-level specification deterministic, predictable, and obeying some natural invariants? Or is it a stochastic and unpredictable? If Alice publishes her open source project with the specification code, and Bob has access to a slightly different set of models at a later date, will Bob be able to reproduce the same generated artifacts that Alice did?
If you _can_ make everything deterministic and well-behaved, does it need to involve AI agents? Or can this effectively turn into an DSL which happens to be English-like, and a code-generation tool?
LLMs are pretty code at compiling clear descriptive or prescriptive instructions in English down to a programming language.
Stopped reading here. Good luck with your shared mutable state! Enjoy!
Are we just talking about prompting with some enforced structure, or is it a programming language?
Whether or not this is the solution, I don't know, but it feels like the right direction.
I have difficultly determining what this company wants to deliver. I know what I actually give them money for.
https://simianwords.bearblog.dev/so-you-want-to-create-a-new...
TL;DR the overhead in learning the new abstraction and dealing with the inevitable edge cases (known or unknown) must be taken into account.
All abstractions sound good until you account for these things.
The new language can work if the edge cases of this language are known and minimal.
COBOL, you're inventing COBOL.
Right now I think I'd bet that whatever this is won't ultimately impress me much, but not at very extreme odds.