Eventually everyone was expected to understand a good deal of the code they were working on. The analyst and the coder became the same person.
I'm deeply skeptical that the kind of people that enjoy software development are the same kind of people that enjoy steering and proofing LLM generated code. Unlike the analyst and the coder, this strike me as a very different skill set.
The real software engineering role, with architecture, customer management, discovery phase, risk analysis and all the other kind of stuff, not yet.
Reading and debugging slop code is not the same thing, not even close.
indeed. people generally hate foreign/alien code, or rather - love their style too much. it is not hard to recognize this pattern - ive seen it with colleagues, with my students, with some topnotch 10x-coders back in the day. so proofing is a skill one perhaps develops by teaching others do things right, but is not something most people entertain about.
on the other hand, people who lack time and patience to implement complex stuff may benefit from this process. particularly if they are good code-readers, and some seasoned devs become such people. i can see little chance they wont be using llms to spit code out.
but the two groups largely don't overlap and are different as astronomers and astronauts.
Not everyone gets to code the next ground breaking algorithm at some R&D department.
Most programming tasks are rather repetitive, and in many countries there is hardly anything to look up to software developers, it is another blue collar job.
And in many cultures if you don't go into management after about five years, usually it is seen as a failure to grow up on their career.
What does that mean?
The mindset, mentality, and culture required to do new software for an ambiguous problem is different from the mentality to produce boilerplate code or maintain an existing codebase. The later is pure execution and the former is more like R&D.
I don't see how that's possible. Wouldn't such a norm result in something like a 7:1 ration of managers to engineers (i.e., assuming a 40ish year career, the first 5 years are spent as an engineer, and the remaining 35 as a manager)? For team managers, I've generally seen around a 1:10 ratio of engineers to managers. So a 7:1 ratio of managers to engineers just doesn't seem plausible, even including non-people leaders in management.
It's these sorts of jobs that will be replaced by AI and a vibe coder, which will cost much less because you don't need as much experience or expertise.