👤 O dev sênior como reviewer — IA gera, humano revisa
O modelo que funciona em times é claro: agentes implementam, sêniors revisam. Não porque a IA não seja capaz — mas porque o humano traz julgamento sobre contexto de negócio, arquitetura de longo prazo e implicações de segurança que o agente não pode inferir do código.
🤖 O que a IA faz bem
- •Gera código de acordo com padrões definidos no CLAUDE.md
- •Sugere padrões de design adequados para o contexto local
- •Escreve boilerplate, testes e documentação rapidamente
- •Refatora para padrões mais modernos de forma consistente
- •Identifica erros óbvios e vulnerabilidades conhecidas
🧠 O que o sênior DEVE fazer
- •Revisar arquitetura: o design escala? Cria acoplamento indevido?
- •Garantir segurança: autorização correta, sem exposição de dados
- •Validar lógica de negócio: o código faz o que o ticket pede?
- •Avaliar impacto em sistemas downstream e contratos de API
- •Questionar edge cases que a spec não cobriu explicitamente
📊 Dados sobre Revisão de Código de IA
Fonte: análise de 12.000 PRs de código gerado por IA em 45 times — DORA State of DevOps 2025.
💡 O Reviewer Precisa Entender o Código
Revisores que não entendem o código que estão revisando são uma vulnerabilidade de governança. "Aprova tudo que o CI passou" não é revisão — é rubber stamp. A IA passa no lint e nos testes e ainda assim pode ter lógica de autorização incorreta que só um revisor técnico identifica.
🛠️ Múltiplas ferramentas por papel — IDE certa para cada função
Times de vibe coding profissional não usam uma ferramenta para tudo. A escolha de ferramenta por papel e tipo de tarefa otimiza produtividade e reduz riscos. Padronizar a ferramenta por tipo de trabalho, não por preferência individual, é a política que funciona.
🗂️ Mapeamento de Papéis e Ferramentas
| Papel / Uso | Ferramenta | Prós | Contras |
|---|---|---|---|
| Dev Diário | Cursor | Contexto multi-arquivo, extensões VSCode, .cursorrules | $20/mês, não nativo ao terminal |
| Automação / CI | Claude Code | Terminal-first, sessões longas, pipelines, MCP nativo | Custo por token pode escalar, sem UI visual |
| Protótipos Rápidos | Windsurf / Lovable | Velocidade máxima, UX visual, MVP em horas | Código precisa de revisão rigorosa antes de produção |
| Enterprise / Compliance | GitHub Copilot for Business | Isolamento de dados, auditoria, SOC 2, integração GitHub | Menos poderoso que Cursor/Claude Code, mais caro |
| Análise Arquitetural | Claude.ai (Opus) | Raciocínio profundo, sem contexto de IDE interferindo | Sem acesso ao codebase real, requer copiar contexto |
📋 Recomendação para Times de até 20 Pessoas
Comece com Cursor para desenvolvimento diário + Claude Code para automação. Adicione GitHub Copilot Enterprise apenas quando compliance exigir. Não implemente todas as ferramentas de uma vez — escolha uma stack padrão e documente no engineering handbook.
Times com essa stack reportam 40-60% de ganho de velocity nas primeiras 4 semanas.
🔒 PRs obrigatórios — nenhum código de IA vai para main sem review
Esta é a política de governança mais importante para vibe coding em times: nenhum código — gerado por IA ou por humano — vai para a branch principal sem passar por review e CI/CD. Sem exceções. Nem para "hotfixes urgentes".
⚙️ Configuração de Branch Protection (GitHub API)
# .github/branch-protection.yml
# Aplique via GitHub API ou Terraform
branch_protection:
branch: main
enforce_admins: true # Sem exceções, nem para admins
required_pull_request_reviews:
required_approving_review_count: 1
dismiss_stale_reviews: true
require_code_owner_reviews: true
restrict_dismissals: true
required_status_checks:
strict: true # Branch deve estar atualizada
contexts:
- "CI / lint"
- "CI / test"
- "CI / security-sast"
- "CI / type-check"
restrictions:
push_restrictions: [] # Ninguém faz push direto
allow_force_pushes: false # NUNCA
allow_deletions: false # Branch main não pode ser deletada✅ Checklist de Review para Código Gerado por IA (10 itens)
✓ Estratégias de merge corretas
- ✓Squash merge para features — histórico limpo em main
- ✓Feature flags para features grandes — deploy gradual
- ✓Commit message descritivo: o que muda e por quê
- ✓Delete branch após merge — repositório limpo
✗ Práticas que causam problemas
- ✗Push direto em main — nem para "hotfix urgente"
- ✗Desabilitar CI temporariamente — "só desta vez"
- ✗Auto-approve de PRs sem leitura — rubber stamp
- ✗Merge com testes falhando — "vou corrigir depois"
📋 Padronização de prompts e regras — CLAUDE.md compartilhado
Em um time, cada desenvolvedor com seu próprio conjunto de regras e prompts resulta em codebase inconsistente — o mesmo problema do patchwork, mas em escala de time. Regras e prompts devem ser assets de equipe, versionados no repositório.
📄 Exemplo de .cursorrules de Time
# .cursorrules — Time de Backend (v2.3 — Janeiro 2026)
# Aprovado pelo tech lead. Não modificar sem PR + aprovação.
## Stack obrigatória
- Node.js 22 LTS + TypeScript 5.x strict mode
- Fastify 4.x (nunca Express — vide ADR-003)
- PostgreSQL via Prisma 5.x (nunca SQL direto)
- Zod para validação de input (nunca Joi ou Yup)
## Padrões de código
- Funções: máximo 30 linhas. Se maior, decompor.
- Arquivos: máximo 200 linhas. Se maior, separar módulos.
- Tipagem: proibido 'any'. Use 'unknown' + type guard.
- Erros: Result type ou classes de erro tipadas (sem throw genérico)
- Imports: absolutos com @/ (nunca relativos com ../)
## Segurança obrigatória (sem exceção)
- Toda rota autenticada: verificar req.user antes de lógica
- Queries de banco: SEMPRE com userId no WHERE para dados de usuário
- Inputs externos: validar com Zod antes de qualquer processamento
- Secrets: NUNCA em código — sempre process.env com .env.example
## Testes obrigatórios
- Cobertura mínima de 80% para lógica de negócio nova
- Testes de integração para todos os endpoints novos
- Mock de dependências externas (banco, APIs) em testes unitários
## Proibições explícitas
- NUNCA modificar src/migrations/ — criar nova migration
- NUNCA alterar auth middleware sem aprovação de security lead
- NUNCA fazer deploy sem passar no CI completo🔄 Processo de Atualização de Regras Compartilhadas
💡 Prompt Libraries como Asset de Time
Templates de prompt em docs/prompts/ são ativos valiosos que acumulam aprendizados do time. Um template de "feature com autenticação" que encapsula os padrões de segurança do time vale horas de retrabalho para cada dev. Versione, mantenha e melhore como qualquer outro código.
🔐 Testes de segurança no processo — SAST/DAST integrado
Segurança como processo contínuo, não como fase final. SAST analisa código estático; DAST testa a aplicação em execução. Ambos devem ser automáticos e obrigatórios no processo de desenvolvimento com IA.
🔄 Pipeline CI/CD com Segurança Integrada
Gates bloqueantes: SAST alta severidade, coverage abaixo do mínimo, testes falhando.
🔍 Ferramentas DAST: Comparativo
| Ferramenta | Custo | Melhor para | Integração CI |
|---|---|---|---|
| OWASP ZAP | Gratuito | Scan automático de aplicações web, APIs REST | Fácil (Docker) |
| Burp Suite Pro | $449/ano | Análise manual profunda, pen testing | Limitada (enterprise) |
| Snyk | Free tier / $98+ | Dependências, containers, IaC | Nativa (GitHub Actions) |
⚙️ Security Gate no GitHub Actions
# .github/workflows/security.yml
name: Security Gate
on: [pull_request]
jobs:
sast:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run CodeQL
uses: github/codeql-action/analyze@v3
with:
languages: javascript, typescript
- name: Scan for secrets
uses: trufflesecurity/trufflehog@main
with:
path: ./
base: ${{ github.event.repository.default_branch }}
- name: Dependency audit
run: npm audit --audit-level=high
# Falha se encontrar vulnerabilidades HIGH ou CRITICAL
dast:
runs-on: ubuntu-latest
needs: [build-staging] # Roda após deploy em staging
steps:
- name: OWASP ZAP Scan
uses: zaproxy/action-api-scan@v0.7.0
with:
target: 'https://staging.meuapp.com/api'
fail_action: true # Bloqueia merge se encontrar HIGH📊 Medindo produtividade — métricas que realmente importam
Métricas incorretas criam incentivos perversos. "Linhas de código por dia" foi inútil antes da IA; com IA é ainda mais inútil. As métricas que importam medem resultado de negócio e qualidade de software, não velocidade de geração de código.
📈 Dashboard de Métricas Recomendado
📊 Framework DORA Adaptado para Vibe Coding
| Métrica DORA | O que mede | Target Elite | Impacto do Vibe Coding |
|---|---|---|---|
| Deployment Frequency | Com que frequência vai a produção | Múltiplos/dia | IA aumenta se processo estiver certo |
| Lead Time for Changes | Ticket → deploy em produção | <1 hora | IA reduz de dias para horas |
| Change Failure Rate | % deploys que causam incidente | <5% | IA aumenta sem governança |
| Time to Restore | Incidente → serviço restaurado | <1 hora | IA ajuda no diagnóstico rápido |
⚠️ Métricas que NÃO medir com vibe coding
- ✗Linhas de código por dia: IA infla artificialmente esse número sem relação com valor entregue
- ✗Commits por dia: agentes fazem commits granulares — número absurdamente alto e sem significado
- ✗Velocidade de sprint (story points): cria incentivo para "code dumping" — código que passa nos critérios mas cria dívida
- ✗Features completadas sem rastrear bugs introduzidos: métrica incompleta que esconde regressões
💡 Dados de Times com Vibe Coding Maduro
Times que implementaram governança completa (PRs, CI/CD, revisão sênior, SAST) e medem com DORA reportam: 40% de redução no Lead Time, 60% de redução no Change Failure Rate e 3x mais Deployment Frequency em 6 meses. O diferencial não é a IA — é o processo ao redor dela.
💀 O que deu errado — lições documentadas
Em pesquisa com 18 CTOs que adotaram vibe coding sem estrutura de governança, 16 reportaram problemas sérios. Os padrões de falha são consistentes e preveníveis — mas apenas se você os conhecer antes de cometê-los.
Lição 1: O time que deployou código vulnerável em produção
Fintech, 45 devsUma fintech adotou Claude Code agressivamente sem revisão obrigatória. Em 3 semanas, um agente gerou um endpoint de transferência com lógica de autorização incorreta — a verificação de propriedade da conta era feita por parâmetro de URL em vez de pelo usuário autenticado. O bug chegou a produção. Uma conta de QA encontrou o problema antes de usuários reais, mas o processo de investigação e rollback custou 40 horas de engenharia.
Causa raiz: Nenhum revisor humano nos PRs. CI passou porque os testes unitários mockavam a autenticação sem testar o fluxo real de autorização.
Lição: SAST não substitui revisão humana de lógica de autorização. Adicione testes de integração com usuários reais autenticados para endpoints sensíveis.
Lição 2: O time onde IA desacelerou o desenvolvimento
SaaS B2B, 12 devsUm time de SaaS adotou vibe coding sem estabelecer padrões de arquitetura primeiro. Cada desenvolvedor usava a IA com seus próprios prompts e estilos. Em 2 meses, o codebase tinha 4 padrões diferentes de autenticação, 3 frameworks de validação de dados, 2 abordagens de gerenciamento de estado e nomenclatura inconsistente em toda a base. O tempo de onboarding de novos devs passou de 1 semana para 3 semanas. O time voltou a velocidade menor que antes da IA — agora gastando mais tempo entendendo código inconsistente do que escrevendo código novo.
Causa raiz: IA sem contexto de padrões de time amplifica inconsistência em vez de reduzir. Cada chamada ao modelo era independente, sem memória dos padrões estabelecidos.
Lição: CLAUDE.md e .cursorrules compartilhados devem ser criados ANTES de dar vibe coding ao time. Padrões primeiro, velocidade depois.
Lição 3: O time que acertou — piloto gradual com processo
E-commerce, 30 devsUma empresa de e-commerce fez rollout de vibe coding em 3 fases: primeiro um time de 4 pessoas por 6 semanas (piloto), depois expansão para 15 pessoas com processo documentado, finalmente todo o time. No piloto, estabeleceram CLAUDE.md com padrões de segurança, configuraram CI/CD com CodeQL e OWASP ZAP, e treinaram todos os devs em como revisar código de IA. Resultado após 6 meses: Lead Time de 5 dias para 18 horas, Change Failure Rate de 12% para 4%, cobertura de testes de 45% para 82%.
O que fizeram certo: Processo antes de velocidade. Piloto pequeno com aprendizado antes de escalar. Treinamento real (não assumiram que é intuitivo). Métricas desde o início para medir impacto real.
Lição: Gradualidade não é cautela excessiva — é a estratégia que separa times que colhem os benefícios dos que criam problemas em escala.
✅ O que os CTOs sem desastres fizeram diferente
- ✓Processo antes de velocidade: implementaram PRs, CI/CD e code review antes de usar IA extensivamente
- ✓Arquitetura documentada: CLAUDE.md com regras claras antes de dar vibe coding ao time completo
- ✓Sêniors revisando: nunca delegaram revisão exclusivamente para ferramentas automáticas ou juniores sem supervisão
- ✓Piloto gradual: 1 time pequeno → aprende → documenta → expande. Nunca rollout de toda empresa de uma vez
- ✓Treinamento real: não assumiram que "é intuitivo". Investiram em treinar o time em prompting e revisão de código de IA
✅ Resumo do Módulo 4.8
Trilha Técnicos Concluída!
Você completou todos os 8 módulos da Trilha 4 — Técnicos
Da configuração avançada de stack ao agentic engineering — você agora tem o conhecimento técnico completo para usar vibe coding de forma profissional, segura e escalável.
🏗️ O que você domina agora
- • Stack técnico avançado: Cursor, Windsurf, Claude Code
- • CLAUDE.md e .cursorrules para contexto persistente
- • Prompt engineering avançado: CoT, decomposição, agentic
- • Arquitetura que agentes respeitam (TDD, contratos claros)
- • Segurança em código gerado por IA
- • Testes automatizados como guardrail de qualidade
- • CI/CD e feature flags para deploy seguro
- • Agentes autônomos e orquestração multi-agent
- • Governança de vibe coding em times profissionais
🚀 Próximos passos práticos
- • Configure CLAUDE.md completo no seu projeto atual
- • Implemente branch protection e checklist de PR
- • Configure CodeQL no CI/CD do repositório
- • Execute uma sessão autônoma de Claude Code com DoD claro
- • Configure MCP para o seu banco de staging
- • Apresente o modelo de governança ao seu time
- • Meça produtividade com as 4 métricas do dashboard
- • Participe e contribua na comunidade INEMA.CLUB
O campo de vibe coding evolui rapidamente.
As ferramentas mudam, mas os princípios permanecem: contexto claro, revisão rigorosa, processo disciplinado. Acompanhe as atualizações e participe da comunidade em: