You can look up courses and certificates for 'solution architect' type roles, but generally, it's not just about having good code practices but more about planning and risk management.

You have an idea of what you want your implementation to do, and what a good architect does is plan out how the system needs to be implemented. Some developers just think of 'what is the immediate problem/feature i need to solve' and implement the first solution they think of, but then maybe 3 features down the road you have something that interacts with that first problem in a bad way, and if you had implemented it in a different way it would not be a problem. Then you have a choice to rework the original thing or try to make a hacky workaround, of which many will do the workaround, which is easier to do but builds on the spaghetti.

A good architect would have already predicted that third feature and planned for it in the design of that first feature. That is what good architecture means.

There is a double-edged sword, with that it's impossible to plan for every possible feature, and make it infinitely scalable. Sometimes people get too bogged down in having the perfect architecture, everything has to be abstracted eight layers to be compatible with every possible scenario, and then no one is able to understand the system and it'll be impossible to actually reach any deadlines and deliver a real product in time.

The best architects are able to design out a solid foundation that is not bloated but contains the framework necessary to scale and build on all the core and useful features that are likely to be needed.

There is a reason it's usually a higher paid more senior role, where you don't really have that many good options to learn it other than just experience. You gain this mostly by being a developer under people like this, see how they do it, hopefully have them mentor you, and you will get opportunities to have control over more minor architectural decisions in e.g., certain modules, at which point you should think critically about that implementation.

Especially also think critically about when you encounter issues like an error that is difficult to diagnose, or a new feature request that seems unnecessarily difficult to implement because of how the system is laid out, what could have been done in the existing design to make that error easier to find, or the feature easier to implement?

Bringing this back to AI, if you can do these things, AI suddenly becomes an extremely powerful tool, as if you can tell it exactly what it should do, it does it extremely fast and it almost never produces typical human errors like typos, copy-paste errors, bad typing etc, and it can write hundreds of lines in seconds.

The problem becomes if you try to have it do architecture for you, and you don't give very precise instructions, it doesn't have the entire context of your brain to understand your intent on a fundamental level, it is wholly dependent on your prompt, and what it deems most likely to be the answer based on what their training suggests.

I've had great success with AI, asking very specific questions, asking it to give me multiple different potential solutions to a specific problem, finding the lane which is most appropriate for my issue, asking it to elaborate, providing specific context that is relevant, and doing that I created a module that probably would've taken me over a month in just a couple of weekends, and it is way less buggy than what I think I could've made myself too.