Com agentes escrevendo mais código, verificar o que eles geram vira o trabalho central em dados

O texto parte de uma mudança de rotina: analistas, analytics engineers e até usuários de negócio escrevem menos SQL e Python à mão e pedem a consulta a um agente. Com contexto bom (modelos de dados, documentação, catálogo), a query sai razoável. O gargalo, então, deixa de ser produzir a análise e passa a ser checá-la. O autor cita uma pesquisa da Metabase: 74% das equipes construíam com IA, só 2% escalavam.

A proposta técnica são cinco níveis de teste: linting (análise estática de métricas e configs, com checagem de tipos e contratos), compilador (valida a árvore de lineage inteira antes do deploy), testes unitários, de integração e ponta a ponta com seeds fixos de dados. Sameer Al-Sakran, CEO da Metabase, defende que agentes podem gerar suítes de teste para KPIs como retenção, mas que gente de negócio segue sendo o melhor data contract, pela intuição sobre os números. Outro ponto é concentrar métricas, dashboards e ETL num só repositório declarativo, com um lineage DAG hierárquico apoiado em ASTs de SQL (como no SQLMesh). Por fim, o texto pede deslocar as assertions para a esquerda: o dbt já faz isso desde a v1.8, com testes unitários antes da materialização e contratos de modelo no build, e a ideia é estender isso à stack toda.

O tema da verificação já vinha sendo tratado pelo CEVIU no desenvolvimento de software em geral. Em 1 de junho de 2026, o CEVIU noticiou "Com IA no ciclo de desenvolvimento, testes ganham protagonismo". Em 16 de junho de 2026, veio "Code review com agentes de IA: da escrita para a confiança no código", e em 25 de agosto de 2026, "A verificação de código se torna essencial na era da IA e impulsiona novas estratégias de desenvolvimento". Em 13 de agosto de 2026, o CEVIU já cobria "A ascensão gradual dos Agentes de IA na gestão de dados". A notícia atual leva esse raciocínio para o território de dados e BI, com propostas específicas: lineage unificado entre modelos e ativos de BI e assertions no início do desenvolvimento.

Para quem opera pipelines e dashboards, a leitura é que o ganho de velocidade dos agentes só se sustenta se a verificação acompanhar. Isso sugere investir em seeds de teste conhecidos, contratos e checagens em build antes de investir em mais geração de SQL. Também sugere que a intuição de quem conhece o negócio continua fazendo parte do processo de validação.