When I look back at what I learned most from, I have to say CSS during the time my company was still supporting old Internet Explorer versions. There was something about this really limited set of possibilities where you had to think outside the box to achieve what you wanted. And no, I don't want those times back. But today, where AI takes over simple coding tasks, learning through these seemingly easy tasks is totally missing. How am I supposed to learn what a good API on a large scale looks like, if I never had the opportunity to build one on the small scale. Seeing a component grow in complexity, and having to change its API, is a great playground — you learn what matters in an API, and what breaks when you change it across every place it's used. The difference is: you might introduce a design glitch or a small bug, whereas playing around with a complex production REST API might lead to much more severe consequences. And it is this small scale practice, that AI removes from developers starting out right now.
It is easy to dismiss this problem and even use it as an advantage: less competition opens the market, people get irreplaceable and can get a raise out of that. But for me, more senior development roles - be it the senior developer, a staff engineer or a tech lead, whatever the roles are called in your company and even if the role doesn't have a specific name - always had the responsibility of mentoring younger, less experienced developers. It has always been my responsibility to not only keep a team running, but to make it better, to make me replaceable by anyone who is part of that team.
And while it might be annoying for all parties, that means looking into merge requests even if you are not part of the review process. Make yourself part of it and see where problems might occur. Understand where your developers have problems, and ask the right questions so that they have to argue for their code (yes, even though AI wrote it, the code ownership should still stay with the developer) and by extension think about what they are committing to the code base.
Understanding where other developers have problems, isn't as easy as it sounds. When you grow and acquire knowledge, you lose track of what was hard for you, or what might be hard for others. You might look at a PR and wonder why someone would write this. It takes time to realise, that not everything you know is as easy to understand as you think. Assuming basic concepts are common knowledge might be right in a lot of cases but it isn't right in all of them, and people differ in what they already know and what they don't, they might be familiar with one concept but totally lack others, they might even think they understand it, but in the end have a wrong idea of what it actually means. And by reviewing other people's code, you get better at explaining, you get better at understanding others and you might even find yourself in a situation where you might not understand a concept yourself. Because explaining to someone else is a great way of identifying missing knowledge.
This is why the right approach to code reviews is so important. Just presenting alternative solutions might be a convenient approach but often isn't enough. Doing a code review right and asking the right questions can open new perspectives on code and most importantly it can
show you and all the people involved where their lack of knowledge is. And that's how you build a future-proof team, not only by delivering new features, but being a mentor to developers with less experience. The easy problems that used to teach us are disappearing. But the teaching still needs to happen.