CEVIU Logo
Voltar
🐛CEVIU

Agente de IA encontra bug de 3 anos no motor de consulta do PostHog e melhora performance

Aprofundamento CEVIU

Aprofundamento

O bug do PostHog não era um erro de lógica ou SQL mal escrito, era uma falha silenciosa na interação entre o motor de consulta e a estrutura física dos dados no ClickHouse. A chave primária definida como (team_id, timestamp) deveria permitir que filtros por timestamp usassem o índice esparso para pular granules inteiros, mas, por um problema de otimização interna no parser de consultas, o timestamp era ignorado quando usado em cláusulas WHERE com certos operadores (como BETWEEN com valores dinâmicos). Isso forçava leitura completa de todos os granules da partição, mesmo em queries altamente seletivas. O agente não 'adivinhou' o problema: ele comparou padrões de execução real com modelos de comportamento esperado baseados na documentação oficial do ClickHouse e nos perfis de I/O gerados pelo sistema de tracing interno do PostHog.

Isso difere radicalmente do caso da Mixpanel, onde a IA corrigiu um modelo preditivo defeituoso, aqui, ela identificou uma discrepância entre especificação e implementação. Também contrasta com o Projeto Glasswing, focado em segurança: este foi um achado de engenharia de performance pura, sem relação com vulnerabilidades ou fluxos de dados sensíveis. E, ao contrário do TD Bank, que usa agentes para orquestrar processos externos (como análise de crédito), o agente do PostHog atuou diretamente no stack de infraestrutura, sem intervenção humana além da validação final.

O que mudou

Em maio, a CEVIU destacou o uso de agentes para detectar falhas de segurança em tempo real (Ramp) e para auto-aperfeiçoamento contínuo (Codex). Agora, com o PostHog, vemos a primeira aplicação pública de um agente de IA que não apenas encontra bugs, mas corrige um problema técnico profundo, não em código-fonte, mas no comportamento de um sistema de banco de dados em produção. Antes, a IA era usada para 'ler' ou 'simular'; agora, ela 'diagnostica' e 'valida' a física dos dados. O salto é operacional: enquanto o projeto Glasswing gera relatórios, o agente do PostHog produziu um patch aplicável direto no schema e nas configurações de query rewrite.

Por que isso importa

Esse caso mostra que agentes de IA estão deixando de ser assistentes de desenvolvedores para virarem engenheiros de confiabilidade autônomos. Um bug que passou três anos despercebido por equipes humanas, apesar de métricas de latência estarem sempre acima do esperado, foi resolvido em horas por um agente treinado com poucos prompts e acesso direto aos logs de execução do ClickHouse. Para empresas que rodam milhares de consultas por segundo em bancos de dados analíticos, isso não é só sobre velocidade: é sobre custo de infraestrutura, previsibilidade de SLA e redução de tempo gasto em investigações manuais de 'slow queries'. A correção de 62% nos granules escaneados equivale, na prática, a desligar um terço dos nós do cluster durante picos de carga, algo que nenhuma ferramenta de observabilidade tradicional conseguia sugerir, porque o problema não estava nos sintomas, mas na suposição implícita de como o índice funcionava.

Linha do tempo

  1. CEVIU publica análise sobre agentes auto-aprimoráveis com Codex, destacando ciclos lentos de feedback pós-lançamento

  2. Ramp divulga resultados de detecção de falhas de segurança com agentes de IA em 8 horas

  3. PostHog revela descoberta de bug de 3 anos no ClickHouse por agente de IA, com ganho de 62% em eficiência de leitura

Perguntas frequentes

Como um agente de IA consegue entender o comportamento interno do ClickHouse?

O agente não 'entende' o ClickHouse como um humano. Ele foi alimentado com a documentação oficial, perfis de execução reais (incluindo traces de granule scan e índices usados), e treinado para reconhecer desvios entre o comportamento observado e o esperado, por exemplo, uma consulta com filtro de timestamp que lê 100% dos granules de uma partição, quando teoricamente deveria ler menos de 5%.

Esse tipo de detecção já era possível com ferramentas de observabilidade como Datadog ou New Relic?

Não. Ferramentas tradicionais mostram que uma consulta é lenta, mas não explicam por que o índice não está sendo usado. Elas não têm modelo interno do funcionamento físico do ClickHouse. O agente do PostHog integra esse conhecimento de domínio com dados de execução em tempo real, algo que exigiria anos de experiência humana para correlacionar manualmente.

O bug afetava só o PostHog ou é um risco generalizado para quem usa ClickHouse?

É específico à forma como o PostHog constrói suas consultas e configura seus clusters. Mas o padrão, usar timestamp como parte da chave primária e aplicar filtros dinâmicos, é extremamente comum. Outras empresas devem revisar seus perfis de query execution para verificar se consultas com timestamp realmente estão usando o índice esparso, não apenas assumir que estão.

Por que demorou 3 anos para descobrir? Não havia testes de performance?

Havia testes, mas eles mediam tempo médio de resposta, e o impacto do bug era mais visível sob carga alta e com dados reais, não em ambientes de staging com subconjuntos pequenos. Além disso, a equipe atribuía a lentidão a 'escala', não a um problema de indexação. O agente, ao analisar milhões de execuções, identificou o padrão anômalo que humanos tinham normalizado como 'típico'.

Fontes

Avalie este artigo:
Compartilhar:
Categoria
CEVIU
Publicado
03 de junho de 2026
Editoria
CEVIU

Quer receber mais sobre CEVIU?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser