I wrote my own frameworks as a kid, and I found that exciting. It helped me understand and accept frameworks written by others, and with actual adoption. Doesn't change the fact that none of that code is particularly original or insightful. It's mundane and done to death - like almost all almost every software company does.
Not seeing the tedium may be a sign of working on really interesting problems, or using excellent frameworks and support tooling - but I'd wager it's mostly a sign of inexperience.
Even if the framework is good, an llm can read the docs faster than you. Probably it's important to understand things in a lot of cases, but sometimes you just need to get it working without really reading the framework source or docs.
And your proposed solution is using an LLM? Because that's less magical than a framework?
I think the problem comes about when it doesn't know the context you're in - give me a list of colour names is well defined, and I assume the LLM's would have read a million pages with this done, so its easy for it to do this. Doing something more exotic that it hasn't seen a lot, then you'll get weird results.
Probably not literally "ages", more like 30 minutes actually.
The average non-software business likely doesn't need to innovate in the software space but rather automate as much as possible so they can innovate elsewhere.
You could basically categorize all programming as CRUD (you’re just reading and updating some bits).
In some cases, definitely. Then good luck making the business case to improve the framework or swap and refactor around a different framework. (Or you can do what I do during the more motivated/less busy times in my life: find undisturbed unpaid time to do it for your team.)
In other cases improving the framework comes at the cost of some magic that may obscure the intent of the code.
The nice thing about LLM code is that it's code. You're not monkey patching a method. You're not subtly changing the behavior of a built-in. You're not adding a build step (though one can argue that LLM generated code is akin to a separate build step.) You're just checking in code. Other contributors can just read the code.
Introducing LLM generated code doesn't do that in my experience.
I think this is one of the major benefits of LLMs. It's far less tedious to repeat yourself and write boilerplate when doing so is a better engineering decision than adding more layers of abstraction.
