And in infra there's figuring out what new approaches you can use to replace stuff in your infrastructure. Then figuring out the migration costs, evaluating its usability, and dealing with a director that's been sweet-talked by a vendor into using some other solution that sucks. Then deciding whether to just build in house b/c none of the solutions quite work and would require additional stuff to build on top. Then when you finally decide on something the back and forth with the vendor because you need to handle some unique thing they hadn't thought of.
The complexity in software engineering is almost never coding. Coding is easy, almost anyone can do it. Some specialized aspects of coding (ultra low latency realtime work, high performance systems, embedded) require deep expertise but otherwise it's rarely hard. It's dealing in ambiguity that's hard.
The hype around GPT-* for coding generally confirms my suspicions that 70+% of folks in software engineering/development are really "programmers" and 30% are actually "engineers" that have to worry about generating requirements, worrying about long term implications, other constraints, etc.
And every time that comes up those folks in the 70% claim that's just a sign of a poorly managed company. Nope. It's good to have these types of conversations. Not having those conversations is the reason a lot of startups find themselves struggling to stay afloat with a limited workforce when they finally start having lots of customers or high profile ones.