Excelente reflexão, Vini.
Você tocou exatamente na ferida mais profunda e assustadora da nossa área hoje.

Sabe qual é o maior perigo dessa era de frameworks consolidados, separação limpa de camadas e, agora, IAs gerando soluções prontas? É que vocês foram inseridos em uma realidade onde o "como fazer" foi totalmente automatizado, mas o "por que fazer" foi esquecido.

Quando eu comecei era o BASIC, passei pelo C++, Java, Visual Basic e depois eu me encontrei na web com ASP Clássico (que era um framework da microsoft) que usava predominantemente o VBScript (baseado no Visual Basic) em conjunto com HTML. Fui para o PHP e voltei para o C# (evolução do antigo Asp clássico da plataforma .NET) e um pouco de Swift, que depois foi substituindo pelo Objective-C. Aqui não tinha framework, você precisava entender o que passava pela veia do sistema e o que comunicava com as outras partes do seu código.

Os frameworks vieram bem depois, sempre foram úteis para resolver algum problema. Mas não aprender os paradigmas basilares tem seus trade-offs, como tudo na vida. O framework já resolve problemas que não precisa se preocupar em resolver, mas quando existe um problema profundo vai ser no conhecimento da raiz que vai entender como resolve-los. Entende?

Quando eu comecei, lá nos anos 80, a gente não tinha o luxo de errar sem pagar um preço altíssimo. Se você errasse a modelagem de um banco ou a estrutura de um loop, o sistema inteiro travava, o cliente perdia dados e você passava três a cinco noites sem dormir escovando bit para consertar. A gente aprendia na dor física e mental do prejuízo. Era brutal! Hoje, a IA cospe um boilerplate limpinho, com Docker configurado, padrões de projeto aplicados e, se funcionar no primeiro teste, o desenvolvedor dá git push e segue a vida. É vraaau!

Hoje você vira refém dos resultados porque a IA te entrega o destino final sem te mostrar o mapa da viagem. Não pegou um atalho (que já é ruim), você é teletransportado direto para o fim.

Dizer "é preciso sentir a ausência dos padrões para entender por que eles existem" é o caminho da razão. A teoria dos livros é linda, mas ela só faz sentido quando você olha para uma linha de código tenebrosa e pensa: "Caramba, se eu aplicar o padrão X aqui, eu resolvo essa bagunça".

Como você não tem tempo (e nem quer) ver a empresa onde trabalha falir só para aprender errando, você precisa induzir o erro de forma controlada. Se você quer mesmo sair do risco de cair no balaio da mediocridade e parar de aceitar o "aceitável" da IA para dominar a arquitetura na prática, mude sua postura com algumas atitudes:

1 - Inverta o jogo com a IA com engenharia reversa. Quando ela te der uma solução que funciona, questione os pontos fracos. Pergunte o "Por que essa estrutura e não a X?", "Onde essa arquitetura quebra se o volume de dados triplicar?" ou "Quais são os trade-offs dessa escolha?". Force a máquina a te ensinar os fundamentos. Exija que ela explore os riscos, as limitações e as brechas que podem se abrir principalmente no quesito segurança.

2 - Abrace o código ruim (o legado). Os livros dão a teoria, mas o aprendizado real vem do atrito. Peça para mexer naquele sistema antigo e problemático da empresa que todo mundo tem medo. Tentar refatorar ou isolar uma regra de negócio em um código macarrônico vai te ensinar mais sobre padrões de projeto do que mil páginas lidas. O importante vai ser entender como conseguiu dar cada passo, sem atalhos, para construir uma solução para o problema x.

3 - Sempre provoque o erro controlado. No seu ambiente local ou num docker, monte um projeto simples misturando tudo, o banco de dados, o front, a lógica no controller. Tente evoluir esse sistema. Quando você sentir a dor real da manutenção difícil, reescreva do jeito certo. A diferença vai fixar na sua cabeça para sempre. E lógico, chame seu techlead ou um dev senior para acompanhar o que fez localmente e apresente sua solução. Geralmente o tiozão cansado não viu o que viu e rola até um upgrade na carreira.

A IA é uma excelente assistente, mas uma péssima mentora se você for passivo. Não seja apenas um "aprovador de código". Quem domina a base e entende o ecossistema é quem dita as regras do jogo e. vai mais longe, ganha mais e cresce.

Sucesso na sua jornada!