The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.

Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself.

A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).

Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.