> LLMs are good for playing with stuff, yes, and that has been implied by your parent commenter as well I think. But when you have to scale the work, then the code has to be easy to read, easy to extend, easy to test, have extensive test coverage, have proper dependency injection / be easy to mock the 3rd party dependencies, be easy to configure so it can be deployed in every cloud provider (i.e. by using env vars and config files for modifying its behavior)... and even more important traits.
I'm totally conflicted on the future of computing careers considering LLM impact, but I've worked at a few places and on more than a few projects where few/none of these are met, and I know I'm far from the only one.
I'd wager a large portion of jobs are like this. Majority of roles aren't working on some well-groomed Google project.
Most places aren't writing exquisite examples of a canonically "well-authored" codebase; they're gluing together enterprise CRUD slop to transform data and put it in some other database.
LLMs are often quite good at that. It's impossible to ignore that reality.
If there is one job I don't want to do, it's being responsible for a big heap of enterprise CRUD slop generated and glued together by LLMs. If they can write it, they should learn to maintain it too!
Absolutely. I agree with your take. It's just that I prefer to work in places where products are iterated on and not made once, tweaked twice, and then thrown out. There LLMs are for the moment not very interesting because you have to correct like 50% of the code they generate, ultimately wasting more time and brain energy than writing the thing yourself in the first place.