Introdução à Engenharia de Software e Arquitetura de Sistemas
Do diff ao deploy: 10 módulos cobrindo terminal, Bash, Git, arquitetura em camadas, APIs, bancos de dados, performance, observabilidade e o impacto da IA generativa em engenharia.
O que você vai construir
Ao final do curso, você terá: vocabulário técnico para conversar com engenheiros sem se perder, intuição para ler diffs em Pull Requests, capacidade de avaliar tradeoffs de arquitetura sem cair em modismos e repertório para escolher a próxima ferramenta com critério, não com hype.
Engenharia de software não é a arte de escrever código. É a disciplina de construir sistemas que continuam funcionando quando o autor original já saiu da empresa, quando a base de usuários cresceu cem vezes e quando o requisito que parecia óbvio em janeiro virou contramão em junho. Programar é uma sub-habilidade. Engenharia é o ofício maior, e quem confunde os dois acaba ou produzindo código brilhante que ninguém consegue manter, ou produzindo entregas medíocres em nome de um pragmatismo mal compreendido.
A distinção clássica formulada por Titus Winters do Google sintetiza bem: 'engenharia de software é programação integrada ao tempo'. Programar é resolver um problema agora. Engenharia é resolver um problema agora de forma que ele continue resolvido em três anos, com outras pessoas mexendo, com a stack mudando ao redor e com a empresa pivotando duas vezes. Os tradeoffs envolvidos não são apenas técnicos -- são econômicos, sociais e cognitivos.
Três conceitos que parecem sinônimos e não são
Código. Texto que um interpretador ou compilador consegue executar. É a matéria-prima. Você pode ter código sem ter software.
Software. Conjunto de código mais artefatos auxiliares (configuração, testes, documentação, dependências) que entrega uma capacidade utilizável. É o produto bruto.
Sistema. Software em operação dentro de um contexto -- com usuários reais, dependências externas, contratos, latência, falhas. É onde o software encontra a realidade. Engenharia de software lida principalmente com sistemas, não com código.
A tríade que governa qualquer projeto
| Eixo | O que controla | Pergunta-chave |
|---|---|---|
| Tempo | Velocidade de entrega, prazo, janela de mercado | Quando precisa estar pronto e por quê? |
| Escopo | Conjunto de funcionalidades, qualidade percebida | O que esse sistema precisa fazer e o que pode esperar? |
| Qualidade | Confiabilidade, performance, manutenibilidade | Quanto custa cada bug que escapar para produção? |
A armadilha do iniciante é querer otimizar os três simultaneamente. A disciplina do engenheiro é escolher conscientemente qual eixo cede em cada decisão. Um MVP de validação cede qualidade em troca de tempo. Um sistema bancário cede tempo em troca de qualidade. Um produto enterprise cede escopo em troca dos outros dois.
Tradeoffs como ofício central. Quase nenhuma decisão de engenharia é binária entre certo e errado -- quase todas são entre dois caminhos com custos diferentes. Postgres ou MongoDB? Monolito ou microsserviços? Server-side rendering ou client-side? REST ou GraphQL? Cada escolha tem custo de manutenção, custo de talento (achar gente que sabe), custo de migração futura. O engenheiro maduro raciocina nesses três planos antes de declarar preferência.
O mecanismo por trás de bons tradeoffs é o segundo derivado: não 'qual é melhor agora', mas 'qual envelhece melhor'. Um stack popular hoje pode estar abandonado em três anos. Um banco de dados marginal pode virar padrão. Boas decisões de engenharia projetam a curva, não apenas o ponto.
O que um engenheiro de software faz no dia a dia
- Lê código mais do que escreve. Estima-se que a proporção em times maduros é de 10 para 1.
- Escreve documentação curta e específica. README, ADR (architecture decision records), runbooks de incidente.
- Participa de revisões de código (Pull Requests) -- comentar PR alheio é metade do trabalho técnico.
- Investiga bugs em produção, com logs, traces e dumps de banco -- nem sempre o erro está onde a stack trace aponta.
- Negocia escopo com produto, prazo com gestão e qualidade com testers. Habilidade política importa.
- Aprende continuamente -- a meia-vida do conhecimento técnico hoje é estimada em três anos.
Faça uma lista das três últimas decisões técnicas que você viu (mesmo de longe -- na sua empresa, em um repositório open-source, em um post técnico). Para cada uma, identifique o tradeoff: o que foi escolhido e o que foi sacrificado. Esse hábito, repetido por seis meses, transforma o jeito de raciocinar sobre sistemas mais do que qualquer livro.
Não confunda complexidade com sofisticação. Sistemas que parecem sofisticados na arquitetura -- microsserviços antes da hora, eventos assíncronos sem necessidade, sete filas de processamento -- frequentemente são apenas complexos. Complexidade é débito que se paga em manutenção, latência e horas de debug. Sofisticação verdadeira é simplicidade defendida com argumento.
Você sabe diferenciar código, software e sistema, conhece a tríade Tempo-Escopo-Qualidade e entende por que tradeoffs explícitos são o coração do ofício -- não a sintaxe da linguagem do mês.
Perguntas frequentes
Preciso saber programar antes deste curso?
Em quanto tempo consigo terminar?
Vou virar engenheiro de software depois disso?
Linux, macOS ou Windows: faz diferença?
Por que começar com diff e bash, e não com uma linguagem?
Este curso ensina IA generativa e Vibecoding?
Alexandre Caramaschi
CEO da Brasil GEO, ex-CMO da Semantix (Nasdaq), cofundador da AI Brasil
Este curso destila o que foi aprendido construindo a infraestrutura da Brasil GEO -- mais de 90% dela escrita em Vibecoding com Claude Code. Engenharia de software em 2026 não é mais sobre dominar uma linguagem; é sobre dominar tradeoffs, especificação e ferramentas. Os 10 módulos formam o repertório mínimo para conversar com qualquer time técnico e tomar decisões com critério.