Eu entrei na programação de cabeça no finalzinho de 2022. Não foi um caminho gradual, do tipo "vou dar uma olhadinha e ver se gosto", foi mais um "preciso muito seguir esse caminho" dito em voz alta pra mim mesma. Comecei pelo básico: HTML, CSS, JavaScript.
Fui me aprofundando nos conceitos, caí num bootcamp muito bom do Boticário, daqueles que ainda abriam a porta pra você trabalhar lá dentro (confesso que gostaria de ter aproveitado ainda mais aquela oportunidade), mas foi por ali que consegui meu primeiro emprego e comecei a atuar de fato na área.
E aí começa a parte que eu quero contar de verdade: como eu aprendi a aprender e por que isso mudou completamente.
O aprendizado que eu conheci: Stack Overflow e código Frankenstein
Antigamente, aprender programação era mais ou menos assim: você travava num problema, ia pro Stack Overflow, pesquisava muito e rezava um pai-nosso pra alguém já ter resolvido aquilo antes. Se tivesse resolvido, ótimo. Se não, você improvisava.
O resultado eram códigos meio Frankenstein, feitos de pedaços colados com um toque generoso de lógica de negócio no meio. Funcionava? Funcionava. Era bonito? Nem sempre. Mas foi assim que eu e boa parte de quem começou naquela época aprendeu que essa era a forma de aprender: pesquisar, quebrar a cabeça, testar, errar, repetir.
Esse processo lento tinha um valor escondido que eu só fui entender depois: ele me obrigava a realmente entender o problema. Não dava pra pular etapa.
A chegada da IA e o salto de aprendizado
Aí chegou a inteligência artificial. Comecei a usar ativamente em 2024, e confesso que foi um salto. Ainda não era boa o suficiente pra tudo, mas ali eu percebi uma coisa: eu não precisava mais gastar dias inteiros numa única feature.
Só que teve um detalhe importante. Eu ainda me sentia muito júnior no sentido de que estava aprendendo a pesquisar sobre os meus próprios problemas. E como eu ainda não sabia formular bem o que estava enfrentando, os resultados da IA não eram lá muito expressivos. Porque naquela época, e eu sinto que até hoje, vivências ainda contavam muito. A IA te dá o que você sabe pedir, e eu ainda estava aprendendo a pedir.
Foi aí que caiu a ficha:
Se eu não aprender de verdade, eu não vou conseguir resolver os meus problemas.
A IA não ia me salvar de não entender o que eu estava fazendo. Ela ia, no máximo, acelerar a minha ignorância se eu deixasse.
E foi essa percepção que me fez correr atrás do tempo perdido: buscar conhecimento sobre arquitetura e entender de verdade o negócio em que eu estava atuando na época.
"Mas como eu vou aprender se a IA resolve por mim?"
Essa é a pergunta que eu mais ouço, e a resposta é mais direta do que parece: a IA não resolve.
A IA não tem a capacidade de pensar sobre um problema. Se ninguém pensou nele antes, ela não vai pensar por você, não é assim que ela funciona. Ela é excelente em preencher lacunas, sugerir caminhos, otimizar o que já existe. Mas alguém precisa ter desenhado o problema, entendido a regra de negócio e decidido como aquilo começa e como termina.
E é exatamente por isso que eu acredito que o futuro é sobre arquitetura. Sobre entender como as peças se encaixam antes de escrever a primeira linha. Sobre saber desenhar mentalmente onde o problema nasce e onde você acredita que ele deveria morrer.
As arquiteturas que vale a pena conhecer
Quando eu falo em "estudar arquitetura", não é decorar nome bonito pra impressionar em entrevista. É entender a ideia por trás de cada abordagem, porque cada uma resolve um tipo diferente de dor. Aqui vão as principais que eu acho que todo dev deveria ao menos entender o conceito:
Domain-Driven Design (DDD)
Talvez a que mais combina com o meu ponto. DDD é uma abordagem que coloca o domínio do negócio no centro de tudo. A ideia é que devs e especialistas do negócio falem a mesma língua (a linguagem ubíqua), pra que o código reflita a realidade do problema, e não só a cabeça do programador. Conceitos como bounded contexts, entidades, value objects e agregados servem pra organizar a complexidade do negócio. Se você não entende o negócio, você não faz DDD, e é por isso que ela é tão relevante nesse novo cenário.
Clean Architecture
Popularizada pelo Robert C. Martin (o "Uncle Bob"), a Clean Architecture organiza o sistema em camadas concêntricas. No centro ficam as regras de negócio mais puras; nas bordas, os detalhes como banco de dados, framework e interface. A regra de ouro é a dependency rule: as dependências sempre apontam pra dentro. Na prática, isso significa que sua lógica de negócio não deveria nem saber qual banco de dados você usa. Troca de banco, troca de framework, troca de UI, o coração continua intacto.
Arquitetura Hexagonal (Ports & Adapters)
Prima da Clean Architecture, criada pelo Alistair Cockburn. A ideia é isolar o núcleo da aplicação do mundo externo por meio de ports (interfaces) e adapters (implementações). Quer testar sem banco de verdade? Cria um adapter fake. Quer trocar de serviço externo? Troca só o adapter. O núcleo nem percebe. É maravilhosa pra testabilidade e pra manter o negócio desacoplado da tecnologia.
Arquitetura em Camadas (Layered / N-tier)
A clássica. Divide a aplicação em camadas horizontais: apresentação, aplicação/negócio, persistência e dados. É simples, é fácil de entender e ainda é a porta de entrada de muita gente. Nem tudo precisa ser sofisticado; às vezes a camada bem-feita já resolve.
Arquitetura Orientada a Eventos (Event-Driven)
Aqui os componentes conversam através de eventos, em vez de chamadas diretas. Alguém publica um evento ("pedido criado"), e quem se interessa reage a ele. O grande ganho é o desacoplamento e a escalabilidade: cada parte evolui no seu ritmo e você lida bem com processamento assíncrono. Muito comum em sistemas grandes que precisam aguentar volume.
Microsserviços vs. Monolito
Não é bem uma "arquitetura", é mais uma decisão de organização. No monolito, tudo vive junto numa aplicação só. Nos microsserviços, você quebra a aplicação em serviços pequenos e independentes, cada um cuidando de uma capacidade de negócio. Cada abordagem tem seu preço, e entender quando usar cada uma vale mais do que saber a definição de cor.
Além da arquitetura: entender a própria IA
Estudar arquitetura é metade do caminho. A outra metade, no cenário de hoje, é entender como a IA funciona, não pra virar pesquisadora de machine learning, mas pra usar a ferramenta com consciência.
Um exemplo concreto: entender o que é um token. Modelos de linguagem não leem "palavras", eles processam texto quebrado em pedacinhos chamados tokens. Isso define o tamanho do contexto que o modelo aguenta, influencia custo e explica por que às vezes ele "esquece" o início de uma conversa longa. Saber disso muda a forma como você conversa com a ferramenta e o quanto você consegue extrair dela.
Some a isso o hábito de ler documentação (sério), e usar a IA como aliada justamente nos pontos onde a doc é densa ou o conceito é complexo. Deixa a IA te ajudar a entender e otimizar, não a pular o entendimento. A diferença entre as duas coisas é tudo.
O que eu levo como lição
A forma como eu conheci o aprendizado em 2022 não é a mesma de hoje. E tudo bem, sabe? O que não pode é continuar aprendendo do mesmo jeito e achar que o mercado vai esperar. Se você não otimizar a sua própria forma de aprender, o mercado te engole. É o famoso "alguém já está pensando nisso".
Então a lição que eu deixo é essa:
- Pense em como resolver problemas, não em como copiar soluções prontas.
- Proatividade vai ser a sua melhor amiga nos momentos em que a IA não sabe o que fazer, que são justamente os momentos que definem um bom profissional.
- Você não é burra e nem está pra trás. Não é sobre isso. É sobre entender o que pode melhorar e otimizar sempre.
A IA não veio pra pensar por você. Ela veio pra amplificar quem já sabe pensar. Então continua estudando arquitetura, continua entendendo o negócio, continua desenhando o problema do começo ao fim. O resto é ferramenta.
Espero ter dito algo que te dê algum insight.
Câmbio e desligo.
