Notícias
Notícias
5 min de leitura
16 de outubro de 2026

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

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:

  1. Escreve unit tests (função por função)
  2. Escreve integration tests (features juntos)
  3. Escreve end-to-end tests (fluxo completo)
  4. QA manual (humano clica e testa)
  5. Deploy em staging (similiar a prod)
  6. 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:

  1. Benchmark tests (MMLU, ARC, etc) - NÃO SUFICIENTE
  2. Real-task tests (tarefas reais do seu caso de uso)
  3. Adversarial tests (tenta quebrar agent)
  4. Long-conversation tests (agent em conversas longas)
  5. Edge-case tests (caps, emoji, gíria, contexto confuso)
  6. Feature interaction tests (feature A + B + C juntos)
  7. Performance tests (latência, memory, CPU)
  8. Hallucination tests (agent inventa?)
  9. Safety tests (agent faz coisa perigosa?)
  10. 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:

  1. Se agent já está em produção: → Setup QA framework imediatamente → Roda 1000+ testes → Encontra bugs antes que cliente encontre → Fix + redeploy

  2. 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)

→ OpenClaw: Agent QA Framework, Testing, Real-Task Validation, Edge-Case Detection, Production-Ready AI Agents, Quality Assurance IA

Seu agent tem quantos bugs que você não vê? 🐛


Publicado em 16 de outubro de 2026

Leia também