Como a PostHog faz benchmark de agentes de IA em escala com tarefas reais

A PostHog gasta mais de 2 trilhões de tokens de LLM por mês, a maior parte rodando agentes. Por isso, diz a empresa, não dá para confiar na saída deles só no "feeling". O texto organiza o benchmark em três decisões: definir o gabarito, isolar as execuções e congelar o ambiente.

No gabarito, a evolução tem três níveis. Primeiro, uma lista de bugs potenciais de um único PR, usada no ReviewHog (agente interno de revisão de código). Depois, um conjunto de 33 incidentes reais, com o PR que causou cada um e o que o corrigiu. Nesse conjunto, o ReviewHog achou o bug em 62% dos casos. Em 47%, foi o único bot a achar. Em 9%, pulou o bug por já ter sido apontado por outro bot. Em 6%, outros bots acharam e ele não. Para tarefas abertas, como os Scouts, a saída foram rubricas geradas a partir do contexto do agente, somadas a uma rubrica estática comum. No isolamento, o problema é que agentes copiam memórias e logs de execuções anteriores, ou desistem de tarefas por achar que já foram feitas. A solução completa exige contexto inicial idêntico, estado gravável privado e avaliação separada, inclusive de telemetria e logs.

Para quem opera agentes em produção, a lição prática é tratar o benchmark como um pipeline de dados: gabarito versionado, execuções sem estado compartilhado e ambiente reproduzível. Usar incidentes reais como gabarito é uma leitura editorial interessante, porque ancora a métrica no que dói de verdade. O resultado de 62% vale para a stack da PostHog, e a própria empresa avisa que não se transfere automaticamente para outros repositórios.