Comment by d4mi3n
2 hours ago
I find this to be an incredibly myopic viewpoint. Software engineering is not defined by a single tool or technology, but rather how we design, implement, and maintain processes of value we want to automate or scale.
LLMs will certainly be an aide, but assuming adoption of them is required across a whole _field_ ignores whole classes of problems, domains, and constraints the production of software covers.
Rather, we should be wary of allowing our skills and hard-earned knowledge to atrophy by over reliance on new technology that is far from perfect, reliable, or even universally available. These tools more than any before suffer from the junk-in-junk-out problem and I’d much rather work with someone who knows their fundamentals than someone who knows their way around a the LLM of the month.
On the contrary, taken at face value I find the GP comment to be spot on.
They aren't saying LLM adoption is required across 100% of the field. They are pointing out that LLMs have reached an impressively capable state, and someone insufficiently inclined to test new tooling that they still dismiss LLMs as "just fancy autocomplete" is exactly who gets left behind when technology advances.
Two things can be true at the same time, 1) that LLMs are not required across a whole field, and 2) that software engineers unwilling to acknowledge their utility have as much a place in the future as the software engineers of 50 years ago who refused to use a compiler.
Can you elaborate on how someone would get "left behind"? Isn't the whole point of LLMs that they use natural language and require less effort?
If they're so easy to use, wouldn't the opposite be true? i.e. people who over rely on LLMs become weaker at the core competency? Nobody gives a rat's ass if you did something in an hour or took all night. The deadline is still next week because of all the meetings. What's the point?