Shift Your Focus
The things I expect fresh college grads to focus on include basic necessities like formatting, clean style, correctness of functions, unit testing, and understanding code thoroughly at the function and class level. They are still learning more than producing, so helping them focus on things that will improve their quality is generally good. It also means they typically need a lot more guidance when it comes to implementing projects. I am generous with suggestions for design and often senior engineers will be creating designs anyway.
For the next level, I expect an engineer to be able to write solid units of code that are well-encapsulated and interface nicely with other parts of the system. Their focus should be how to ensure that multiple units within an application interact well without leading to spaghetti. The scope of their designs should thus expand to match these expectations. They mostly write application code, but can safely update shared libraries with some oversight.
I expect "senior" engineers to be able to grasp the essential details of an entire service (not necessarily an entire application like an OS or a major standalone desktop app). They should understand how the code works from the function level up to the service startup and dependency level. They should be able to design and build a service competently from scratch, given only a set of requirements (of course, I'm speaking from a primarily SOA/microservice context).
Someone with nearly 10 years in the industry should be an expert. You should be at least a "senior" engineer by most common standards. So what is left? Well, everything.
Those Who Can, Do. Those Who Can't, Teach
Of course, this saying is usually applied to sports and coaching, but there is a grain of truth here for you. If you feel you are burning out on the coding, then spend some time mentoring. If all your coworkers know more than you, including the fresh new junior engineers, then you are clearly not learning as much as you should be. At that point, you should think hard about switching into Project / Program / Product Management. It will be difficult to stay relevant if there is nothing you are more expert in than most of your peers.
If your org hires interns, volunteer to take one under your wing. Do some pair programming. Do code reviews. Don't just critique...explain. Don't just explain...teach. Start out with the areas of code you know the best, where you are most confident and have the most value to share. Then branch out to areas you know less well but still have more experience than most of the team. Even if your org doesn't have interns, there are always junior programmers looking for a mentor. Ask your manager to connect you with one.
There are more important things than just knowing the latest programming language paradigm or faddish framework. There's principles. Design principles. Code quality. Testing. Documentation. Things you do that others on your team don't. Spend some time educating the whole team on why you think those things are important. Preach. Evangelize. These aren't things you can learn by reading a book or participating in a hackathon. They are lessons learned by years of experience and trial and error. Share that knowledge, and it will also grow in your own mind. Don't just tell them the principles. Share your stories, your experiences. That is the value you have built up all this time.
Go Big or Go Home
Returning to the original thread, engineers who are more ambitious will not be satisfied to master a service or two. They will think about the big picture. The architecture of their system. Which services should exist, whether the dependencies are clean or should be refactored. Whether functionality is distributed rationally or has become a Rube Goldberg machine due to poor code maintenance and an unhealthy acceptance of tech debt. Some people call this stage "Architect". I don't like that title, because I personally think that every engineer should put on an architect hat some of the time. I think that whoever designs the top-level architecture of your system should also be actively participating in the building and implementation of said system.
Regardless, this level does not require a focus on the nitty-gritty details of coding. In fact, such a focus can be counter-productive. Engineers hate it when architects tell them how to implement the details of some high-level design like they are fresh college grads. If you are slowing down, then move up. Your brain is getting full (which is why it is hard to stuff more knowledge into it), but that is an asset, not a liability. It means you need to put all the knowledge you have acquired to work. Hopefully, you have been paying attention to and absorbed the high-level architecture of your system. Hopefully, you can identify its strengths and weaknesses, and guide the team on refactorings or future improvements which can produce the most value. If you can leverage your accumulated knowledge to operate at this higher level, you will find that you have learned things which are not easily acquired by reading StackOverflow or the latest programming language manifesto.
When you begin your career, you must focus on the tactics of software engineering. Once you have mastered the tactics, it is time to move to the strategy of it. Of course, many engineers plateau at some senior position and simply choose a work/life balance which lets them focus on the things they really care about, while continuing to sling code to pay the bills. There is nothing wrong with this strategy, either, if it makes you happy.
That being said, architect-like positions are political, and do involve more human interaction than hiding in the corner pumping out pull requests. But often, you can control to what degree this is true, and shape your own destiny by figuring out how to provide value while avoiding confrontation. Sometimes that might mean giving up on an idea that a rival is willing to fight you on. If you back down instead of standing your ground, you can avoid uncomfortable interactions, but you will also lose some standing, unless you can make it up by producing really good work in an uncontroversial area. Also, architects can't just ignore new technology trends. You still need to keep your eyes open and make yourself aware of the latest frameworks, libraries, languages and trends. You just don't need to obsess over the details of them. You need to learn enough to see their strengths and weaknesses: to see what trade-offs they have made. Eventually, you learn that there is nothing new under the sun, and that everything in engineering simply boils down to a different set of trade-offs. Some bring better value than others as the technology landscape shifts, and you need to see and recognize that. But there is no absolute "better" and "worse". It's all relative to what you have now and what is on the horizon.
At the end of the day, your career is what you make of it. No more and no less. Sprinkle in as much or as little coding as you like, depending on how else you can and want to bring value to the team and the company. Figure out where your personal strengths and passions are, and focus on leveraging those, instead of trying to fit yourself into the cookie cutter that HR and management like to apply to the cogs of the machine. Write the ideal job description for where you want to be. One that maximizes the value you can bring to an effort. Then work towards turning your position into that job, by spending more time on the things that matter, and less on the things that don't. You don't need permission to do this. You just need to make it work.