It might be the opposite. Python apps still get written despite the performance hit, because understandability matters more than raw performance in many cases. Now that we’re all code reviewers, that quality should matter more, not less. Programmer time is still more expensive than machine time in many cases.
I kinda like viewing this as similar to coordinate-invariance in physics / geometry. A programming language is effectively a function from textual programs to behaviors; this serves the same role as a coordinate system on a space, which is a function from coordinates to points. Naturally many different programs and programming languages can describe the same behavior, especially if you forget about implementation-specific details like memory layout or class structures. LLM code generation is just another piece of the same model: turns out that to some degree you can use English+LLMs as coordinate systems for the textual programs.
I expect that over time we will adopt a perspective on programming that the code doesn't matter at all; each engineer can bring whatever syntax or language they prefer, and it will be freely translated into isomorphic code in other languages as necessary to run in whatever setting necessary. Probably we will settle on an interchange format which is somehow as close as possible to the "intent" of the code, with all of the language-specific concepts stripped away, and then all a language will be is a toolbox that engineer carries with them of their favorite ways to express concepts.
but the interesting thing about coordinate systems is that they do matter, a lot! many problems are much much easier to solve in one coordinate system than another.
This is my second attempt learning Rust and I have found that LLMs are a game-changer. They are really good at proposing ways to deal with borrow-checker problems that are very difficult to diagnose as a Rust beginner.
In particular, an error on one line may force you to change a large part of your code. As a beginner this can be intimidating ("do I really need to change everything that uses this struct to use a borrow instead of ownership? will that cause errors elsewhere?") and I found that induced analysis paralysis in me. Talking to an LLM about my options gave me the confidence to do a big change.
n_u's point about LLMs as mentors for Rust's borrow checker matches my experience. The error messages are famously helpful, but sometimes you need someone to explain the why.
I've noticed the same pattern learning other things. Having an on-demand tutor that can see your exact code changes the learning curve. You still have to do the work, but you get unstuck faster.
I don't see why it shouldn't be even more automated than that, with LLM ideas tested automatically by differential testing of components against the previous implementation.
Defining tests that test for the right things requires an understanding of the problem space, just as writing the code yourself in the first place does. It's a catch-22. Using LLMs in that context would be pointless (unless you're writing short-lived one-off garbage on purpose).
I.e. the parent is speaking in the context of learning, not in the context of producing something that appears to work.
I'm not sure that's true. Bombarding code with huge numbers of randomly generated tests can be highly effective, especially if the tests are curated by examining coverage (and perhaps mutation kills) in the original code.
> I don't see why it *shouldn't be even more automated
In my particular case, I'm learning so having an LLM write the whole thing for me defeats the point. The LLM is a very patient (and sometimes unreliable) mentor.
I am old but C is similarly improved by LLM. Build system, boilerplate, syscalls, potential memory leaks. It will be OK when the Linux graybeards die because new people can come up to speed much more quickly
The thing is LLM-assisted C is still memory unsafe and almost certainly has undefined behaviour; the LLM might catch some low hanging fruit memory problems but you can never be confident that it's caught them all. So it doesn't really leave you any better off in the ways that matter.
While I still struggle to think in Rust after years of thinking in C, it is NEVER the borrow checker or lifetimes that trip me, it's the level of abstraction, in that C forced me low level, building my own abstractions, while Rust allows me to think in abstractions first and muse over how to implement those idiomatically.
What did it for me was thinking through how mutable==exclusive, non-mutable==shared, and getting my head around Send and Sync (not quite there yet).
AI helps me with boiler plate, but not with understanding, and if I don't understand I cannot validate what AI produces.
I'm starting my rusty journey and I'm only a few months in. With the rise of autogenerated code, it's paradoxically much harder to go slow and understand the fundamentals.
Just wanted to add another bit of reassurance. At some point during my career people started "stack overflow coding". But ultimately someone has to fix the difficult issues and when you have the skills, you are coming out on top where others can just shrug and say "well there's no solution on stack overflow".
If there's a human in then loop, actually reading the plans and generated code, then it's possible to have 90% of me code generated by an LLM and maintain reasonable quality.
That depends on how you define "doomed". Most screwed up companies don't go belly up overnight. They get sold as fixer-uppers and passed between bigger firms and given different names until, finally, it is sold for parts. The way this works is that all parties behave as if the company is the opposite of doomed. It's in a sense correct. The situation hardly seems doomed if everyone has enough time to make their money and split before the company's final death twitches cannot be denied, in which case the company accomplished its mission. That of course doesn't mean everything from its codebase to its leadership didn't lack excellence the whole time.
Its insane to me seeing this kind of thing. I write 100% of my code by hand. Of developers I know, they write >95% of code by hand
>We are entering an era where the Brain of the application (the orchestration of models, the decision-making) might remain in Python due to its rich AI ecosystem, but the Muscle, the API servers, the data ingestion pipelines, the sidecars, will inevitably move to Go and Rust. The friction of adopting these languages has collapsed, while the cost of not adopting them (in AWS bills and carbon footprint) is rising.
This is the most silicon valley brain thing I've seen for a while
We're entering an era where I continue to write applications in C++ like I've always done because its the right choice for the job, except I might evaluate AI as an autocomplete assistant at some point. Code quality and my understanding of that code remains high, which lets me deliver at a much faster pace than someone spamming llm agent orchestration, and debuggability remains excellent
90% of code written by devs is not written by AI. If this is true for you, try a job where you produce something of value instead of some random silicon valley startup
In my experience, most of the NodeJS shops do this. Because, LLMs on the surface seemingly are good at giving you a quick solution for JS code. Whether it's a real solution or patchwork is up for debate, but, for most mid-level to junior devs, it's good enough to get the job done. Now, multiply this workflow 10x for 10 employees. That's how you end up with a complete rewrite and hiring a senior consultant.
Yeah, I would say it's pretty variable, and it depends on what you mean by the word write.
I've recently joined a startup whose stack is Ruby on Rails + PostgreSQL. Whilst I've used PostgreSQL, and am extremely familiar with relational databases (especially SQL Server), I've never been a Rubyist - never written a line of Ruby until very recently in fact - and certainly don't know Rails, although the MVC architecture and the way projects are structured feels very comfortable.
We have what I'll describe as a prototype that I am in the process of reworking into a production app by fixing bugs, and making some pretty substantial functional improvements.
I would say, out of the gate, 90%+ of the code I'm merging is initially written by an LLM for which I'm writing prompts... because I don't know Ruby or Rails (although I'm picking them up fast), and rather than scratch my head and spend a lot of time going down a Google and Stackoverflow black hole, it's just easier to tell the LLM what I want. But, of course, I tell it what I want like the software engineer I am, so I keep it on a short leash where everything is quite tightly specified, including what I'm looking for in terms of structure and architectural concerns.
Then the code is fettled by me to a greater or lesser extent. Then I push and PR, and let Copilot review the code. Any good suggestions it makes I usually allow it to either commit directly or raise a PR for. I will often ask it to write automated tests for me. Once it's PRed everything, I then both review and test its code and, if it's good, merge into my PR, before running through our pipeline and merging everything.
Is this quicker?
Hmm.
It might not be quicker than an experienced Rails developer would make progress, but it's certainly a lot quicker than I - a very inexperienced Rails developer - would make progress unaided, and that's quite an important value-add in itself.
But yeah, if you look at it from a certain perspective, an LLM writes 90% of my code, but the reality is rather more nuanced, and so it's probably more like 50 - 70% that remains that way after I've got my grubby mitts on it.
This seems like a really short-sighted view. 6 months from now you'll be much more inexperienced than if you just went through the initial struggle (with an LLM's help!)
It seems like it may be true, but pointlessly true. I.e. yes, 90% of code is probably written by LLMs now - but that high number is because there is such a gigantic volume of garbage being generated.
The problem is not coding (for me). The problem is thinking for a long time about what to code, then the execution is merely the side effect of my thinking. The LLM has helped me execute faster. Is not a silver bullet, and I do review the outputs carefully. But I won’t pretend it hasn’t made me much more productive.
Not going far enough - why would applications be written in either 'systems languages' or 'agent languages' if you have superintelligence too cheap to meter and you will amortize the costs over more than, say, a few days? Just write in raw assembler from a domain-specific design hyperoptimized for solely the task, the way Donald Knuth on steroids would.
My take: Any gains from an "LLM-oriented language" will be swamped by the massive training set advantage held by existing mainstream languages. In order to compete, you would need to very rapidly build up a massive corpus of code examples in your new language, and the only way to do that is with... LLMs. Maybe it's feasible, but I suspect that it simply won't be worth the effort; existing languages are already good enough for LLMs to recursively self-improve.
There has been at least one posted here in Hacker News, Mojo. Google shows some other similar attempts.
The real issue with doing this is that there is no body of code available to train your models on. As a result the first few look like opinionated Python.
It seems the language would need to be strongly typed, have good error reporting and testing infrastructure, have a good standard library and high-level abstractions, and be "close enough" to existing languages. Go would seem to already fit that bill, any bespoke language you come up with is going to have less exposure in the training set than Go. Maybe Rust as a second, but Go's memory management might be easier for the LLM (and humans) than Rust's.
Python too -- hear me out. With spec-driven development to anchor things, coupled with property-based tests (PBT) using Hypothesis, it's great for prototyping problems.
You wouldn't write mission critical stuff with it, but it has two advantages over so-called "better designed languages": massive ecosystem and massive training.
If your problem involves manipulating dataframes (polars, pandas), plotting (seaborn), and machine learning, Python just can't be beat. You can try using an LLM to generate Rust code for this -- go ahead and try it -- and you'll see how bad it can be.
Better ecosystems and better training can beat better languages in many problem domains.
> You wouldn't write mission critical stuff with it
People do, they also write mission critical stuff in Lua, TCL, Perl, and plenty of other languages. What they generally won't do is write performance critical stuff in those languages. But there is definitely some critical communication infrastructure out there running with interpreted languages like these out there.
or rather, maybe we stop seeing new features that are mostly there for developers and find some older languages are quite good and capable, maybe even easier since there's less to reason about
I don't really want to learn how to use the borrow checker, LLM help or not, and I don't really want to use a language that doesn't have a reputation for very fast compile/dev workflow, LLM help or not.
Re; Go, I don't want to use a language that is slower than C, LLM help or not.
Zig is the real next Javascript, not Rust or Go. It's as fast or faster than C, it compiles very fast, it has fast safe release modes. It has incredible meta programming, easier to use even than Lisp.
Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.
Rusts borrow checker is only able to prove at compile-time that a subset of correct programs are correct. There are many correct programs that the BC is unable to prove to be correct and therefore rejects them.
I’m a big fan of Rust and the BC. But let’s not twist reality here.
Come on that’s not true. How would you write and LRU cache in rust? It’s not possible in idiomatic rust. You either need to use unsafe or use integer indices as a poor man’s pointer.
Indices are fine. Fixating on the “right” shape of the solution is your hang-up here. Different languages want different things. Fighting them never ends well.
Predicting the future is futile, but I would guess this would be exactly the opposite. LLMs make it remarkably easy to generate a lot of code so they can easily generate a lot of Rust code that looks good. It probably wouldn't be, and for us it would be unreadable when something goes wrong. We would end up in LLM debugging hell.
The solution is to use a higher level safer, strict language (e.g. Java) that would be easy for us to debug and deeply familiar to all LLMs. Yes, we will generate more code, but if you spend the LLM time focusing on nitpicking performance rather than productivity you would end up in the same problem you have with humans. LLMs also have capacity limits and the engineers that operate them have capacity limits, neither one is going away.
I've been thinking about this and using Rust for my next backend. I think we still lack a true "all in one" web "batteries included" framework like Django or RoR for Rust.
Maybe someone should use AI to write the code for that...
It might be the opposite. Python apps still get written despite the performance hit, because understandability matters more than raw performance in many cases. Now that we’re all code reviewers, that quality should matter more, not less. Programmer time is still more expensive than machine time in many cases.
I kinda like viewing this as similar to coordinate-invariance in physics / geometry. A programming language is effectively a function from textual programs to behaviors; this serves the same role as a coordinate system on a space, which is a function from coordinates to points. Naturally many different programs and programming languages can describe the same behavior, especially if you forget about implementation-specific details like memory layout or class structures. LLM code generation is just another piece of the same model: turns out that to some degree you can use English+LLMs as coordinate systems for the textual programs.
I expect that over time we will adopt a perspective on programming that the code doesn't matter at all; each engineer can bring whatever syntax or language they prefer, and it will be freely translated into isomorphic code in other languages as necessary to run in whatever setting necessary. Probably we will settle on an interchange format which is somehow as close as possible to the "intent" of the code, with all of the language-specific concepts stripped away, and then all a language will be is a toolbox that engineer carries with them of their favorite ways to express concepts.
but the interesting thing about coordinate systems is that they do matter, a lot! many problems are much much easier to solve in one coordinate system than another.
This is my second attempt learning Rust and I have found that LLMs are a game-changer. They are really good at proposing ways to deal with borrow-checker problems that are very difficult to diagnose as a Rust beginner.
In particular, an error on one line may force you to change a large part of your code. As a beginner this can be intimidating ("do I really need to change everything that uses this struct to use a borrow instead of ownership? will that cause errors elsewhere?") and I found that induced analysis paralysis in me. Talking to an LLM about my options gave me the confidence to do a big change.
n_u's point about LLMs as mentors for Rust's borrow checker matches my experience. The error messages are famously helpful, but sometimes you need someone to explain the why.
I've noticed the same pattern learning other things. Having an on-demand tutor that can see your exact code changes the learning curve. You still have to do the work, but you get unstuck faster.
I don't see why it shouldn't be even more automated than that, with LLM ideas tested automatically by differential testing of components against the previous implementation.
EDIT: typo fixed, thx
Defining tests that test for the right things requires an understanding of the problem space, just as writing the code yourself in the first place does. It's a catch-22. Using LLMs in that context would be pointless (unless you're writing short-lived one-off garbage on purpose).
I.e. the parent is speaking in the context of learning, not in the context of producing something that appears to work.
I'm not sure that's true. Bombarding code with huge numbers of randomly generated tests can be highly effective, especially if the tests are curated by examining coverage (and perhaps mutation kills) in the original code.
I'm assuming you meant to type
> I don't see why it *shouldn't be even more automated
In my particular case, I'm learning so having an LLM write the whole thing for me defeats the point. The LLM is a very patient (and sometimes unreliable) mentor.
I am old but C is similarly improved by LLM. Build system, boilerplate, syscalls, potential memory leaks. It will be OK when the Linux graybeards die because new people can come up to speed much more quickly
The thing is LLM-assisted C is still memory unsafe and almost certainly has undefined behaviour; the LLM might catch some low hanging fruit memory problems but you can never be confident that it's caught them all. So it doesn't really leave you any better off in the ways that matter.
I don’t code C much, is my passion side language. LLM improves my ability to be productive and quickly. Is not a silver bullet, but is an assist
My take: "Any application that was written in Javascript, eventually will be written in a system language"
While I still struggle to think in Rust after years of thinking in C, it is NEVER the borrow checker or lifetimes that trip me, it's the level of abstraction, in that C forced me low level, building my own abstractions, while Rust allows me to think in abstractions first and muse over how to implement those idiomatically.
What did it for me was thinking through how mutable==exclusive, non-mutable==shared, and getting my head around Send and Sync (not quite there yet).
AI helps me with boiler plate, but not with understanding, and if I don't understand I cannot validate what AI produces.
Rust is worth the effort.
Thank you for this comment.
I'm starting my rusty journey and I'm only a few months in. With the rise of autogenerated code, it's paradoxically much harder to go slow and understand the fundamentals.
Your comment is reassuring to read.
Just wanted to add another bit of reassurance. At some point during my career people started "stack overflow coding". But ultimately someone has to fix the difficult issues and when you have the skills, you are coming out on top where others can just shrug and say "well there's no solution on stack overflow".
> in 2026 devs write 90% of the code using natural language, through an LLM.
That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)?
If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with.
I literally cannot imagine a serious company in which that is a viable scenario.
I can believe LLM generated after being cut up into small slices that are carefully reviewed.
But to have 20 copies of Claude Code running simultaneously and the code works so well you don't need testers == high on your own supply.
> high on your own supply.
reminds me of a bar owner who died of liver failure. people said he himself was his best customer
If there's a human in then loop, actually reading the plans and generated code, then it's possible to have 90% of me code generated by an LLM and maintain reasonable quality.
That depends on how you define "doomed". Most screwed up companies don't go belly up overnight. They get sold as fixer-uppers and passed between bigger firms and given different names until, finally, it is sold for parts. The way this works is that all parties behave as if the company is the opposite of doomed. It's in a sense correct. The situation hardly seems doomed if everyone has enough time to make their money and split before the company's final death twitches cannot be denied, in which case the company accomplished its mission. That of course doesn't mean everything from its codebase to its leadership didn't lack excellence the whole time.
Its insane to me seeing this kind of thing. I write 100% of my code by hand. Of developers I know, they write >95% of code by hand
>We are entering an era where the Brain of the application (the orchestration of models, the decision-making) might remain in Python due to its rich AI ecosystem, but the Muscle, the API servers, the data ingestion pipelines, the sidecars, will inevitably move to Go and Rust. The friction of adopting these languages has collapsed, while the cost of not adopting them (in AWS bills and carbon footprint) is rising.
This is the most silicon valley brain thing I've seen for a while
We're entering an era where I continue to write applications in C++ like I've always done because its the right choice for the job, except I might evaluate AI as an autocomplete assistant at some point. Code quality and my understanding of that code remains high, which lets me deliver at a much faster pace than someone spamming llm agent orchestration, and debuggability remains excellent
90% of code written by devs is not written by AI. If this is true for you, try a job where you produce something of value instead of some random silicon valley startup
In my experience, most of the NodeJS shops do this. Because, LLMs on the surface seemingly are good at giving you a quick solution for JS code. Whether it's a real solution or patchwork is up for debate, but, for most mid-level to junior devs, it's good enough to get the job done. Now, multiply this workflow 10x for 10 employees. That's how you end up with a complete rewrite and hiring a senior consultant.
Yeah, I would say it's pretty variable, and it depends on what you mean by the word write.
I've recently joined a startup whose stack is Ruby on Rails + PostgreSQL. Whilst I've used PostgreSQL, and am extremely familiar with relational databases (especially SQL Server), I've never been a Rubyist - never written a line of Ruby until very recently in fact - and certainly don't know Rails, although the MVC architecture and the way projects are structured feels very comfortable.
We have what I'll describe as a prototype that I am in the process of reworking into a production app by fixing bugs, and making some pretty substantial functional improvements.
I would say, out of the gate, 90%+ of the code I'm merging is initially written by an LLM for which I'm writing prompts... because I don't know Ruby or Rails (although I'm picking them up fast), and rather than scratch my head and spend a lot of time going down a Google and Stackoverflow black hole, it's just easier to tell the LLM what I want. But, of course, I tell it what I want like the software engineer I am, so I keep it on a short leash where everything is quite tightly specified, including what I'm looking for in terms of structure and architectural concerns.
Then the code is fettled by me to a greater or lesser extent. Then I push and PR, and let Copilot review the code. Any good suggestions it makes I usually allow it to either commit directly or raise a PR for. I will often ask it to write automated tests for me. Once it's PRed everything, I then both review and test its code and, if it's good, merge into my PR, before running through our pipeline and merging everything.
Is this quicker?
Hmm.
It might not be quicker than an experienced Rails developer would make progress, but it's certainly a lot quicker than I - a very inexperienced Rails developer - would make progress unaided, and that's quite an important value-add in itself.
But yeah, if you look at it from a certain perspective, an LLM writes 90% of my code, but the reality is rather more nuanced, and so it's probably more like 50 - 70% that remains that way after I've got my grubby mitts on it.
This seems like a really short-sighted view. 6 months from now you'll be much more inexperienced than if you just went through the initial struggle (with an LLM's help!)
It seems like it may be true, but pointlessly true. I.e. yes, 90% of code is probably written by LLMs now - but that high number is because there is such a gigantic volume of garbage being generated.
The problem is not coding (for me). The problem is thinking for a long time about what to code, then the execution is merely the side effect of my thinking. The LLM has helped me execute faster. Is not a silver bullet, and I do review the outputs carefully. But I won’t pretend it hasn’t made me much more productive.
I wonder when we'll start to see languages designed exclusively to be easy to write by agent programming.
Not going far enough - why would applications be written in either 'systems languages' or 'agent languages' if you have superintelligence too cheap to meter and you will amortize the costs over more than, say, a few days? Just write in raw assembler from a domain-specific design hyperoptimized for solely the task, the way Donald Knuth on steroids would.
Here's one attempt: https://x.com/sigilante/status/2013743578950873105
My take: Any gains from an "LLM-oriented language" will be swamped by the massive training set advantage held by existing mainstream languages. In order to compete, you would need to very rapidly build up a massive corpus of code examples in your new language, and the only way to do that is with... LLMs. Maybe it's feasible, but I suspect that it simply won't be worth the effort; existing languages are already good enough for LLMs to recursively self-improve.
Lisp?
I'm always surprised when agents aren't working directly with the AST.
There has been at least one posted here in Hacker News, Mojo. Google shows some other similar attempts.
The real issue with doing this is that there is no body of code available to train your models on. As a result the first few look like opinionated Python.
It seems the language would need to be strongly typed, have good error reporting and testing infrastructure, have a good standard library and high-level abstractions, and be "close enough" to existing languages. Go would seem to already fit that bill, any bespoke language you come up with is going to have less exposure in the training set than Go. Maybe Rust as a second, but Go's memory management might be easier for the LLM (and humans) than Rust's.
Rust, Go and TypeScript are good bets.
Python too -- hear me out. With spec-driven development to anchor things, coupled with property-based tests (PBT) using Hypothesis, it's great for prototyping problems.
You wouldn't write mission critical stuff with it, but it has two advantages over so-called "better designed languages": massive ecosystem and massive training.
If your problem involves manipulating dataframes (polars, pandas), plotting (seaborn), and machine learning, Python just can't be beat. You can try using an LLM to generate Rust code for this -- go ahead and try it -- and you'll see how bad it can be.
Better ecosystems and better training can beat better languages in many problem domains.
> You wouldn't write mission critical stuff with it
People do, they also write mission critical stuff in Lua, TCL, Perl, and plenty of other languages. What they generally won't do is write performance critical stuff in those languages. But there is definitely some critical communication infrastructure out there running with interpreted languages like these out there.
or rather, maybe we stop seeing new features that are mostly there for developers and find some older languages are quite good and capable, maybe even easier since there's less to reason about
I don't really want to learn how to use the borrow checker, LLM help or not, and I don't really want to use a language that doesn't have a reputation for very fast compile/dev workflow, LLM help or not.
Re; Go, I don't want to use a language that is slower than C, LLM help or not.
Zig is the real next Javascript, not Rust or Go. It's as fast or faster than C, it compiles very fast, it has fast safe release modes. It has incredible meta programming, easier to use even than Lisp.
Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.
Idk. Did you see the "Buffer reuse" section of this blog post? [1]
Kudos to that guy for solving the puzzle, but I really don't want to use a special trick to get the compiler to let me reuse a buffer in a for loop.
[1]: https://davidlattimore.github.io/posts/2025/09/02/rustforge-...
This is a n objectively false statement.
Rusts borrow checker is only able to prove at compile-time that a subset of correct programs are correct. There are many correct programs that the BC is unable to prove to be correct and therefore rejects them.
I’m a big fan of Rust and the BC. But let’s not twist reality here.
Come on that’s not true. How would you write and LRU cache in rust? It’s not possible in idiomatic rust. You either need to use unsafe or use integer indices as a poor man’s pointer.
Indices are fine. Fixating on the “right” shape of the solution is your hang-up here. Different languages want different things. Fighting them never ends well.
What's wrong with integer indices? They have bounds checking. You definitely do not need unsafe to do LRU.
Predicting the future is futile, but I would guess this would be exactly the opposite. LLMs make it remarkably easy to generate a lot of code so they can easily generate a lot of Rust code that looks good. It probably wouldn't be, and for us it would be unreadable when something goes wrong. We would end up in LLM debugging hell.
The solution is to use a higher level safer, strict language (e.g. Java) that would be easy for us to debug and deeply familiar to all LLMs. Yes, we will generate more code, but if you spend the LLM time focusing on nitpicking performance rather than productivity you would end up in the same problem you have with humans. LLMs also have capacity limits and the engineers that operate them have capacity limits, neither one is going away.
I've been thinking about this and using Rust for my next backend. I think we still lack a true "all in one" web "batteries included" framework like Django or RoR for Rust.
Maybe someone should use AI to write the code for that...