⚙️ Por que CI/CD é ainda mais importante com vibe coding
Em desenvolvimento tradicional, CI/CD captura bugs que humanos introduzem por descuido. Em vibe coding, CI/CD captura bugs que agentes introduzem por falta de contexto ou instrução ambígua. O pipeline é a verificação objetiva que o agente não consegue fazer por si mesmo — e sem ele, cada push é uma aposta.
✗ Sem CI/CD — o que pode acontecer
- •Agente faz push com TypeScript errors não percebidos
- •Testes quebram silenciosamente após refactoring
- •Vulnerabilidade de segurança vai direto para produção
- •Build falha em produção por falta de variável de ambiente
- •Bug sutil descoberto por usuário 3 dias após o deploy
✓ Com CI/CD — o que é capturado automaticamente
- •TypeScript errors e violações de lint no PR
- •Regressões detectadas antes do merge
- •Padrões de vulnerabilidade bloqueados pelo SAST
- •Build verificado em ambiente limpo e isolado
- •Deploy só ocorre após todos os gates passarem
📊 Taxa de Escape de Bugs — Com vs. Sem CI/CD em Projetos de Vibe Coding
Estimativa baseada em análise de projetos com Claude Code (2025)
💡 O Pipeline como Segundo Revisor
Pense no CI/CD como um revisor de código que nunca cansa, nunca esquece um check e nunca aprova código que quebra testes. Para equipes de vibe coding, o pipeline é o segundo par de olhos mais confiável — diferentemente do humano, ele executa os mesmos checks toda vez, sem variação.
⚙️ GitHub Actions — workflow completo gerado por IA
O GitHub Actions é a ferramenta padrão de CI/CD para projetos de vibe coding por integrar nativamente com o repositório, ser gratuito para projetos privados (2.000 min/mês) e ser facilmente gerado por IA. Peça para o agente criar o workflow completo — de lint a deploy.
⚙️ Workflow Completo para Projeto de Vibe Coding
Lint + Type check + Testes + Cobertura + SAST + Deploy — tudo em um arquivo
# .github/workflows/ci.yml
name: CI/CD Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
# JOB 1: Qualidade de código
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm' # Cache de dependências — builds 3x mais rápidos
- run: npm ci # Instala dependências de forma determinística
- name: Lint e formatação
run: npm run lint # ESLint + Prettier check
- name: TypeScript type check
run: npx tsc --noEmit # Verifica tipos sem gerar arquivos
- name: Testes unitários + integração
run: npm run test:coverage
env:
DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}
NODE_ENV: test
- name: Upload cobertura para Codecov
uses: codecov/codecov-action@v4
with:
token: ${{ secrets.CODECOV_TOKEN }}
fail_ci_if_error: true # Falha se cobertura abaixo do threshold
# JOB 2: Segurança (roda em paralelo com quality)
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Semgrep SAST
uses: semgrep/semgrep-action@v1
with:
config: >-
p/security-audit
p/secrets
p/owasp-top-ten
p/javascript
# JOB 3: Deploy (só roda se quality E security passarem)
deploy:
needs: [quality, security] # Gates obrigatórios
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
steps:
- uses: actions/checkout@v4
- name: Deploy to Vercel (produção)
run: npx vercel --prod --token=${{ secrets.VERCEL_TOKEN }}
env:
VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
- name: Notificar Sentry do novo deploy
run: |
curl -X POST "https://sentry.io/api/0/organizations/${{ secrets.SENTRY_ORG }}/releases/" \
-H "Authorization: Bearer ${{ secrets.SENTRY_AUTH_TOKEN }}" \
-d '{"version": "${{ github.sha }}", "projects": ["${{ secrets.SENTRY_PROJECT }}"]}'
📋 Prompt para Gerar Este Workflow
"Crie um GitHub Actions workflow completo para meu projeto.
Stack: Node.js 22 + TypeScript + Vitest + Vercel
Requisitos:
- Job 'quality': lint (ESLint), type check (tsc), tests com cobertura (Vitest),
upload para Codecov
- Job 'security': Semgrep com p/security-audit, p/secrets, p/owasp-top-ten
- Job 'deploy': Vercel prod, só em push para main, requer quality E security
- Notificar Sentry de novo deploy após deploy bem-sucedido
- Cache de npm para builds rápidos
- Usar secrets para tokens e URLs de banco
Crie o arquivo em .github/workflows/ci.yml"
🔍 SAST no pipeline — análise de segurança em cada PR
SAST (Static Application Security Testing) no pipeline transforma segurança de uma fase final para um processo contínuo. Código gerado por IA pode replicar padrões inseguros conhecidos — SAST os detecta antes de qualquer código chegar à produção.
🔍 Adicionando Snyk + Semgrep ao Pipeline
# Adicione ao job 'security' no ci.yml existente:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# Semgrep: padrões de código inseguro (OWASP, secrets)
- name: Semgrep SAST
uses: semgrep/semgrep-action@v1
with:
config: >-
p/security-audit
p/secrets
p/owasp-top-ten
p/javascript
env:
SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}
# Snyk: vulnerabilidades em dependências (npm packages)
- name: Snyk — dependências vulneráveis
uses: snyk/actions/node@master
with:
args: --severity-threshold=high # só bloqueia HIGH e CRITICAL
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
# CodeQL: análise profunda de fluxo de dados (GitHub nativo, gratuito)
- uses: github/codeql-action/init@v3
with:
languages: javascript-typescript
queries: security-extended
- uses: github/codeql-action/analyze@v3
📊 O Que é Detectado em Cada Estágio
| Ferramenta | Detecta | Quando |
|---|---|---|
| ESLint + no-eval, no-new-func | Uso de eval(), injeção via string | Em cada PR (job quality) |
| Semgrep p/secrets | API keys, tokens hardcoded no código | Em cada PR (job security) |
| Semgrep p/owasp-top-ten | SQLi, XSS, path traversal, SSRF | Em cada PR (job security) |
| Snyk | CVEs em dependências npm | Em cada PR (job security) |
| CodeQL | Fluxos de dados inseguros entre arquivos | No merge para main |
⚠️ Não Bloqueie Deploys com Falsos Positivos
SAST tem falsos positivos. Se você configurar todas as ferramentas como bloqueadoras estritas, sua equipe vai começar a suprimir alertas em massa — destruindo o valor do sistema. Estratégia recomendada:
- •Semgrep p/secrets: sempre bloqueador — segredos hardcoded são inaceitáveis
- •Snyk HIGH/CRITICAL: bloqueador — dependências com CVE grave não devem ir para prod
- •CodeQL e Semgrep geral: alertas visíveis, mas não bloqueadores no PR — revise semanalmente
🚀 Deploy automático com Vercel/Railway
Vercel e Railway são as plataformas de deploy padrão para projetos de vibe coding por sua integração nativa com GitHub, zero configuração de infraestrutura e deploy automático a cada push. Cada merge em main dispara deploy automático — sem intervenção humana.
Vercel — 3 Passos para Deploy Automático
Conectar repositório
vercel.com → "Add New Project" → selecionar repo GitHub → Next.js/Vite detectado automaticamente
Configurar variáveis de ambiente
Settings → Environment Variables → adicionar DATABASE_URL, NEXTAUTH_SECRET, etc. para Production e Preview
Deploy automático ativado
Cada push para main = deploy de produção. Cada PR = preview deploy com URL única para revisão.
Railway — 3 Passos para APIs e Workers
Criar projeto com template
railway.app → "New Project" → Deploy from GitHub repo → Railway detecta Node.js e cria Dockerfile automaticamente
Adicionar PostgreSQL e Redis
New Service → PostgreSQL → Railway injeta DATABASE_URL automaticamente no ambiente. Redis da mesma forma.
Configurar health check
Settings → Deploy → Health Check Path: /health. Railway valida que app está saudável antes de trocar o tráfego.
📊 Vercel vs. Railway — Quando Usar Cada Um
| Critério | Vercel | Railway |
|---|---|---|
| Melhor para | Frontend, Next.js, Edge Functions | APIs Node.js, workers, microserviços |
| Banco de dados | Use Supabase/Neon externo | PostgreSQL + Redis nativos |
| Preview deploys | Automático por PR — cada PR ganha URL | Configurável por ambiente |
| Processos long-running | Não (serverless apenas) | Sim, containers persistentes |
| Plano gratuito | Hobby: 100GB banda/mês | Trial: $5 crédito único |
| Custo estimado (produção) | $20/mês (Pro) | $5-15/mês (Hobby/Pro) |
🚩 Feature flags — liberando código de IA gradualmente
Feature flags permitem deploar código de IA em produção mas ativá-lo apenas para subconjuntos controlados de usuários. Se algo der errado, você desliga o flag sem rollback de código. É a estratégia de release mais segura para vibe coding — especialmente para features críticas.
🚩 Implementação de Feature Flag em TypeScript
// src/lib/feature-flags.ts
type UserId = string;
interface FeatureFlags {
newCheckoutFlow: boolean;
aiRecommendations: boolean;
betaDashboard: boolean;
}
// Flags simples por variável de ambiente (rollout global on/off)
export const flags: FeatureFlags = {
newCheckoutFlow: process.env.FF_NEW_CHECKOUT === 'true',
aiRecommendations: process.env.FF_AI_RECS === 'true',
betaDashboard: process.env.FF_BETA_DASHBOARD === 'true',
};
// Flags com rollout percentual (por userId)
export function isInRollout(userId: UserId, flagName: string, percent: number): boolean {
// Hash determinístico: mesmo user sempre cai no mesmo grupo
const hash = userId.split('').reduce((acc, c) => acc + c.charCodeAt(0), 0);
return (hash % 100) < percent;
}
// Uso no componente / handler
export function getCheckoutComponent(userId: UserId) {
if (flags.newCheckoutFlow && isInRollout(userId, 'newCheckout', 25)) {
return NewCheckout; // 25% dos usuários veem o novo checkout
}
return OldCheckout;
}
📋 Prompt para Adicionar Feature Flags a uma Feature Existente
"Adicione feature flag para o novo fluxo de checkout.
@src/pages/checkout.tsx
@src/lib/feature-flags.ts
Requisitos:
- Flag chamado FF_NEW_CHECKOUT (variável de ambiente booleana)
- Rollout percentual por userId (começa em 10%)
- Se flag desligado, usa OldCheckout sem nenhuma mudança de comportamento
- Adicione log de analytics quando usuário entra no grupo de teste
- NÃO modifique OldCheckout — apenas envolva com o flag"
💡 Estratégia de Rollout Gradual para Código de IA
Código gerado por IA pode ter bugs sutis que só aparecem com dados reais de produção. O rollout gradual limita o blast radius:
✗ Não faça com features de IA
- •Deploy de 100% de uma vez sem teste gradual
- •Feature flag que muda schema do banco (irreversível)
- •Remover o código antigo antes de validar o novo
- •Feature flag que afeta fluxos de pagamento sem revisão manual
✓ Boas práticas com feature flags
- •Rollout gradual com métricas monitoradas em cada etapa
- •Flags sempre reversíveis sem novo deploy
- •Remova flags antigos após 100% de rollout estável
- •Documente cada flag com data de criação e propósito
⏪ Rollback automático — revertendo quando métricas degradam
Rollback automático é a capacidade de reverter um deploy quando métricas de saúde do sistema degradam além de um threshold. Em projetos de vibe coding, onde código gerado pode ter bugs sutis que só aparecem em produção com dados reais, rollback automático é a última linha de defesa.
🌲 Árvore de Decisão para Rollback Automático
Health Check Endpoint — Base para Rollback Automático
// src/routes/health.ts
import { Router } from 'express';
import { db } from '../lib/database';
const router = Router();
router.get('/health', async (req, res) => {
try {
// Verifica conexão com banco
await db.$queryRaw`SELECT 1`;
res.json({
status: 'ok',
timestamp: new Date().toISOString(),
version: process.env.npm_package_version,
uptime: process.uptime(),
});
} catch (error) {
// Retorna 503 — Railway/Vercel detectam e param o tráfego
res.status(503).json({
status: 'degraded',
error: 'Database connection failed',
});
}
});
export default router;
Rollback no Vercel
# Via CLI — rollback para deployment anterior
vercel rollback [deployment-url]
# Listar deployments disponíveis
vercel ls --prod
Vercel mantém histórico de deployments. Rollback é instantâneo — apenas aponta DNS para deployment anterior sem rebuild.
Rollback no Railway
# Railway Dashboard:
# Deployments → selecionar deploy anterior
# → "Rollback to this deployment"
# Ou via Railway CLI:
railway rollback [deployment-id]
Railway usa containers — rollback reativa o container anterior. Configure health check em Settings → Deploy para validação automática.
⚠️ Migrations de Banco e Rollback — O Ponto Crítico
Rollback de código é trivial. Rollback de schema de banco é perigoso. Se um deploy incluiu uma migration que removeu uma coluna ou tabela, reverter o código sem reverter o banco causa erros imediatos no código antigo.
Regra: sempre use migrations expansivas (additive only) com vibe coding. Adicione nova coluna, migre dados, só então remova a antiga em um deploy posterior. Nunca remova e adicione no mesmo deploy.
📡 Monitoramento pós-deploy — Sentry, analytics e alertas
Código gerado por IA pode ter bugs que passam por todos os checks mas só aparecem com tráfego real e dados de produção. Monitoramento pós-deploy é o último guardrail do processo de vibe coding profissional — e o que garante que você saiba antes dos usuários.
📊 Ferramentas de Monitoramento — Stack Recomendado
| Ferramenta | Detecta | Custo | Prioridade |
|---|---|---|---|
| Sentry | Erros runtime, exceções não tratadas, performance issues | Grátis até 5K erros/mês | Obrigatório |
| Vercel Analytics | Web Vitals (LCP, CLS, FID), performance por página | Incluso no plano Pro | Recomendado |
| Railway Metrics | CPU, memória, latência HTTP, container health | Incluso no Railway | Recomendado |
| PostHog | Analytics de produto, funis, feature flag analytics, sessões | Grátis até 1M eventos/mês | Opcional |
| Pino.js + LogTail | Logs estruturados, rastreamento de requests | LogTail grátis até 1GB/mês | Opcional |
Adicionando Sentry em um Prompt
"Adicione Sentry ao projeto Next.js.
Requisitos:
- Instale @sentry/nextjs
- Configure captura de erros em client e server
- Remova dados sensíveis (senha, cartão)
antes de enviar para o Sentry
- Adicione SENTRY_DSN ao .env.example
- Crie sentry.client.config.ts e
sentry.server.config.ts conforme docs
@package.json @next.config.ts"
Sentry Configurado com Privacidade
// sentry.config.ts
Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: process.env.NODE_ENV,
tracesSampleRate: 0.1, // 10% das transações
beforeSend(event) {
// Remove dados sensíveis
if (event.request?.data) {
delete event.request.data.password;
delete event.request.data.creditCard;
}
return event;
},
});
Configuração de Alertas Essenciais no Sentry
Alerta crítico — Slack imediato
Novo erro nunca visto antes (first seen) + taxa > 10 ocorrências/min
Alerta de regressão — Email
Erro resolvido que voltou a ocorrer (regression) em até 24h após deploy
Digest diário — Email
Resumo dos 10 erros mais frequentes das últimas 24h — para priorização
💡 O Que Monitorar Especificamente em Código Gerado por IA
Código gerado por IA tem padrões de falha distintos do código humano. Foque o monitoramento em:
- •Edge cases de dados reais: o agente testou com dados mockados — monitore erros com dados reais de produção nas primeiras 48h
- •Performance em escala: algoritmos corretos mas ineficientes aparecem quando há volume. Monitore queries lentas e memory usage
- •Erros de tipo em runtime: TypeScript estrito no build, mas dados externos (APIs, banco) podem surpreender. Monitore TypeErrors especificamente
- •Mudanças de comportamento sutis: a feature "funciona" mas a taxa de conversão caiu. PostHog com funis é essencial para detectar isso
✅ Resumo do Módulo 4.6
Próximo Módulo:
4.7 — 🤖 Agentes Autônomos e Multi-Agent: orquestração de agentes, paralelismo e o futuro do desenvolvimento de software em 2026