It sounds like your boss subscribes to the idea that software engineering is more like traditional engineering disciplines, where the engineers draw up detailed designs and specifications and hand them to laborers who go off and build the thing. In this idea, the junior engineers are the laborers who take designs and turn them into code while the senior engineers are architects and designers, and maybe even requirements engineers.
However, this model really doesn't hold up. Unlike a skyscraper or a bridge, it's very hard to specify software in models with sufficient detail to actually hand to someone to "crank the wheel" and turn the models into working code. There's the idea that, in software development, code is design. Someone's deep knowledge of programming paradigms, languages, frameworks, and technologies will inform the design of the system that uses those paradigms, languages, frameworks, and technologies.
I believe that the more senior people in an organization should be involved in requirements, architecture, and design, since they are more likely to understand the domain and system under development, and also the tools used to build the system. People who have a senior title are, simply, more experienced and should be able to make better informed decisions that impact the product. However, junior developers learn by doing, so some of their time should be involved in these activities as they progress. There's no other way for them to steadily progress from a junior (coding) role in a senior (design) role.
As you spend more time in an organization or domain and gain more experience, it's likely that you will take on more non-coding activities. But the sharp divide that your boss sees doesn't make much sense to me. In my opinion, entirely removing yourself from the act of coding will eventually make it hard for you to keep up-to-date on the tools and technologies that are used in your product. Your architectural decisions may not be the best in the current landscape, which would have a negative impact on product functionality and quality.
I would recommend checking out the talk "Real Software Engineering" by Glenn Vanderburg. He gave this same talk several times, as well.