GitHub: CI/CD e AI Code Review como portão de qualidade
Velocidade sem qualidade é dívida. Qualidade sem velocidade é estagnação. O jeito que a gente equilibra os dois passa pelo GitHub: todo código que entra na plataforma atravessa um portão onde IA e automação trabalham junto com o time. Este post abre esse portão e mostra o que acontece em cada PR.
A filosofia: portão que protege, não que atrapalha
A ideia não é dificultar o merge. É automatizar o chato (lint, type, formato) e a primeira camada de revisão (IA), pra que o olhar humano sobre o PR fique livre pro que realmente exige julgamento: arquitetura, produto, risco.
O que roda em toda PR para a main
Cada PR dispara automaticamente, só nos pacotes afetados (--filter=...[origin/main]):
| Check | O que faz |
|---|---|
| Lint | Padrão de código nos pacotes afetados |
| Typecheck | TypeScript sem surpresa em runtime |
| Build | Garante que compila de ponta a ponta entre os pacotes |
| Format | Formatação consistente (format:check) |
| AI Code Review | Claude analisa o diff em pt-BR, com severidades critical / warning / suggestion / nitpick |
O AI Code Review é o pulo do gato: ele lê o diff inteiro, aponta bug provável, risco de segurança e inconsistência — e classifica a gravidade pra você saber o que é "tem que arrumar" e o que é "se der".
Como a gente trabalha no fluxo
- Branch + PR sempre. Nada de commit direto na
main. - Nome de branch e commit seguem convenção (ver
CONTRIBUTING.md). - Squash merge e branch deletada automaticamente — histórico limpo.
- Pra mergear: 1 aprovação humana + todos os checks verdes (lint, type, build, format, AI Review).
IA + humano: divisão de trabalho
- A IA pega o óbvio e o sutil que cansa o revisor humano: variável não usada, caso não tratado, tipo frouxo, padrão fora do lugar.
- O humano decide o que importa: essa é a abstração certa? Isso resolve o problema do usuário? Vale a complexidade?
Quando a IA erra (e erra), o humano descarta. Quando o humano cansa (e cansa), a IA não deixa passar o trivial. Um cobre o outro.
Detalhe honesto: o CI às vezes falha por billing
Já aconteceu de job do GitHub Actions falhar em ~2s — e não era o código, era bloqueio de billing da organização. Antes de sair caçando bug no seu PR, vale checar as anotações do run. Transparência também faz parte da cultura de engenharia.
A revisão por IA não substitui o olhar do time — ela libera o time pra revisar o que é arquitetura e produto, não vírgula e import. É assim que dá pra ir rápido sem baixar a barra.
Post-âncora do Módulo 7 da série Vibe Coding. Próximo da série: #39 — Deploy no Google Cloud Run.