It is a precarious time to look backwards on the definition of the roles of an IC or an engineering manager and make any extrapolations to what those will look like in the future.

In my own team, I have seen ICs increasingly function like engineering managers, and even suffer some of the pitfalls of the role switch, as they change from reasoning about creating code to delegating to teams of software agents.

Increasingly, ICs are needing to understand the product roadmap more deeply, figure out how to spec a problem and constraints on a solution in the right way to get their subordinates to produce reasonable output, and be the communication bridge between other jobs functions and the entities actually producing the code.

I've also heard concerns of skill atrophy, as these team members spend less brain energy on language syntax, low level logic, etc, and more on interpreting abstract strategies to solving a problem and pattern matching those strategies against their software engineering wisdom.

If anything, ICs should consider that the skills that will make them successful managing agents might be the ones that have made first-level engineering managers successful: the ability to coordinate with other job functions, map implementation strategies to product and organization needs, and deliberately and carefully delegate and coordinate work of others writing the actual code.