Agent seu tem bug que você não vê (QA de IA é diferente)
Postgres 19 atrasou: AI reviewer encontrou MAIS bugs que humano. Seu agent pode ter bugs invisíveis. Como evitar quebra em produção?
Equipe OpenClaw · Time de Engenharia & Produto
A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…
Agent seu tem bug que você não vê (QA de IA é diferente)
Notícia que assusta:
Postgres 19 (database mais confiável do mundo) foi atrasado porque AI reviewer encontrou tantos bugs que humano não consegue consertar tudo.
Você leu certo: AI encontrou MAIS problemas que equipe humana consegue resolver.
Significado: Mesmo em projeto maduro (30 anos), com time experiente (centenas de devs), AI encontrou complexidade que passou despercebido.
Implicação pro seu SaaS:
Seu agent de IA tem quantos bugs que você não vê?
Probabilidade: Muitos.
O Cenário: Postgres descobriu isso do jeito difícil
O que aconteceu (simplificado)
Timeline:
Setembro 2026: Postgres devs: "Vamos lançar Postgres 19 em outubro." Plano: Code review com time humano
Octubro 2026: Alguém usa AI reviewer (experimental, pra ajudar) AI reviewer: "Achei 500+ issues potenciais" Humans: "Hmm, isso é muito. Vamos verificar." Human review: "Sim, AI encontrou problemas reais que passaram despercebidos."
Resultado: Postgres 19 foi ADIADO (não era pra sair em oct) Motivo: Quantidade de bugs é maior que capacidade de fix
Decisão: "Melhor adiar e consertar do que lançar bugado."
Por quê AI reviewer encontrou mais bugs
Razão 1: Escala de análise
Humano review:
- Lê código linha por linha
- Foca em 20-50 arquivos de cada vez
- Cansa depois de 4-6 horas
- Pode revisar 1000 linhas/dia (com 70% atenção)
AI reviewer:
- Analisa 100% do codebase simultaneamente
- Ve padrões entre milhões de linhas
- Não cansa
- Encontra: inconsistência em arquivo A que afeta arquivo Z (humano nunca veria porque não lê os dois juntos)
Razão 2: Padrão de bugs complexos
Bug simples (humano encontra):
- Null pointer exception
- Array out of bounds
- Undefined variable
Bug complexo (AI encontra, humano pode perder):
- Subtle race condition (só em 0.01% de execuções)
- Edge case que requer compreensão de 5 funções diferentes
- Comportamento inesperado quando 2 features interagem
- Performance regression (não quebra, mas fica lento)
- Memory leak que só ocorre depois de 10000 interações
AI pode encontrar: "Quando feature A + feature B + feature C executam em sequência específica, há memory leak."
Humano: "Hmm, eu nunca testei essa sequência específica."
Razão 3: Volume absoluto
Postgres 19 codebase:
- 3+ milhões de linhas de código
- 10000+ funções
- 30 anos de patches acumulados
Human review capacity:
- 100 devs x 50 horas/semana = 5000 horas/semana
- Podem revisar ~500k linhas/semana (com qualidade)
- Codebase = 3M linhas = 6 semanas só pra ler tudo uma vez
- Encontram ~100-200 bugs (sensatos, óbvios)
AI review capacity:
- 3M linhas analisadas em horas
- Encontra ~500+ issues (óbvios + complexos + sutis)
Diferença: 5x mais bugs encontrados por AI
O Problema Real: Seu agent pode ter os mesmos bugs
Como bugs invisíveis acontecem em agent
Bug tipo 1: Comportamento inesperado em edge case
Agent de atendimento: Funciona bem em 99% dos casos.
Bug invisível: Quando cliente escreve com CAPS LOCK + emojis + gírias, agent entra em loop infinito (pensa muito lentamente, timeout)
Você nunca vê porque:
- Testou com texto normal
- Não testou combinação: caps + emojis + gírias
- Probability: 0.5% dos clientes (não pega logo)
Cliente descobre: "Agent seu congela quando digito em CAPS." Você: "Nunca vi isso no teste." (verdade, você testou errado)
Bug tipo 2: Interação entre features
Seu agent tem: Feature A: Processar dúvidas (Q&A) Feature B: Escalação pra humano Feature C: Feedback de cliente
Bug invisível: Quando escalação (B) + feedback (C) acontecem juntos, agent envia resposta duas vezes (duplicado)
Você nunca vê porque:
- Testou A sozinho: funciona
- Testou B sozinho: funciona
- Testou C sozinho: funciona
- Nunca testou B+C juntos em situação real
Cliente descobre: "Agent escalou minha dúvida e ainda respondeu? Confuso."
Bug tipo 3: Performance degradation
Agent de vendas: Rápido no começo (responde em 2s)
Bug invisível: Conforme conversa fica longa, agent fica lento 100 mensagens: 2s 500 mensagens: 5s 1000 mensagens: 15s
Você nunca vê porque:
- Teste: conversas curtas (20-50 mensagens)
- Cliente real: conversas longas (200+ mensagens)
- Resultado: Agent "quebra" pra cliente com histórico longo
Bug tipo 4: Hallucination/Confabulation
Agent de suporte técnico: Responde perguntas sobre produtos
Bug invisível: Quando pergunta é muito específica (edge case), agent inventa resposta ao invés de dizer "não sei"
Exemplo: Cliente: "E se eu usar produto X em modo Y com config Z?" Agent: "Sim, funciona perfeitamente." (mentira, nunca testou) Cliente tenta: Quebra Resultado: Seu SaaS deu resposta errada
Você nunca vê porque:
- Testou com perguntas padrão (que agent sabe)
- Edge cases = combinação de 10+ parâmetros
- Probability de acertar ou errar? 50-50
Por quê você não vê esses bugs
Razão 1: Teste é incompleto
Seu teste: ✓ Testa happy path (cliente normal, pergunta normal) ✓ Testa algumas edge cases óbvias ✗ Não testa: todas as combinações possíveis ✗ Não testa: 1000+ horas de interação real ✗ Não testa: clientes "problemáticos" (caps, emoji, gíria)
Resultado: Bugs complexos não são descobertos até produção
Razão 2: Agent é não-determinístico
Código tradicional: Input X → Output Y (sempre) Fácil de testar: se output é Y, está certo
Agent de IA: Input X → Output Y1 (60% das vezes) Input X → Output Y2 (30% das vezes) Input X → Output Y3 (10% das vezes)
Problem: Como testar se correto? Qual output é esperado? Como saber se Y3 é bug ou comportamento aceitável?
Resultado: Difícil garantir qualidade (não determinístico)
Razão 3: Escala de complexidade
Postgres: 3M linhas código = complexidade X Seu agent: 1000 linhas prompt + 100k parâmetro modelo = complexidade 10x X
Por quê? Código: Controle de fluxo = determinístico, previsível Agent: Raciocínio emergente = não-determinístico, surpresas
Resultado: Seu agent é mais complexo que você acha Bugs invisíveis = garantido
A Solução: QA de agent é diferente
QA tradicional vs QA de agent
QA Tradicional (software):
Proesso:
- Escreve unit tests (função por função)
- Escreve integration tests (features juntos)
- Escreve end-to-end tests (fluxo completo)
- QA manual (humano clica e testa)
- Deploy em staging (similiar a prod)
- Deploy em prod (se tudo passou)
Metrics:
- Code coverage (80-90%)
- Test coverage (unit, integration, e2e)
- Bug detection rate (quantidade de bugs encontrados)
QA de Agent (IA):
Proesso:
- Benchmark tests (MMLU, ARC, etc) - NÃO SUFICIENTE
- Real-task tests (tarefas reais do seu caso de uso)
- Adversarial tests (tenta quebrar agent)
- Long-conversation tests (agent em conversas longas)
- Edge-case tests (caps, emoji, gíria, contexto confuso)
- Feature interaction tests (feature A + B + C juntos)
- Performance tests (latência, memory, CPU)
- Hallucination tests (agent inventa?)
- Safety tests (agent faz coisa perigosa?)
- Human review (reviewer (humano + AI) valida)
Metrics:
- Real-task accuracy (80%+)
- Edge-case accuracy (70%+)
- False positive rate (<5%)
- Latency p99 (<5s)
- Hallucination rate (<2%)
- Feature interaction test pass rate (95%+)
Checklist QA antes de lançar agent
Week 1: Prep
☐ Coleta 500+ conversas reais (histórico) ☐ Marca respostas corretas (humano valida) ☐ Identifica edge cases (caps, emoji, gíria, sarcasmo) ☐ Identifica feature interactions (A+B, A+C, B+C, etc)
Week 2-3: Testing
☐ Real-task tests: Agent em 500 tarefas reais Meta: accuracy >= 80%
☐ Edge-case tests: Agent em 100 edge cases Meta: accuracy >= 70%
☐ Long-conversation tests: Agent em conversas 200+ msgs Meta: latência <= 5s, sem timeout
☐ Feature interaction tests: A+B, A+C, B+C Meta: sem duplicação, sem erro, sem confusion
☐ Adversarial tests: "Break the agent" exercises Meta: agent reconhece limite, não inventa
☐ Hallucination tests: Perguntas que agent não sabe Meta: "não sei" rate >= 90%, inventa <= 2%
Week 4: Review
☐ AI reviewer: Análise automática de padrões Procura: bugs complexos, race conditions, memory leaks
☐ Human review: Reviewer experiente valida Procura: falsos positivos, edge cases que AI perdeu
☐ Combined review: AI + Human juntos Resultado: confiança alta que bugs são encontrados
Week 5: Staging + Go-live
☐ Deploy em staging (5 clientes beta) ☐ Monitor: accuracy, latency, errors ☐ Collect feedback: funciona? quebra? ☐ Staged rollout: 5% → 10% → 25% → 100%
Ferramenta: QA automatizado pra agent
O que procurar:
Ferramenta ideal pra QA de agent: ✓ Real-task testing (não só benchmark) ✓ Edge-case generation (gera automaticamente casos difíceis) ✓ Long-conversation simulation (simula conversas longas) ✓ Feature interaction matrix (testa todas combinações) ✓ Hallucination detection (identifica quando agent inventa) ✓ Performance monitoring (latência, memory, CPU) ✓ Regression testing (detecta quando nova versão quebrou algo) ✓ Human-in-the-loop review (QA não é 100% automática)
Exemplos:
- OpenClaw QA Framework
- DeepEval (open-source)
- Humanloop (monitoring + evals)
- Langsmith (LangChain's testing)
Casos reais: Quando QA falhou
Caso 1: Chatbot bancário
Banco lança agent de atendimento. QA: 5000 testes (happy path). Accuracy: 95%.
1 dia em produção: Cliente em CAPS LOCK: "ME AJUDA, TRANSFERÊNCIA NÃO FOI!" Agent: Congela (entrou em loop, prompt treatment error) Timeout: 30s Cliente: Nunca consegue resposta Resultado: Churn + PR damage
Pós-mortem: "QA não testou CAPS LOCK (achamos óbvio que agent saberia). AI reviewer teria encontrado em 5 minutos. Não usamos AI reviewer antes de lançar."
Caso 2: Agent de vendas
SaaS lança agent de vendas. QA: 1000 testes (conversas normais). Accuracy: 92%.
2 semanas em produção: Cliente com 500+ mensagens no histórico: Agent fica muito lento (10s por msg). Cliente: "Seu agent é lento demais." Resultado: Churn
Pós-mortem: "QA testou com conversas de 20-50 msgs. Nunca testou com 500 msgs (performance regression). AI reviewer teria simulado conversas longas. Não fizemos."
Caso 3: Agent de suporte técnico
SaaS lança agent de suporte técnico. QA: 2000 testes (perguntas padrão). Accuracy: 88%.
3 semanas em produção: Cliente pergunta edge case: "E se eu usar feature X com config Y em modo Z?" Agent inventa resposta: "Sim, suportamos isso 100%." Cliente tenta: Quebra (não é suportado) Resultado: Cliente furioso, refund
Pós-mortem: "QA não testou edge cases (muito específicos, não sabia testar). AI reviewer teria gerado 1000+ edge cases automaticamente. Não fizemos. AI teria dito: 'Agent hallucina em 5% das perguntas edge-case'."
Timeline: Implementar QA de agent
Opção 1: DIY (faça você mesmo)
Week 1-2: Coleta dados reais Week 3-4: Escreve testes (real-task, edge-case, long-conversation) Week 5-6: Roda testes, itera agent Week 7: Human review Week 8: Deploy
Timing: 2 meses Custo: 2-3 devs full-time Risco: Pode esquecer casos importantes (bias humano) Benefício: Controle total
Opção 2: Ferramenta de QA (recomendado)
Week 1: Setup de ferramenta (DeepEval, OpenClaw, etc) Week 2: Coleta dados reais + setup testes Week 3: Roda testes automaticamente (gera 1000+ casos) Week 4: Itera agent baseado em feedback Week 5: Human review (10% dos testes, AI fez 90%) Week 6: Deploy
Timing: 6 semanas Custo: Tool cost ($500-5k/mês) + 1 dev full-time Risco: Baixo (ferramenta já tem playbook) Benefício: Escala (1000+ testes gerados automaticamente)
Opção 3: Consultoria + ferramenta
Week 1: Consultoria (expert audita agent, identifica riscos) Week 2: Setup de ferramenta Week 3-4: Testes + feedback de expert Week 5: Deploy com confiança
Timing: 5 semanas Custo: Consultoria ($5-20k) + tool ($500-5k/mês) Risco: Muito baixo (expert viu muitos agents) Benefício: Highest confidence
Conclusão: AI encontra bugs que você não vê
Verdade:
Postgres 19 foi atrasado porque AI reviewer encontrou MÁIS bugs que time humano consegue consertar.
Significado: AI é melhor em encontrar bugs complexos. Seu agent? Tem bugs invisíveis garantido.
Implicação:
Se lançar agent sem QA rigorosa:
- Cliente vai achar bug que você não viu
- Vai reclamar (Twitter, reviews, refund)
- Você vai perder cliente
- Culpa: "Deveria ter testado melhor"
Se lançar agent com QA rigorosa:
- Vai gastar 4-8 semanas a mais
- Mas vai encontrar 80% dos bugs antes de produção
- Clientes felizes (agent funciona)
- Diferencial: "Agente que você pode confiar"
Ação imediata:
-
Se agent já está em produção: → Setup QA framework imediatamente → Roda 1000+ testes → Encontra bugs antes que cliente encontre → Fix + redeploy
-
Se agent ainda não está em produção: → Coleta 500+ tarefas reais → Roda QA rigoroso (real-task, edge-case, feature interaction) → Accuracy >= 80% em tarefas reais → Deploy com confiança
Timeline pra seu SaaS:
Agora: Setup QA (1-2 semanas) Week 3-6: Testes rigorosos (encontra bugs) Week 7: Deploy ou itera (depende dos resultados) Ongoing: Monitoring + retraining (nunca para)
Seu agent tem quantos bugs que você não vê? 🐛
Publicado em 16 de outubro de 2026