Como manter a qualidade do código em vibe engineering: 5 práticas

A qualidade em vibe engineering não vem de “boa disciplina”. Vem de cinco práticas que, juntas, formam um escudo contra regressões. Uma prática isolada não basta. Duas bastam para começar. Três dão conforto. Com quatro e cinco, desaparece a maior parte dos problemas do tipo “por que quebrou de novo se os testes passaram”.

Prática 1: a spec como gate

Toda alteração que mexe em mais de três arquivos tem um SPEC.md ou uma issue com requisitos formais não funcionais (latência, custo de LLM, caminho de rollback) e funcionais. A spec é curta (400-800 palavras) e termina com uma seção “Fora do escopo”. Sem essa seção, toda implementação se desvia em 30%.

Quem escreve a spec é você (o humano). O agente pode ajudar com o primeiro rascunho, mas a aprovação é sua. Sem concessões: sem a aceitação humana, a spec vira um placeholder generativo.

Prática 2: duas revisões

Primeiro um agente revisa o PR (por exemplo, um subagent revisor dedicado). Depois, um humano. As duas revisões pegam classes diferentes de bugs. O agente pega inconsistências de estilo, tipos faltando, caminhos de código ingênuos. O humano pega a lógica de domínio mal interpretada e o “problema resolvido pela metade”.

O ponto crucial: o agente revisor não pode aprovar sozinho. Ele só pode comentar. Essa é a diferença entre um ajudante e quem toma a decisão.

Prática 3: testes de mutação ou baseados em propriedades

Uma cobertura tradicional de 80% só diz que a linha foi executada. O mutation testing (Stryker, PIT, Cosmic Ray) altera uma instrução e verifica se algum teste percebeu. Se nenhum percebeu, o teste era uma muleta.

O property-based testing (fast-check, Hypothesis) gera centenas de casos aleatórios. Basta um deles pegar uma regressão antes de chegar à produção para economizar milhares de horas de postmortem.

Em vibe engineering, recomendamos pelo menos um dos dois. O ideal é usar ambos nos módulos principais.

Prática 4: gates de CI

Gates que não dá para contornar:

• typescript strict sem erros;
• lint sem warnings (ou com uma allow list explícita);
• testes unit + e2e completos (nenhum .skip sem uma issue);
• mutation testing: 70%+ de mutantes mortos;
• delta de bundle size < 5% (alerta acima disso);
• security scan: zero high+critical, zero segredos no diff;
• evals de LLM nos prompts: 90%+ de taxa de aprovação no conjunto de regressão.

Cada gate pega uma classe diferente de bug. Pular qualquer um “só desta vez” dá início a uma dívida de qualidade que você paga de madrugada.

Prática 5: telemetria em produção + rollback automático

Depois do deploy: alertas de latência p99, erros 5xx, custo de LLM por requisição. Gatilho de rollback automático quando um limite é ultrapassado (API de rollback de deployments da Vercel, rollback do Kubernetes).

Segunda camada: resposta a incidentes. Um runbook para “o que fazer quando o alerta dispara”. Terceira: um postmortem sem culpados depois de cada incidente, com 5x “por quê”.

Mito: a IA vai garantir a qualidade sozinha

Não vai. A IA é muito boa em gerar código que “parece funcionar”, mas tem problemas sutis. Sem as cinco práticas acima, um PR gerado por LLM sai mais rápido, mas chega à produção com mais risco do que o PR de um júnior supervisionado por um mentor. Não porque a IA seja pior, e sim porque a IA escreve mais rápido, então cada brecha no seu processo cresce na mesma proporção dessa velocidade.

Objeções das equipes

“Cinco práticas é demais para a nossa equipe pequena.” Cada prática custa algumas horas por semana. Não ter nenhuma custa alguns dias por mês salvando a produção. A conta fecha mesmo para uma equipe de três pessoas.

“Somos uma startup, não temos tempo.” Spec, duas revisões e um tipo de teste: esse é o mínimo para uma startup depois do primeiro cliente pagante. O resto vem com o tempo.

Implantação em etapas

1. Semanas 1-2: spec para toda alteração em > 3 arquivos.
2. Semanas 3-4: agente revisor no CI (comenta, não bloqueia).
3. Semanas 5-8: mutation testing em um módulo (o mais crítico).
4. Semanas 9-12: gates de CI aplicados por completo.
5. Semana 13 em diante: telemetria em produção, rollback automático, runbooks.

TL;DR

Qualidade em vibe engineering são cinco práticas: spec, duas revisões, testes de mutação/propriedades, gates de CI e telemetria em produção com rollback automático. Isoladas, elas não bastam. Juntas, transformam o vibe engineering em um jeito de trabalhar que escala para a produção de verdade sem dramas de madrugada.