There are two simple answers.
Never stop learning
As an experienced developer, you naturally have some skills already. But what other areas of the industry do you not yet know about?
In my case as an embedded software engineer, I started out knowing a fair bit about C coding. In my first couple of years in industry, I learnt about state machines, bit length and resolution as it applies to fixed and floating point processing, and how to read datasheets to interface micros with other things. At that point I was more valuable than a new hire, because I could do all that on my own.
Moving on, I learnt more about the switches, motors, and other things that could be controlled. So I didn't just know how to make the software work, I knew how to make the system work. New hires from mechatronics knew more about motors and B-H curves than me, but I could put that into a system context and they couldn't.
Moving on from there, I learnt about requirements value, regression testing, safety-related development, and design for test and manufacture. Then I knew how to develop software which was more likely to work first time, and which would remain working and remain testable in case anything went wrong. By now I could easily see some new hires knew more about new chips and new languages than I did - but I was at a point where I could put the whole system together, and they couldn't.
And more recently I've got more heavily into control theory. Now I absolutely know there will be new graduates who can do that better than me - I wasn't really very good at it in uni. If we do hire someone and they can teach me, that's brilliant. But I'll still be a better software engineer than them, because of my experience.
And train the next generation
Engineering isn't a zero-sum game. If there are good new people coming up, share what you know. You can improve your team's efficiency by preventing them falling into traps which you've already seen. This often involves a move to architect level, so you're more likely to be doing the overall design and reviewing than actually directly coding. Embrace this, because engineering a good system is just as valid as cutting code.