The only thing I can think of is to ask the AI "why this instead of that?"
Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.
Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.
For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.
Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).
What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.
In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.
I enjoyed a lot reading the book and also learned a few things there: The Pragmatic Programmer, 20th Anniversary Edition. The main guiding principle: Good design is easier to change than bad design
These are available to read completely free online, but I do plan to purchase the physical books some day.
[edit] I realize that I should probably give more context to my answer. The books on the site are basically interviews with the authors of the software and they discuss what choices they made as well as the advantages/tradeoffs of this approach. In other words, the direct answer to your question is to learn by reading what other people have written about their own successes and glean from that.
[edit 2] Your favorite LLM could also provide a list of books that are similar in spirit, but there's just something about the series that I linked to that I like.
I have been programming long before LLMs, and it was painfully slow, but the lessons stayed with me for a long time, and after some time I was able to spot architectural problems before they became problems, because I suffered many times before.
When I'm building with AI now, it's much faster, yeah, but it's extremely difficult to learn these patterns, so I feel like slowing down the pace when working with LLMs (although very difficult), and researching things properly will allow you to develop these muscles, and bring benefits in the long run.
Learning programming languages that have been well designed is helpful. I suggest Programming Erlang: Software for a Concurrent World and Elixir in Action.
The only thing I can think of is to ask the AI "why this instead of that?"
Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.
Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.
For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.
Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).
What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.
In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.
I enjoyed a lot reading the book and also learned a few things there: The Pragmatic Programmer, 20th Anniversary Edition. The main guiding principle: Good design is easier to change than bad design
https://aosabook.org/en/
These are available to read completely free online, but I do plan to purchase the physical books some day.
[edit] I realize that I should probably give more context to my answer. The books on the site are basically interviews with the authors of the software and they discuss what choices they made as well as the advantages/tradeoffs of this approach. In other words, the direct answer to your question is to learn by reading what other people have written about their own successes and glean from that.
[edit 2] Your favorite LLM could also provide a list of books that are similar in spirit, but there's just something about the series that I linked to that I like.
I have been programming long before LLMs, and it was painfully slow, but the lessons stayed with me for a long time, and after some time I was able to spot architectural problems before they became problems, because I suffered many times before.
When I'm building with AI now, it's much faster, yeah, but it's extremely difficult to learn these patterns, so I feel like slowing down the pace when working with LLMs (although very difficult), and researching things properly will allow you to develop these muscles, and bring benefits in the long run.
often recommended are https://htdp.org and SICP (https://en.wikipedia.org/wiki/Structure_and_Interpretation_o... ?)
There are a lot of good books here: https://pragprog.com/categories/architecture-design-and-test...
I second the comment (https://news.ycombinator.com/item?id=48327571) recommending How to Design Programs (HTDP) and Structure and Interpretation of Computer Programs (SICP). The former has an edX course (https://www.edx.org/learn/coding/university-of-british-colum... and https://www.edx.org/learn/coding/university-of-british-colum...) and the latter has online lectures (https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CAB...)
Head First Architecture (https://www.amazon.com/Head-First-Software-Architecture-Arch...) is good.
Reading about systems thinking would be useful.
Learning programming languages that have been well designed is helpful. I suggest Programming Erlang: Software for a Concurrent World and Elixir in Action.