Uma narrativa da moda está criando raiz silenciosamente: a IA escreve código cada vez melhor, e o valor do programador está sendo corroído. A narrativa ressurgem a cada lançamento da GPT — a GPT-5.6 acaba de sair, e as mesmas vozes retornaram. Mas olhe de perto um caso concreto, e você encontrará a história oposta.
James, um engenheiro da PostHog, reescreveu o parser SQL da empresa com o Claude. O resultado: 16 mil linhas de código de parser, 5 mil linhas de ferramentas, uma melhoria de desempenho de 70× (454× medida em produção), zero divergências em todas as consultas reais.
Mas o que é notável não são os números. É que ele quase não escreveu código. Ele não realizou a reescrita “escrevendo código” — ele fez isso “construindo um loop de verificação”. Essa é precisamente a mudança estrutural em curso no trabalho dos programadores: de escrever código à mão para construir sistemas de verificação.
Por que a PostHog Precisava de uma Reescrita — e por que Não Podia Fazer Isso Antes
A PostHog é uma plataforma open-source de análise de produtos em que os usuários consultam dados escrevendo SQL diretamente. Por baixo fica o ClickHouse, e a PostHog precisa fazer a transpilação entre eles — converter o SQL do usuário em SQL que o ClickHouse entenda.
Isso exige um parser SQL. Toda consulta processada pelo parser é uma entrada não confiável, e o controle de acesso e a otimização de desempenho downstream dependem todos da AST (árvore de sintaxe abstrata) que ele produz. Se o parser estiver errado, a fundação de todo o sistema está errada. A PostHog usava anteriormente um parser gerado pelo ANTLR. O ANTLR é um gerador de parsers open-source — você define regras gramaticais e ele gera o código do parser. Poderoso e flexível, ao custo do desempenho: o ANTLR compila as regras gramaticais em uma ATN (rede de transições aumentada) e a percorre em tempo de execução com um interpretador genérico. Cada parse passa por abstração e indireção; não existe um parseExpression() escrito à mão — tudo é travessia genérica de grafo.
Antes da IA, escrever um parser à mão era simplesmente irrealista — meses de trabalho, manutenção brutal, longe de valer a pena por um ganho de desempenho. O ANTLR trocava velocidade de execução por eficiência de desenvolvimento: a clássica troca entre ferramentas genéricas e implementação especializada. A IA desequilibrou essa balança.
O Loop de Verificação: o Novo Método de Trabalho do Programador
A reescrita do James foi, em sua essência, um loop de verificação em iteração contínua:
Gerar casos de teste → encontrar divergências → corrigir o parser → rodar regressão → repetir
O loop contém três camadas. Camada um: comparação com oráculo. James tinha uma “verdade absoluta” — o parser C++ ANTLR existente. Ele o transformou no oráculo, e o objetivo do novo parser era concordância exata em cada consulta real. Simples de enunciar, nada trivial de executar: os pontos de divergência não se revelam sozinhos; é preciso ir atrás deles. Camada dois: descoberta automatizada de divergências. James usou quatro métodos: uma suíte de testes de regressão para validação rápida inicial; testes baseados em propriedades (PBT) com a biblioteca Hypothesis para gerar automaticamente instruções SQL em busca de discordâncias com o oráculo; consultas anonimizadas amostradas dos logs de produção; e “pensar bastante nos casos extremos” — agentes Claude gerando proativamente casos de teste perversos em segundo plano. O PBT foi a arma central: ele chegou a escrever uma ferramenta que gera geradores de SQL a partir de arquivos de gramática do ANTLR — “para escrever um parser SQL, primeiro escreva um parser para arquivos de gramática .g4”, ele observou com um riso.
A percepção-chave: ele deixou o PBT rodando continuamente em segundo plano, adicionando novos casos com falha a um arquivo. Sempre que o Claude estava ocioso, ele puxava esses casos e corrigia o parser. Sua CPU rodava o PBT em carga máxima enquanto a inferência do Claude rodava em carga máxima corrigindo o parser — duas linhas de produção funcionando simultaneamente. Camada três: geração orientada por cobertura. Mais tarde, James adicionou geração de testes baseada em cobertura — o gerador identificava quais estruturas gramaticais permaneciam descobertas e as atacava. Não era estritamente necessário (a precisão em produção já estava perto de 100%), mas revelou vários casos extremos extremamente sutis.
O loop final: gerar casos com falha (PBT + corpora reais + regressão + raciocínio sobre casos extremos) → minimizar e adicionar à suíte de regressão → pensar na melhor correção, preferindo soluções gerais → implementar, produzindo um resumo para revisão humana → rodar regressão → repetir automaticamente.
O Framework do Loop de Verificação: o Novo Modelo de Capacidade do Programador
Do caso da PostHog, um quadro geral se abstrai — o Loop de Verificação — em três camadas, do básico ao avançado. Camada um: definição do oráculo. Você precisa ter um padrão de “correção”: um sistema existente, anotação humana ou um modelo teórico. Sem oráculo, sem verificação; sem verificação, sem controle sobre a qualidade da saída da IA. Camada dois: descoberta automatizada de divergências. Nunca conte com os olhos para encontrar todas as diferenças — busque sistematicamente com testes baseados em propriedades, fuzzing e orientação por cobertura. O ROI supera em muito revisar manualmente a saída da IA. Camada três: autonomia do loop. Encadeie a descoberta e a correção de divergências em um ciclo automático. O humano passa de “revisar cada linha de código” para “revisar o design do próprio loop”, tomando as decisões-chave: os casos de teste são suficientes? A correção é geral? O loop está convergindo?
O resumo do próprio James é preciso: “Embora eu não tenha escrito nenhuma linha de código à mão, eu jamais chamaria isso de codificação por vibes. Minha configuração de PBT gera entradas a partir de arquivos de gramática e usa geração orientada por cobertura — isso está próximo do estado da arte em fuzzing de parsers.”
O Alcance do Framework Além dos Parsers
O loop de verificação não é exclusivo de reescritas de parsers — ele se aplica a praticamente qualquer cenário em que a IA gera código. Refatoração de código: para fazer a IA reescrever um sistema Python antigo em Go, gerar diretamente produz código que “parece certo, mas pode não ser”. Rode o loop em vez disso — a saída e o comportamento do sistema antigo servem como oráculo; construa ferramentas automatizadas de diff comparando o antigo com o novo; deixe a IA corrigir até que todos os testes passem. Testes unitários com auxílio da IA: a geração de testes é a aplicação nativa do loop de verificação — a IA escreve os casos, você roda a suíte, encontra ramos não cobertos e manda a IA preenchê-los. Colaboração multi-agente: quando agentes trabalham juntos, o loop de verificação se torna “verificação de consenso entre agentes” — a saída de cada agente serve de oráculo para outro, e os pontos de divergência são os conflitos. É exatamente isso que o framework CoAgent ataca.
Um quadro, três camadas, muitos cenários. O loop de verificação não é uma invenção privada da PostHog — está se tornando o paradigma fundamental da engenharia de software na era da IA.
O que os Programadores Devem Fazer
Desenvolvedores de linha de frente: parem de gastar energia revisando cada linha de código da IA — esse é o caminho ineficiente. Comecem a construir ferramentas de verificação: frameworks de teste, ferramentas de diff, testes baseados em propriedades. Sua entrega central não é mais código; é a confiança de que esse código está correto. Gestores de engenharia: não meçam a eficiência da equipe por linhas geradas por IA. Construam uma métrica de “maturidade de loops de verificação” — a equipe constrói sistematicamente oráculo, descoberta de divergências e loops fechados em cada projeto? Invistam em infraestrutura de testes; o retorno supera comprar mais créditos de IA. Arquitetos: tornem a verificabilidade a primeira prioridade de design. Se a saída de um módulo não pode ser verificada automaticamente, ela não deve ser gerada por IA. Considerem o modo shadow — rodar a implementação gerada por IA em paralelo com o sistema antigo e comparar as diferenças de saída.
Dessa vez, o James fez em dias o que antes levava meses. Ele não escreveu código — ele construiu um sistema em que a IA gera código sob restrições corretas, testes automatizados garantem a qualidade e o loop de verificação impulsiona a convergência. A IA não tornou os programadores obsoletos. Ela os promoveu de escrever código para construir loops — um cargo mais sênior. Os programadores que dominam loops de verificação não perderam valor; a alavancagem o multiplicou.
Fonte: PostHog Engineering Blog — I wrote a 70x faster SQL parser while barely looking at the code
