It depends a lot. I work as a web platform engineer so the datasets on some parts of what I do are limited.
For a react project, there are millions of projects, code and setups in the training data.
To create and manage a monorepo that runs on our specific infrastructure, the story is different.
Writing bash scripts to run on GitHub actions: 10x.
Ask to setup a monorepo: -3x.
Modify a specific business domain: -10x.
A couple of weeks ago I was handed a project that was the implementation of a experimentation sdk. The project was made by previous developer with Claude. I couldn't understand a thing. I had to basically start from scratch to understand all the principles of how this experimentation tool worked.
This was not fault of the previous Devs, it was a combination of reading code from a third³ person (person through an LLM) plus I'm a bottom up processor.
I read here some time ago an article of how LLM generated content is the new nylon/lycra. In the 80's this fabric was all the rage but now it just feel cheaper.
The same happens to me when people quote something an LLM told them as a big true.
I love the idea of converge with the web and also like the simplicity of being able to see what is happening.
I've also experienced the despair or having to debug the internals of a library or a wrapper of a wrapper of a wrapper somebody thought was a good idea to make.
But I wonder how the future in a LLM powered world could look like.
Will LLMs privilege code that require less tokens to read and to write? Will verbosity become a monetary problem? Will short implicit Frameworks take the lead?
I wonder if frameworks will start to optimize for machines or people.
Short term profit companies usually try to get away with giving you the less they can while charging you as much as possible.
There are still mid size company that try to make a good product for a fair price, but I have the gut feeling that any company that have a board of shareholders will always default to this behaviour.
The same is happening to me. I live in Europe and I'm a staff engineer with almost 40 y/o but I have to be honest and I think I'm not going to be able to grow on the corporate track. Whatever comes next will come from other sources, maybe consulting, maybe teaching, but I don't see an option moving forward, and I'm kind of fine with it.
I think that it depends a lot on how much customisation you have to do on top of NextJS to make it work for your personal use case.
For example if you stay as close as possible to the framework defaults, everything is golden. But as soon you start pushing it to the limits the cracks start to appear.
Last year I was working on a NextJS app with 15k files, 18k unit tests, 100+ developers in the same repository and a page with hundred of millions of page views daily. Under that conditions NextJS doesn't scale, but again, those conditions are not the majority of the NextJS cases.
In that project, we have been using NextJS as a standalone for around 5 years and each time NextJS rollout a major version it take us at least 2 months to be able to upgrade and keep it working.
It depends a lot. I work as a web platform engineer so the datasets on some parts of what I do are limited. For a react project, there are millions of projects, code and setups in the training data. To create and manage a monorepo that runs on our specific infrastructure, the story is different. Writing bash scripts to run on GitHub actions: 10x. Ask to setup a monorepo: -3x. Modify a specific business domain: -10x. A couple of weeks ago I was handed a project that was the implementation of a experimentation sdk. The project was made by previous developer with Claude. I couldn't understand a thing. I had to basically start from scratch to understand all the principles of how this experimentation tool worked. This was not fault of the previous Devs, it was a combination of reading code from a third³ person (person through an LLM) plus I'm a bottom up processor.
reply