The argument here is that React has permanently won because LLMs are so heavily trained on it and default to it in their answers.
I don't buy this. The big problem with React is that the compilation step is almost required - and that compilation step is a significant and growing piece of friction.
Compilation and bundling made a lot more sense before browsers got ES modules and HTTP/2. Today you can get a long way without a bundler... and in a world where LLMs are generating code that's actually a more productive way to work.
Telling any LLM "use Vanilla JS" is enough to break them out of the React cycle, and the resulting code works well and, crucially, doesn't require a round-trip through some node.js build mechanism just to start using it.
Call me a wild-eyed optimist, but I'm hoping LLMs can help us break free of React and go back to building things in a simpler way. The problems React solve are mostly around helping developers write less code and avoid having to implement their own annoying state-syncing routines. LLMs can spit out those routines in a split-second.
> The big problem with React is that the compilation step is almost required - and that compilation step is a significant and growing piece of friction.
Having a build step more than pays for itself just in terms of detecting errors without having to execute that codepath. The friction is becoming less and less as the compilation step is increasingly built into your project/dependency management tool and increasingly faster (helped by the trend towards Rust or Go now that the required functionality is relatively well-understood)
> The problems React solve are mostly around helping developers write less code and avoid having to implement their own annoying state-syncing routines. LLMs can spit out those routines in a split-second.
An LLM can probably generate the ad hoc, informally-specified, bug-ridden, slow implementation of half of React that every non-React application needs very quickly, sure. But can the LLM help you comprehend it (or fix bugs in it) any faster? That's always been the biggest cost, not the initial write.
_I'm gonna narrow in on the bit about compilation steps_.
Anyone shipping production code will one way of another have some kind of build step, whether that's bundling, minification, typechecking, linting, finger printing files, etc. At that point it makes little difference if you add a build step for compilation.
I'm sympathetic to not wanting to deal with build processes I try to avoid them where I can in my side projects. The main web project I've been working on for the last year has no build step, uses Vanilla JS & web components. But it's also not a consumer facing product.
I think there's friction for sure, but I just can't see this being an issue for most cases where a build step is already in place for other concerns. And Developers are fairly familiar with build steps especially if you do anything outside the web in C/C++ or Java/C# or Rust or whatever.
Fwiw - I'm hoping it can break out too. But one of the biggest challenges is that last bit "asking it to use vanilla JS" - unsee this all the time in developer relations: getting developers to ask for a specific thing or even have it on their mind to think about using it is one of the biggest hurdles.
While I tend to agree, I think there's still an undercurrent of React-like paradigms being strongly preferenced in the training data so assuming LLMs continue to get much better, if you were to build a simple UI toolkit with an LLM, there's a strong chance that over time with accretion you will end up remaking React or any one other framework unless you're particularly opinionated about direction.
I share your optimism. Once you move up a conceptual layer (from writing code to guiding an LLM), the lower level almost becomes interchangeable. You can even ask the LLM to translate from one language/framework to another.
what about the value of abstraction to readability and maintainability? Do you really want to be stuck with debugging/upgrading and generally working with such low level vanilla js code when elegant abstractions are so much more efficient ?
I've been leaning more on web components as an abstraction here, once an LLM can take care of their boilerplate they're a pretty nice way to modularize frontend code.
I also think the pitfall that might exist here is the base assumption that developers are allowing the LLMs to make architecture decisions either not addressing the issue at all and just prompting for end results or not making the choice before asking the LLM.
E.g., if most developers are telling their LLMs “build me a react app” or “I want to build a website with the most popular framework,” they were going to end up with a react app with or without LLMs existing.
I’m sure a lot of vibecoders are letting Jesus take the wheel, but in my vibecoding sessions I definitely tend to have some kind of discussion about my needs and requirements before choosing a framework. I’m also seeing more developers talking about using LLMs with instructions files and project requirement documents that they write and store in their repo before getting started with prompting, and once you discover that paradigm you don’t tend to go back.
If this gets me out of the "This framework that almost everyone uses and is easy to hire for and that works well for a lot of people is literally unusable compared to this new hot framework I fell in love with recently! We need to rebuild everything!"-discussion, I'm fine with it
I try to filter out such people in hiring nowadays but sometimes you miss, or come into an existing team with these issues
On the plus side, maybe this means the endless churn of JS libraries will finally slow down and as someone who isn’t a JS developer but occasionally needs to dip their toe into the ecosystem, I can actually get stuff done without having to worry about 6-month old tutorials being wrong and getting caught in endless upgrade hell.
For what it’s worth - vanilla JS is pretty darn good and if you’re only dipping in for some small functionality I highly doubt a framework brings much benefit.
Has this actually been true, though? I admit I don’t write JavaScript much recently, but to me it feels like things have pretty stabilized. React released hooks in early 2019 before Covid, and after that things don’t really change much at all.
At this point there are several large Rust UI libraries that try to replicate this pattern in web assembly, and they all had enough time to appear and mature without the underlying JSX+hooks model becoming outdated. To me it’s a clear sign that JS world slowed down.
Yes. When I dipped my toes into the front end ecosystem in 2021 to build a portfolio site, the month old tutorial video I followed, was already out of date. React had released an update to routers and I could not find any documentation on it. Googling for the router brought me to pages that said to do what I had done, which disagreed with the error message that I was getting from react.
React had just updated and documentation hadn’t.
I then discovered that Meta owns React so I got frustrated as hell with their obfuscation and ripped out all of the React and turned what was left into vanilla html+js.
I don't buy it, I've used LLMs (well, mostly sonnet 4.5 and sometimes gpt5) in a variety of front-end frameworks (react, vue, htmx) and they do just fine. As usual, requires a lot of handholding and care to get good results, but I've found this is true for react codebases just as much as anything else.
As LLMs improve, it matters less what they are trained on and more what they understand. I've used codex on some very obscure code bases and frameworks. It's fine. It understands them. It broadly does the right things. It can understand from examples in your code how to use things. To give you one example, I'm using an obscure framework called fritz2 with kotlin-js. Kotlin-js is not that widely used. And I'm probably one of a handful of active users of this Fritz2 framework in the world. There isn't a whole lot of code to train on. And what little there is is probably a bit outdated.
It's fine. I've been using codex on some code bases with this with pretty alright results. I also use codex to generate typescript/react code. I'm getting similar results. I had a little wow moment when I asked it to add some buttons and then afterwards realized that it had figured out the localization framework (one of my creations) and added translations for the button labels. All unprompted. It clearly understood the code base and how I like things done. So it just went ahead and did them. The syntax is not a problem. The obscurity of the library is not a problem as long as you give it enough to work with. It does less well coding something from scratch than working on existing code.
IMHO, things like react are optimized for humans. They aren't actually that optimal for LLMs to work with. It's actually impressive that they can. Too much expressiveness and ambiguity. LLMs like things spelled out. Humans don't. We're still doing things manually so it helps if we can read and edit what the LLMs do. But that won't stay like that.
I think in a few years, we'll start seeing languages and frameworks that are more optimal for Agentic coding tools as they will be the main users. So, stronger typing. More verbosity and less ambiguity.
I don't buy it either. I've been building my own backend framework for the past 2.5 years, and even though it's a DSL over Python and there's no documentation online and barely one in my computer, Claude Code understands it with enough usage examples in my codebase.
In front-end as well—I've been able to go much farther for simple projects using alpine than more complex frameworks. For big products I use Elm, which isn't exactly the most common front-end choice but it provides a declarative programming style that forces the LLM to write more correct code faster.
In general, I think introspectible frameworks have a better case, and whether they're present in training data or not becomes more irrelevant as the introspectibility increases. Wiring the Elm compiler to a post-write hook means I basically have not written front-end code in 4 or 5 months. Using web standards and micro frameworks with no build step means the LLM can inspect the behaviour using the chrome dev tools MCP and check its work much more effectively than having to deal with the React loop. The ecosystem is so fragmented there, I'm not sure about the "quality because of quantity of training data" argument.
Author here. This is a fair comment. If you have a corpus that can be used as context already it's not like the LLMs will be forcing you in to React, there's probably enough bias (in a good way) to ensure the tool continues to be useful.
What I was trying to get at in the post is that net new experiences is where I see a massive delta
I feel like there could be a loophole here for the new-framework-author. Stick to using JSX for the view; JSX is just syntax sugar for built in react functions for constructing a tree, which can be easily swappable with your own implementation. I recall years ago using a babel plugin that just emitted static HTML from JSX. I know Vue.js v2 also had JSX support that way.
I think LLMs, despite already being trained massively on React, can easily adapt their output to suit a new framework's-specific API surface with a simple adjustment to the prompt. Maybe include an abbreviated list of type/function signatures that are specific to your new framework and just tell the LLM to use JSX for the views?
What I think will definitely be a challenge for new library authors in the age of LLMs is state management. There are already tons of libraries that basically achieve the same thing but have vastly different APIs. In this case, new lib-authors may be forced to just write pluggable re-implementations of existing libraries just to enable LLMs to emit compilable/runnable code. Though I dont know of any state management library that dominates the web like React does with the view layer.
A built in feature with frameworks is that you constantly have to update your code to be in sync with the latest version of the framework, this create work for contractors, it's like a taxation of software.
Thanks god. The days people kept inventing new JS frameworks or even dialects (coffeescript, remember?) every three months couldn't be gone fast enough.
Coffeescript was great though, because at the time Javascript was growing fast but the language was developing slowly or not at all. There was also Atscript for a little while which added annotations because Typescript didn't want to add them; they eventually budged and Atscript was dead. Then there was a fork of Node because Node at the time was still tightly controlled by Joyent, whereas its fork (io.js or js.io or something) was an open governance model. It was eventually merged back into node.
TL;DR sometimes you need to make an alternative to get the original to move.
A blog named "AI Focus" is of course going to push LLMs and vibe coding. But here in the real world, people can still code without LLMs, or use them with a human in control, where the LLM can look at existing code written in a framework that is not React.
Also, React was extremely popular before any LLMs were out there. I would not ascribe much of the growth to vibe coding.
Just to push back on this a tad. Yes there's growth React, it's popular, but it was consistent up until the introduction of some of the more popular code generation tools where there is a clear acceleration (if you believe builtwith.com data) in the last 9 months or so.
I'm not really sure why this focuses so much on React, when it's a general "issue"/"feature"
More broadly, obviously there is some pressure to use a framework/library/programminglang/editor that has better LLM training. But even before LLMs.. you'd want to choose the one that has more SO questions, more blog posts and books published about it. The one where you can hire experienced programmers.
New players has a certain activation energy they need to overcome - which is probably good. B/c it slows down the churn of new shiny with incrementally improvements. I think a paradigm shift is sufficient though. Programmers like new shiny things - especially the good ones that are passionate about their craft
Sure. Is there a competitive advantage to people who know COBOL and never bothered to learn Java?
At the moment I still consider it a tool alongside all other tool, or else a business strategy next to e.g. outsourcing. My job didn't go away because there's 1000x more of them overseas. But likewise, it also didn't go away because there's individuals 1000x better (educated, developed, paid, connected) than me in the US.
I embraced this when I had the same realisation that React will get reinforced the most, and vibe-coded something in it.
I had to ditch the whole thing and rewrite it in Vue when it got big enough that I couldn’t debug it without learning React.
Vibe-coding something in a stack you know or want to know means you can get off your high horse and peek into the engine.
I still agree with the sentiment that React is winning; if the competition of volume. But other frameworks won’t stop existing unless you believe that people exclusively choose what is dominant. But there will always be artisans, even after all old people who learned the alternatives were flushed out.
LLMs are great at HTMX and Python. Both Claude Code and Codex do well at it so I’m fine with things like that. React is fine but HTMX does well. I also frequently used to copy Claude’s generated React things into ChatGPT and ask it to rewrite them in Vanilla JS and it would work but that was a year ago when artifacts were just being launched.
Nothing different then - before AI it would have been search engines or social networks / upvotes of the masses.
The common factor is the reader, taking what the search engine, SO commenter or AI takes as gospel. A good software developer can judge multiple inputs on their own.
And if someone doesn't care what an AI does it really isn't important what they are having it build or what tool it uses, clearly.
You could always write some code in a different framework and help spread around other types of reusable template frameworks. Like in XSLT for example...oh wait... that's been killed off too.
The argument here is that React has permanently won because LLMs are so heavily trained on it and default to it in their answers.
I don't buy this. The big problem with React is that the compilation step is almost required - and that compilation step is a significant and growing piece of friction.
Compilation and bundling made a lot more sense before browsers got ES modules and HTTP/2. Today you can get a long way without a bundler... and in a world where LLMs are generating code that's actually a more productive way to work.
Telling any LLM "use Vanilla JS" is enough to break them out of the React cycle, and the resulting code works well and, crucially, doesn't require a round-trip through some node.js build mechanism just to start using it.
Call me a wild-eyed optimist, but I'm hoping LLMs can help us break free of React and go back to building things in a simpler way. The problems React solve are mostly around helping developers write less code and avoid having to implement their own annoying state-syncing routines. LLMs can spit out those routines in a split-second.
> The big problem with React is that the compilation step is almost required - and that compilation step is a significant and growing piece of friction.
Having a build step more than pays for itself just in terms of detecting errors without having to execute that codepath. The friction is becoming less and less as the compilation step is increasingly built into your project/dependency management tool and increasingly faster (helped by the trend towards Rust or Go now that the required functionality is relatively well-understood)
> The problems React solve are mostly around helping developers write less code and avoid having to implement their own annoying state-syncing routines. LLMs can spit out those routines in a split-second.
An LLM can probably generate the ad hoc, informally-specified, bug-ridden, slow implementation of half of React that every non-React application needs very quickly, sure. But can the LLM help you comprehend it (or fix bugs in it) any faster? That's always been the biggest cost, not the initial write.
_I'm gonna narrow in on the bit about compilation steps_.
Anyone shipping production code will one way of another have some kind of build step, whether that's bundling, minification, typechecking, linting, finger printing files, etc. At that point it makes little difference if you add a build step for compilation.
I'm sympathetic to not wanting to deal with build processes I try to avoid them where I can in my side projects. The main web project I've been working on for the last year has no build step, uses Vanilla JS & web components. But it's also not a consumer facing product.
I think there's friction for sure, but I just can't see this being an issue for most cases where a build step is already in place for other concerns. And Developers are fairly familiar with build steps especially if you do anything outside the web in C/C++ or Java/C# or Rust or whatever.
Fwiw - I'm hoping it can break out too. But one of the biggest challenges is that last bit "asking it to use vanilla JS" - unsee this all the time in developer relations: getting developers to ask for a specific thing or even have it on their mind to think about using it is one of the biggest hurdles.
My actual long term hope is that in the future we won't need to think about frameworks at all: https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...
While I tend to agree, I think there's still an undercurrent of React-like paradigms being strongly preferenced in the training data so assuming LLMs continue to get much better, if you were to build a simple UI toolkit with an LLM, there's a strong chance that over time with accretion you will end up remaking React or any one other framework unless you're particularly opinionated about direction.
I share your optimism. Once you move up a conceptual layer (from writing code to guiding an LLM), the lower level almost becomes interchangeable. You can even ask the LLM to translate from one language/framework to another.
Author here. Fwiw this is my hope too. I wrote about something similar in the past https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...
what about the value of abstraction to readability and maintainability? Do you really want to be stuck with debugging/upgrading and generally working with such low level vanilla js code when elegant abstractions are so much more efficient ?
I've been leaning more on web components as an abstraction here, once an LLM can take care of their boilerplate they're a pretty nice way to modularize frontend code.
To be fair, React is a very leaky abstraction, I wouldn't define it "elegant". It does work at simplifying things for certain usecases though
I also think the pitfall that might exist here is the base assumption that developers are allowing the LLMs to make architecture decisions either not addressing the issue at all and just prompting for end results or not making the choice before asking the LLM.
E.g., if most developers are telling their LLMs “build me a react app” or “I want to build a website with the most popular framework,” they were going to end up with a react app with or without LLMs existing.
I’m sure a lot of vibecoders are letting Jesus take the wheel, but in my vibecoding sessions I definitely tend to have some kind of discussion about my needs and requirements before choosing a framework. I’m also seeing more developers talking about using LLMs with instructions files and project requirement documents that they write and store in their repo before getting started with prompting, and once you discover that paradigm you don’t tend to go back.
[dead]
If this gets me out of the "This framework that almost everyone uses and is easy to hire for and that works well for a lot of people is literally unusable compared to this new hot framework I fell in love with recently! We need to rebuild everything!"-discussion, I'm fine with it
I try to filter out such people in hiring nowadays but sometimes you miss, or come into an existing team with these issues
On the plus side, maybe this means the endless churn of JS libraries will finally slow down and as someone who isn’t a JS developer but occasionally needs to dip their toe into the ecosystem, I can actually get stuff done without having to worry about 6-month old tutorials being wrong and getting caught in endless upgrade hell.
For what it’s worth - vanilla JS is pretty darn good and if you’re only dipping in for some small functionality I highly doubt a framework brings much benefit.
Has this actually been true, though? I admit I don’t write JavaScript much recently, but to me it feels like things have pretty stabilized. React released hooks in early 2019 before Covid, and after that things don’t really change much at all.
At this point there are several large Rust UI libraries that try to replicate this pattern in web assembly, and they all had enough time to appear and mature without the underlying JSX+hooks model becoming outdated. To me it’s a clear sign that JS world slowed down.
Yes. When I dipped my toes into the front end ecosystem in 2021 to build a portfolio site, the month old tutorial video I followed, was already out of date. React had released an update to routers and I could not find any documentation on it. Googling for the router brought me to pages that said to do what I had done, which disagreed with the error message that I was getting from react.
React had just updated and documentation hadn’t.
I then discovered that Meta owns React so I got frustrated as hell with their obfuscation and ripped out all of the React and turned what was left into vanilla html+js.
I don't buy it, I've used LLMs (well, mostly sonnet 4.5 and sometimes gpt5) in a variety of front-end frameworks (react, vue, htmx) and they do just fine. As usual, requires a lot of handholding and care to get good results, but I've found this is true for react codebases just as much as anything else.
As LLMs improve, it matters less what they are trained on and more what they understand. I've used codex on some very obscure code bases and frameworks. It's fine. It understands them. It broadly does the right things. It can understand from examples in your code how to use things. To give you one example, I'm using an obscure framework called fritz2 with kotlin-js. Kotlin-js is not that widely used. And I'm probably one of a handful of active users of this Fritz2 framework in the world. There isn't a whole lot of code to train on. And what little there is is probably a bit outdated.
It's fine. I've been using codex on some code bases with this with pretty alright results. I also use codex to generate typescript/react code. I'm getting similar results. I had a little wow moment when I asked it to add some buttons and then afterwards realized that it had figured out the localization framework (one of my creations) and added translations for the button labels. All unprompted. It clearly understood the code base and how I like things done. So it just went ahead and did them. The syntax is not a problem. The obscurity of the library is not a problem as long as you give it enough to work with. It does less well coding something from scratch than working on existing code.
IMHO, things like react are optimized for humans. They aren't actually that optimal for LLMs to work with. It's actually impressive that they can. Too much expressiveness and ambiguity. LLMs like things spelled out. Humans don't. We're still doing things manually so it helps if we can read and edit what the LLMs do. But that won't stay like that.
I think in a few years, we'll start seeing languages and frameworks that are more optimal for Agentic coding tools as they will be the main users. So, stronger typing. More verbosity and less ambiguity.
I don't buy it either. I've been building my own backend framework for the past 2.5 years, and even though it's a DSL over Python and there's no documentation online and barely one in my computer, Claude Code understands it with enough usage examples in my codebase.
In front-end as well—I've been able to go much farther for simple projects using alpine than more complex frameworks. For big products I use Elm, which isn't exactly the most common front-end choice but it provides a declarative programming style that forces the LLM to write more correct code faster.
In general, I think introspectible frameworks have a better case, and whether they're present in training data or not becomes more irrelevant as the introspectibility increases. Wiring the Elm compiler to a post-write hook means I basically have not written front-end code in 4 or 5 months. Using web standards and micro frameworks with no build step means the LLM can inspect the behaviour using the chrome dev tools MCP and check its work much more effectively than having to deal with the React loop. The ecosystem is so fragmented there, I'm not sure about the "quality because of quantity of training data" argument.
Author here. This is a fair comment. If you have a corpus that can be used as context already it's not like the LLMs will be forcing you in to React, there's probably enough bias (in a good way) to ensure the tool continues to be useful.
What I was trying to get at in the post is that net new experiences is where I see a massive delta
I feel like there could be a loophole here for the new-framework-author. Stick to using JSX for the view; JSX is just syntax sugar for built in react functions for constructing a tree, which can be easily swappable with your own implementation. I recall years ago using a babel plugin that just emitted static HTML from JSX. I know Vue.js v2 also had JSX support that way.
I think LLMs, despite already being trained massively on React, can easily adapt their output to suit a new framework's-specific API surface with a simple adjustment to the prompt. Maybe include an abbreviated list of type/function signatures that are specific to your new framework and just tell the LLM to use JSX for the views?
What I think will definitely be a challenge for new library authors in the age of LLMs is state management. There are already tons of libraries that basically achieve the same thing but have vastly different APIs. In this case, new lib-authors may be forced to just write pluggable re-implementations of existing libraries just to enable LLMs to emit compilable/runnable code. Though I dont know of any state management library that dominates the web like React does with the view layer.
A built in feature with frameworks is that you constantly have to update your code to be in sync with the latest version of the framework, this create work for contractors, it's like a taxation of software.
Thanks god. The days people kept inventing new JS frameworks or even dialects (coffeescript, remember?) every three months couldn't be gone fast enough.
Coffeescript was great though, because at the time Javascript was growing fast but the language was developing slowly or not at all. There was also Atscript for a little while which added annotations because Typescript didn't want to add them; they eventually budged and Atscript was dead. Then there was a fork of Node because Node at the time was still tightly controlled by Joyent, whereas its fork (io.js or js.io or something) was an open governance model. It was eventually merged back into node.
TL;DR sometimes you need to make an alternative to get the original to move.
Shoutout to CoffeeScript!
A blog named "AI Focus" is of course going to push LLMs and vibe coding. But here in the real world, people can still code without LLMs, or use them with a human in control, where the LLM can look at existing code written in a framework that is not React.
Also, React was extremely popular before any LLMs were out there. I would not ascribe much of the growth to vibe coding.
Just to push back on this a tad. Yes there's growth React, it's popular, but it was consistent up until the introduction of some of the more popular code generation tools where there is a clear acceleration (if you believe builtwith.com data) in the last 9 months or so.
I'm not really sure why this focuses so much on React, when it's a general "issue"/"feature"
More broadly, obviously there is some pressure to use a framework/library/programminglang/editor that has better LLM training. But even before LLMs.. you'd want to choose the one that has more SO questions, more blog posts and books published about it. The one where you can hire experienced programmers.
New players has a certain activation energy they need to overcome - which is probably good. B/c it slows down the churn of new shiny with incrementally improvements. I think a paradigm shift is sufficient though. Programmers like new shiny things - especially the good ones that are passionate about their craft
I find pretty much all models in vscode decent enough on Vue+Quasar. The fact they make bad choices I don't blame on them not understanding Vue.
I absolutely wouldn't be swapping because the output 'isn't good enough'.
And while the bulk of the internet stagnates into mediocrity is there a competitive advantage for people who never let their actual skills dull?
Sure. Is there a competitive advantage to people who know COBOL and never bothered to learn Java?
At the moment I still consider it a tool alongside all other tool, or else a business strategy next to e.g. outsourcing. My job didn't go away because there's 1000x more of them overseas. But likewise, it also didn't go away because there's individuals 1000x better (educated, developed, paid, connected) than me in the US.
Maybe, or maybe not. Is a welder valuable to Ford Motor Company if all their welders are robots?
Why make all these graphs to show that react is dominating, which we already know, to make a guess?
Should have made graphs testing LLMs with different frameworks.
So its going to be just like jquery. Never really dying fully.
I embraced this when I had the same realisation that React will get reinforced the most, and vibe-coded something in it.
I had to ditch the whole thing and rewrite it in Vue when it got big enough that I couldn’t debug it without learning React.
Vibe-coding something in a stack you know or want to know means you can get off your high horse and peek into the engine.
I still agree with the sentiment that React is winning; if the competition of volume. But other frameworks won’t stop existing unless you believe that people exclusively choose what is dominant. But there will always be artisans, even after all old people who learned the alternatives were flushed out.
LLMs are great at HTMX and Python. Both Claude Code and Codex do well at it so I’m fine with things like that. React is fine but HTMX does well. I also frequently used to copy Claude’s generated React things into ChatGPT and ask it to rewrite them in Vanilla JS and it would work but that was a year ago when artifacts were just being launched.
yup, patterns due to llms may alter languages and preferential bits quite a bit
This is the AI apocalypse. Not AI nuking us, but nuking choice.
Nothing different then - before AI it would have been search engines or social networks / upvotes of the masses.
The common factor is the reader, taking what the search engine, SO commenter or AI takes as gospel. A good software developer can judge multiple inputs on their own.
And if someone doesn't care what an AI does it really isn't important what they are having it build or what tool it uses, clearly.
Just write some code that uses your preferred framework?
It matters if one cannot write code.
Ask your wizard to use a different framework?
You could always write some code in a different framework and help spread around other types of reusable template frameworks. Like in XSLT for example...oh wait... that's been killed off too.
That was depressing as shit.