COMECE a Fazer assim, e vire um ENGENHEIRO DE SOFTWARE!!

Описание: Você vai virar engenheiro de software, ou só pedir código pra IA?

CURSO BASICO DE GOLANG [PUBLICO]:    • Golang Curso Básico  
CURSO COMPLETO DE GOLANG [EXCLUSIVO MEMBROS]:    • GOLANG 2025 | CURSO INTENSIVO  

Junte-se ao clube dev pinguin, para ter acesso antecipado, videos exclusivos e mentoria exclusiva.
   / @lucas_badico  

Neste vídeo eu mostro por que o papel do dev está mudando: menos “cuspidor de código” e mais alguém que sabe pedir direito, revisar e julgar arquitetura. Eu explico por que a IA tende a errar menos sintaxe, mas ainda falha quando precisa entender o contexto da aplicação inteira. Depois eu levo isso pra prática com uma API, mostro o erro clássico de misturar regra de negócio com o web server e como orientar a IA a separar camadas (handlers, services, repositories). Fecho com um exemplo real de como essa arquitetura facilita adicionar um segundo banco sem quebrar tudo.

00:00 - O dev vira engenheiro: pedir, revisar e julgar arquitetura
01:42 - Por que a IA falha em estrutura e contexto de aplicação
04:58 - O erro clássico: tudo misturado no web server
08:35 - A correção: separar camadas e usar adapters
13:28 - Exemplo real: dois bancos e manutenção organizada
21:14 - Fechamento: service vs repository e mentalidade de controle

O novo papel do dev
Eu argumento que o dev vai ser cada vez mais um engenheiro: alguém que sabe construir sistemas e também sabe pedir a coisa certa (pra IA ou pra pessoas) e avaliar se o resultado é bom. Não é só fazer funcionar, é ter estrutura e intenção.

IA não resolve arquitetura sozinha
Eu explico que a IA consegue acertar bem quando o contexto é pequeno (uma função), mas arquitetura depende do sistema inteiro: módulos, responsabilidades e como as partes se comunicam. Sem meu modelo mental, eu aceito coisa “porca” achando que tá ok.

O erro de arquitetura que mais aparece
Eu mostro na prática que a IA pode criar uma API que funciona, mas vem com regra de negócio dentro do web server, acessando banco direto. Eu explico por que isso é ruim: acoplamento, manutenção difícil e pouca liberdade de evoluir.

Como orientar pra ficar profissional
Eu guio a separação em camadas: HTTP como adapter, service como núcleo e repository como interface pro banco. Eu destaco a vantagem de injeção de dependência e como isso deixa as peças substituíveis sem reescrever o sistema.

O exemplo real e a lição final
Eu conto como, seguindo esses princípios, eu consegui adicionar SQLite além do Postgres no meu projeto, mexendo no lugar certo e evitando duplicação do que não precisava. Eu fecho reforçando: comportamento muda no service, dados mudam no repository, e o controle tem que estar na engenharia, não na ferramenta.

Edição: @l.f.porto
Thumbnail: @gasmaskelab