Maybe? But it doesn't change the fact that most code written is tedious and repetitive and not particularly novel, except as part of one's own personal journey as a programmer.

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.

Sometimes frameworks are a little too magic. Think raw sql vs a magic orm. No I'm not saying don't use an orm, but when everything ends up as magic meta configuration it's sometimes too much. Sometimes making things a little explicit can make it more flexible going forward.

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.

Yeah its not a huge amount, but its a start. eg - just got it to make me a class in Lua with names for all the colours. It went and named all the colors and did a very nice job (Claude) - it would have taken me ages to go and find the names, sort them out etc, and I was avoiding the work, cause its tedious. I've got it to make me windows controls and data structures, parsers all well defined stuff.

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.

I have a suspicion that the majority of code is rather mundane. After all the community did create the term CRUD to describe typical corporate work.

Maybe?

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.

Raising the level of abstraction can greatly reduce tedium, and can make code a lot easier to grok.

Introducing LLM generated code doesn't do that in my experience.