O ETL que a IA Escreveu Funcionou no Primeiro Dia. E na Segunda-Feira?

Resumo

Este artigo responde a uma pergunta: por que um pipeline de dados gerado por IA pode funcionar no primeiro dia e falhar nas semanas seguintes, e o que o time de dados precisa especificar antes de pedir o código?

O raciocínio é construído em etapas. Primeiro, define-se o que "funcionar" significa para um pipeline, e por que essa definição é mais exigente do que para uma aplicação comum. Depois, um caso relatado por um praticante mostra quatro falhas que surgiram semanas depois da entrada em produção, e o artigo as agrupa em tipos. Com os tipos em mãos, a pergunta passa a ser por que a IA não implementou essas regras. A resposta tem duas partes: um mecanismo (quando falta contexto, modelos generativos produzem o plausível, não admitem que não sabem) e uma causa informacional (as regras que sustentam um pipeline de produção nunca foram escritas). Em seguida, o artigo examina as regras que mais faltam, completude e plausibilidade, e mostra por que testes gerados junto com o código não as detectam. Por fim, organiza a divisão de trabalho entre IA e profissional de dados num checklist com exemplos de contrato e de verificação.

A literatura sustenta o diagnóstico por três caminhos: o desempenho de modelos em SQL cai muito ao sair de benchmarks acadêmicos para ambientes corporativos reais; modelos inventam artefatos inexistentes (pacotes, tabelas) em taxas não desprezíveis; e a validação de dados em produção, estudada há anos no Google, na Amazon e na Microsoft, depende de restrições explícitas e de histórico, não da sintaxe do código.

A resposta prática é inverter a ordem do trabalho: antes do código vêm a lista de modos de falha, o contrato de dados (esquema, SLA de latência, regras de qualidade), a definição de completude e testes escritos de forma independente da implementação.

1. O que "Funcionar" Significa para um Pipeline

Em 2026, pedir a um assistente de código um job que lê um CSV, grava em staging, faz merge na tabela final e registra log é tarefa de minutos. O código sai organizado, com tratamento de exceções e nomes razoáveis. Isso é um ganho real, e não é o que está em discussão.

O que está em discussão é o que "funcionar" significa para um pipeline de dados. Numa aplicação comum, código que roda sem erro é um bom sinal. Num pipeline, o código pode rodar sem erro e ainda assim carregar dado:

• errado (valores implausíveis, codificação trocada);
• duplicado (o mesmo lote carregado duas vezes);
• incompleto (carga feita antes de o dado estar pronto);
• atrasado (disponível depois do momento em que era necessário).

E ninguém percebe até o número aparecer num dashboard ou numa decisão. O erro de dados costuma ser silencioso. Por isso a pergunta "funciona?" precisa ser reformulada: "funciona em quais condições, e o que acontece fora delas?".

Na mesma semana, Simon Willison registrou que, quanto mais trabalha com agentes de código, mais convencido fica de que eles tornam a engenharia de software "even harder", porque extrair todo o potencial deles exige "extraordinary discipline and knowledge" (Willison, 2026). É uma nota curta e pessoal, não um estudo, mas resume a tensão deste artigo: gerar ficou barato, e a parte difícil mudou de lugar.

2. O Caso: Quatro Falhas que Não Estavam no Pedido

2.1 Os relatos e o grau de confiança

Os fatos recentes vêm de relatos de praticantes. Servem como ilustração, mas não são evidência controlada.

2.2 As quatro regras que ninguém havia escrito

O caso do ETL concentra o argumento; seu título original, "AI Generated ETL Worked on Day One. Then Came Monday.", inspira o deste artigo. Segundo o autor, Pinal Dave, o job antigo (de 2016) tinha quatro comportamentos que ninguém havia documentado:

1. um laço de espera que tolerava o atraso do arquivo de segunda-feira até as 9h, regra criada depois de um incidente em 2019;
2. uma verificação por hash que impedia recarregar um arquivo já processado;
3. uma regra que interrompia a carga quando o total do dia ficava abaixo da metade da média dos sete dias anteriores;
4. uma conversão de codificação de caracteres.

O pipeline novo não tinha nenhuma dessas regras, e no caso do arquivo zerado as validações existentes passaram. A conclusão do autor é a frase central deste artigo: nenhum dos quatro problemas estava na especificação que ele entregou. Ele descreve o job antigo como "a pipeline plus nine years of bad mornings" (Dave, 2026a).

2.3 Agrupando as falhas por tipo

As quatro falhas correspondem a tipos de regra que qualquer pipeline de produção precisa ter:

A tabela da seção 2.1 acrescenta um quinto tipo, latência ("tempo real" sem número). Esses tipos organizam o resto do artigo.

A pergunta seguinte: o modelo escreveu código correto para o que foi pedido. Por que não acrescentou nenhuma dessas regras?

3. Por que a IA Não Implementou as Regras: Mecanismo e Causa

3.1 O mecanismo: plausibilidade não é correção

O NIST, no perfil de IA generativa do seu framework de gestão de risco, chama de confabulação "the production of confidently stated but erroneous or false content (known colloquially as 'hallucinations' or 'fabrications')" e a lista entre os riscos específicos ou agravados pela IA generativa (NIST AI 600-1, 2024). O OWASP, no item LLM09:2025 (Misinformation), descreve o mesmo fenômeno, soma a ele o excesso de confiança do usuário e cita explicitamente a geração de código que sugere bibliotecas inexistentes (OWASP, 2025).

A tabela inventada é a versão em SQL desse problema. O texto de Pinal Dave resume: o modelo escreve SQL fluente porque leu muito SQL, mas nunca viu o seu esquema; diante de um nome desconhecido, não para e pergunta: escolhe o nome mais provável (Dave, 2026b). O risco que ele aponta é sutil: o erro Invalid object name é barulhento, mas a correção "óbvia" de alguém bem-intencionado pode ser criar a tabela que falta, e aí a alucinação vira objeto de produção.

3.2 O que a pesquisa mede

Há evidência revisada por pares de que inventar artefatos é comum. Spracklen et al. analisaram 576 mil amostras de código geradas por 16 modelos e encontraram taxas médias de alucinação de pacotes de pelo menos 5,2% em modelos comerciais e 21,7% em modelos abertos, com 205.474 nomes de pacotes inventados distintos (Spracklen et al., 2025). O estudo trata de dependências de software, não de tabelas; a analogia com esquemas de banco é minha e não foi medida pelos autores. O mecanismo, porém, é o mesmo: completar o padrão com um nome plausível.

Em SQL, o dado mais relevante vem do Spider 2.0, benchmark de fluxos text-to-SQL em ambientes corporativos reais (632 problemas, bancos com mais de mil colunas, vários dialetos, contexto longo e múltiplas queries). O o1-preview resolveu 21,3% das tarefas, contra 91,2% no Spider 1.0 e 73,0% no BIRD (Lei et al., 2025). O número reflete modelos de 2024 e não deve ser projetado para os modelos atuais. A lição que sobrevive à troca de modelos é a distância entre o ambiente controlado e o ambiente real, porque é nela que mora o conhecimento que o modelo não tem.

3.3 O agravante: a confiança do usuário

Perry et al., em estudo controlado com usuários, observaram que participantes com assistente de IA escreveram código menos seguro e, ao mesmo tempo, tinham mais chance de acreditar que o código era seguro; os que confiavam menos na ferramenta e reformulavam os pedidos tiveram menos vulnerabilidades (Perry et al., 2023). O estudo usou um modelo antigo (codex-davinci-002) e tarefas de segurança, não de dados. Ainda assim, o padrão de comportamento (código fluente gera confiança sem verificação) é exatamente o que torna silenciosas as falhas de um pipeline.

3.4 A causa: as regras nunca foram escritas

Juntando as três subseções: diante do que não sabe, o modelo preenche com o plausível, e quem usa tende a confiar. Mas por que o modelo não sabia das regras do caso? Porque elas não estavam em nenhum lugar que ele pudesse ler. Eram conhecimento implícito, acumulado em incidentes: quanto tempo esperar por um arquivo atrasado, como reconhecer um reenvio, quando um total baixo demais deve parar a carga.

Essa é uma limitação informacional, não de um modelo específico que a próxima versão vá resolver: o modelo não tem acesso ao incidente de 2019. Por isso a solução não está em escolher um modelo melhor, e sim em escrever as regras. As próximas seções mostram como fazer isso para os tipos que mais faltam.

4. Regras de Completude e Latência: Decisões de Negócio, Não de Código

4.1 "Quando o dado está completo?" não tem resposta padrão

Duas das quatro falhas (arquivo atrasado e arquivo zerado) têm a ver com completude: a carga rodou antes de o dado estar pronto, ou rodou com um dado de formato válido e conteúdo inválido.

A engenharia de dados trata disso há pelo menos uma década. O Dataflow Model, do Google, parte da premissa de que dados não limitados chegam fora de ordem, nunca estão "completos" e podem ser corrigidos depois, e de que o praticante precisa escolher um equilíbrio explícito entre correção, latência e custo (Akidau et al., 2015).

Esse equilíbrio é uma decisão de negócio, não um detalhe de implementação. Nenhum modelo de linguagem consegue inferir que o fornecedor atrasa às segundas.

4.2 "Tempo real" é um requisito sem unidade

O mesmo vale para latência, o quinto tipo de regra. O SeattleDataGuy propõe uma pergunta de triagem: "Can you give me an example of a decision that would have been different if you had this data 10 minutes earlier?". Ele lembra que rodar um pipeline 1.440 vezes por dia em vez de 24 multiplica a complexidade de backfill e de mudança de esquema, e que "the freshest version of the data is not the most reliable version" (SeattleDataGuy, 2026).

Para um agente de código, "tempo real" pedido sem número pode virar qualquer coisa: um cron a cada minuto, um stream, um trigger. Todas as opções compilam.

4.3 As ferramentas existem; falta a especificação

A documentação atual já oferece lugar para escrever esses requisitos:

• O dbt permite declarar source freshness com loaded_at_field, warn_after e error_after, e descreve isso como "a critical component of defining Service Level Agreements (SLAs) for your warehouse" (dbt Labs, s.d.-a).
• O Open Data Contract Standard (ODCS), mantido pelo projeto Bitol, tem uma seção de SLA com propriedades como latency, frequency, retention, timeToDetect e timeToRepair; a documentação indica latency como "preferred to freshness" (Bitol, s.d.-a).

O gargalo, portanto, não é de ferramenta. É alguém decidir os números e escrevê-los antes de pedir o código.

5. Regras de Plausibilidade: Por que Teste Verde Não Basta

Completude e latência podem ser declaradas em configuração. A plausibilidade do conteúdo exige testes. E aqui surge um problema adicional: os testes que a IA gera junto com o código não detectam o que falta no código.

5.1 O problema do oráculo, na versão agente

Gal Arav formula o problema com precisão: se um único agente implementa sua interpretação de um requisito ambíguo e depois escreve testes com base na mesma interpretação, "the tests cannot disagree with the implementation". E "a test's entire value is that it might fail" (Arav, 2026).

A proposta é separação de funções aplicada por código: a especificação em YAML é dividida em requisitos (vistos só pelo agente que codifica), critérios de aceitação (vistos só pelo agente que testa) e interface (compartilhada).

O texto é a parte 1 de uma série e não traz medição de eficácia; o autor deixa os números para a parte 2. A ideia de fundo (o teste precisa de uma fonte de verdade independente do código testado) é antiga em engenharia de software. A novidade é que, com agentes, a independência deixa de ser garantida por pessoas diferentes e precisa ser construída no processo.

5.2 Em dados, o teste é sobre o dado, não sobre o código

Mesmo com testes independentes, pipelines têm uma segunda camada que o teste de unidade clássico não cobre: o dado de amanhã. Um teste que verifica se a função de merge funciona com um fixture não diz nada sobre o arquivo zerado da próxima terça-feira. Por isso a pesquisa em validação de dados trata o dado como artefato de produção a ser verificado continuamente:

• Amazon / Deequ. Schelter et al. propõem "testes de unidade para dados": uma API declarativa que combina restrições comuns de qualidade com código de validação próprio, validação incremental em conjuntos que crescem e aprendizado de máquina para sugerir restrições e detectar anomalias em séries históricas de métricas de qualidade (Schelter et al., 2018).
• Google / TFX. Polyzotis et al. descrevem o sistema de validação de dados em produção no Google, parte do TFX, partindo da constatação de que erros nos dados de entrada podem anular qualquer ganho do modelo; relatam detecção precoce de erros e redução do esforço de depuração (Polyzotis et al., 2019).
• Microsoft / AVH. Tu et al. partem de uma constatação que é quase o caso do ETL: problemas de qualidade "can often creep into recurring pipelines because of upstream schema and data drift over time". A proposta é programar restrições automaticamente a partir do histórico de execuções, avaliada em 2.000 pipelines de produção da Microsoft (Tu et al., 2023).

A regra "parar se o total do dia for menor que metade da média de sete dias" é, literalmente, uma restrição histórica do tipo que Deequ e AVH formalizam. O job de 2016 a implementava de forma artesanal. O pipeline gerado pela IA não a tinha, porque ela não estava escrita em nenhum lugar legível.

5.3 Forma não é conteúdo

Vale separar forma de conteúdo. A documentação do dbt é explícita: o contrato de um modelo define a forma do dataset, e testes de dados validam o conteúdo depois da construção. Além disso, em várias plataformas as restrições são "definable and not enforced", ou seja, existem apenas como metadado; no Snowflake e no Redshift, por exemplo, só not_null é aplicada (dbt Labs, s.d.-b). Um arquivo zerado passa em qualquer contrato de esquema.

6. Síntese: a Divisão de Trabalho entre IA e Profissional de Dados

Com os tipos de regra da seção 2.3 e as explicações das seções 3 a 5, a divisão de trabalho fica razoavelmente clara:

As linhas em que a IA vai bem são as que o pedido já descreve. As linhas em que ela falha dependem de conhecimento que só existe na cabeça de quem opera o sistema ou em código legado que ninguém lê. É a limitação informacional da seção 3.4.

Há uma consequência menos óbvia: a migração assistida por IA pode apagar conhecimento. Reescrever um job antigo "do zero, mais limpo" descarta justamente as regras estranhas que existiam por um motivo. O código novo parece melhor e é, ao mesmo tempo, menos correto.

7. Aplicando: Checklist Antes de Pedir o Código

O checklist segue a ordem do raciocínio: descobrir as regras, escrevê-las, testar de forma independente e monitorar.

Descobrir as regras que existem

1. Peça a lista de falhas antes do código. É o que o autor do caso passou a fazer: pedir ao modelo que enumere as formas de o pipeline falhar e validar a lista com quem opera o sistema hoje (Dave, 2026a). Use a lista como insumo de requisitos, não como verdade: ela também pode confabular.
2. Faça arqueologia do legado. Se o pipeline substitui outro, leia o código antigo em busca de laços de espera, hashes, limiares e conversões. Cada um é um requisito não documentado. Transcreva-os.

Dar ao modelo o contexto que ele não tem

1. Entregue o esquema real e proíba a invenção. "Schema first, question second": cole as tabelas e colunas permitidas no contexto antes da pergunta e diga explicitamente que o modelo não pode criar outras (Dave, 2026b).
2. Nunca "conserte" um Invalid object name criando o objeto. Primeiro confirme se ele deveria existir.

Escrever as regras (um item por tipo da seção 2.3)

1. Escreva o contrato de dados. Esquema, SLA de latência e regras de qualidade num formato legível por máquina (ODCS, contratos do dbt ou equivalente).
2. Completude: qual é o sinal de "pronto"? Até quando esperar? O que fazer se o dado não chegar: falhar, alertar ou seguir com parcial?
3. Idempotência: o que identifica um arquivo ou lote já processado? Como tratar reenvio corrigido: substituir, versionar ou rejeitar?
4. Latência: transforme "tempo real" em número, em minutos, justificado por uma decisão concreta.

Testar e monitorar

1. Separe quem escreve o teste de quem escreve o código. Pessoa ou agente, com critérios de aceitação que a implementação não vê (Arav, 2026).
2. Teste o dado, não só o código. Contagem de linhas, duplicidade, nulos, total contra histórico, codificação.
3. Monitore o que muda com o tempo. Restrições baseadas em histórico (no estilo Deequ ou AVH) pegam o que um teste estático não prevê.

7.1 Exemplo: contrato mínimo

Um contrato mínimo para o caso do CSV do fornecedor, seguindo a estrutura dos exemplos da documentação do ODCS (Bitol, s.d.-a; Bitol, s.d.-b). O exemplo é ilustrativo e mostra apenas os trechos de SLA e qualidade, não um contrato completo. Note que ele cobre latência (latency), completude (rowCount), idempotência (duplicateValues) e plausibilidade (a regra em SQL):

# ILUSTRATIVO — trechos de SLA e qualidade no formato do ODCS
slaProperties:
  - property: latency            # dado disponível até 3 h após a data de referência
    value: 3
    unit: h
    element: vendas_fornecedor.data_ref
  - property: frequency
    value: 1
    unit: d
    description: "Arquivo diário; às segundas o fornecedor pode atrasar até 09:00"
schema:
  - name: vendas_fornecedor
    quality:
      - id: vendas_linhas_minimas
        metric: rowCount
        mustBeGreaterThan: 0
        dimension: completeness
      - id: vendas_sem_duplicidade
        metric: duplicateValues
        mustBe: 0
        dimension: uniqueness
        arguments:
          properties: [data_ref, id_venda]
      - id: vendas_total_plausivel
        type: sql
        description: "Total do dia não pode ser < 50% da média dos 7 dias anteriores"
        query: "SELECT CASE WHEN ... THEN 1 ELSE 0 END"
        mustBe: 1
        dimension: accuracy

7.2 Exemplo: verificação de plausibilidade antes do merge

A regra de plausibilidade escrita como verificação SQL antes do merge (ilustrativo, T-SQL). O COALESCE é deliberado: sem ele, um lote vazio produz SUM nulo, a comparação vira desconhecida e a carga passa como OK, exatamente o tipo de falha silenciosa que este artigo descreve.

-- ILUSTRATIVO: bloqueia a carga se o total do lote for implausível
WITH hist AS (
    SELECT AVG(total_dia) AS media_7d
    FROM (
        SELECT data_ref, SUM(valor) AS total_dia
        FROM   final.vendas
        WHERE  data_ref >= DATEADD(day, -7, @data_ref)
          AND  data_ref <  @data_ref
        GROUP BY data_ref
    ) t
)
SELECT CASE
         WHEN (SELECT media_7d FROM hist) IS NULL
              THEN 'SEM_HISTORICO_REVISAR'
         WHEN (SELECT COALESCE(SUM(valor), 0) FROM staging.vendas)
              < 0.5 * (SELECT media_7d FROM hist)
              THEN 'BLOQUEAR_E_ALERTAR'
         ELSE 'OK'
       END AS decisao;

Para o arquivo atrasado, o source freshness do dbt (warn_after / error_after) é o equivalente declarativo mais direto na documentação consultada (dbt Labs, s.d.-a).

8. Consequência: a Modelagem de Dados Virou o Briefing do Agente

Se a causa das falhas é informacional (seção 3.4), a atividade que produz informação sobre o negócio ganha importância, não perde. É o caso da modelagem de dados.

Madison Mae, no texto que reabriu a pergunta "a modelagem de dados acabou?", defende que não: a IA não entende sozinha os processos de negócio, não detecta fluxos não documentados nem percebe quando o dado de origem vem de um processo quebrado. O valor está no conhecimento de domínio, na comunicação e no aprendizado sobre o negócio que o próprio ato de modelar produz (Mae, 2026). É um ensaio de opinião, sem dados; o caso do ETL funciona como evidência anedótica a favor dele.

A reformulação que proponho é mais operacional. Grãos, chaves, regras de deduplicação, definições de métrica, SLAs e restrições de qualidade eram, antes, documentação para humanos, frequentemente desatualizada. Agora são também o contexto que determina se o agente vai gerar o pipeline certo ou apenas um pipeline plausível. Um modelo dimensional com grão explícito responde de antemão perguntas que o agente teria de adivinhar. Um contrato de dados executável transforma "nove anos de manhãs ruins" em texto que tanto uma pessoa nova quanto um agente conseguem ler.

Nessa leitura, a modelagem não perdeu importância. Ganhou um leitor a mais, que interpreta tudo ao pé da letra e preenche as lacunas com o que parecer mais provável.

9. Limitações e o que Ainda Não se Sabe

• Os casos da semana são anedóticos. O relato do ETL é de fonte única, em primeira pessoa, sem código ou dados publicados; o da tabela alucinada é uma narrativa didática. Servem para ilustrar mecanismos, não para estimar frequência.
• Não há, na pesquisa consultada, medição direta de "pipelines de dados gerados por IA em produção". A evidência científica usada é adjacente: text-to-SQL em benchmark, alucinação de pacotes, segurança de código, validação de dados. A transposição para ETL é inferência minha.
• Os números envelhecem rápido. O Spider 2.0 avaliou modelos de 2024. Modelos mais novos podem ir bem melhor em SQL, o que reduziria o problema de sintaxe e de esquema, mas não o das regras não escritas, que é informacional.
• O desenho spec-driven ainda não tem avaliação publicada. Não sabemos quanto a separação entre agente de código e agente de teste melhora os resultados na prática, nem a que custo.
• Contratos de dados também podem ser gerados por IA, o que recoloca o problema um nível acima. Não encontrei estudo sobre a qualidade de contratos e testes de dados gerados automaticamente sem histórico.

10. Recapitulando o Raciocínio

1. Para um pipeline, "funcionar" não é rodar sem erro: o dado pode estar errado, duplicado, incompleto ou atrasado sem nenhum alerta.
2. No caso relatado, quatro falhas surgiram em semanas, e nenhuma estava no pedido. Elas correspondem a tipos de regra: completude, idempotência, plausibilidade e formato, além de latência.
3. A IA não implementou as regras por um mecanismo (diante do desconhecido, produz o plausível) e por uma causa informacional (as regras nunca foram escritas).
4. Completude e latência são decisões de negócio; as ferramentas para declará-las existem (dbt, ODCS), falta decidir os números.
5. Plausibilidade exige testes sobre o dado, com fonte de verdade independente do código e restrições baseadas em histórico.
6. A IA faz bem o que o pedido descreve; o profissional de dados é quem descobre e escreve o que o pedido não descreve.
7. Por isso a modelagem e a especificação não perderam valor: viraram o insumo principal entregue ao agente.

11. Conclusão

O ETL gerado por IA funcionou no primeiro dia porque o primeiro dia só testou o que foi pedido. Na segunda-feira chegou o que não foi pedido: atraso, reenvio, zeros e codificação trocada. A pesquisa ajuda a entender por que isso é estrutural e não azar: modelos produzem o plausível quando falta contexto, erram mais em ambientes reais do que em benchmarks, e os usuários tendem a confiar demais no código fluente. Dados de produção, por sua vez, só se mantêm confiáveis com restrições explícitas e monitoradas ao longo do tempo.

A resposta à pergunta, portanto: o pipeline falha depois porque as regras que o sustentam nunca foram especificadas, e o que o time precisa fazer é especificá-las antes: modos de falha, completude, idempotência, latência em número, limiares de plausibilidade e testes independentes da implementação. A IA reduziu muito o custo de escrever o caminho feliz. O trabalho do profissional de dados se concentra agora no que fica fora dele, e isso já tem nome antigo: modelagem e especificação.

Nota Metodológica

Todas as fontes listadas foram lidas na origem (em 27/09/2026), e as citações e números foram conferidos contra o texto original. A definição de confabulação do NIST foi extraída do PDF oficial do NIST AI 600-1. Textos que não puderam ser acessados na íntegra não foram usados. Relatos de praticantes e ensaios de opinião estão identificados como tal e servem para ilustrar mecanismos; as conclusões se apoiam nos estudos revisados por pares e na documentação oficial.

Referências

1. Dave, P. (SQL Authority). (2026a). AI Generated ETL Worked on Day One. Then Came Monday. Link

2. Dave, P. (SQL Authority). (2026b). AI Hallucinated a Table That Was Never There. Link

3. Willison, S. (2026). Nota sobre agentes de código tornarem a engenharia de software mais difícil. Link

4. Arav, G. (2026). Towards Spec-Driven Test Automation, Part 1. Towards Data Science. Link

5. Mae, M. (2026). Is Data Modeling Done For? Learn Analytics Engineering. Link

6. SeattleDataGuy. (2026). Do You Actually Need Real-Time Data? SeattleDataGuy's Newsletter. Link

7. NIST. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). Link

8. OWASP GenAI Security Project. (2025). LLM09:2025 Misinformation. Link

9. Spracklen, J.; Wijewickrama, R.; Sakib, A. H. M. N.; Maiti, A.; Viswanath, B.; Jadliwala, M. (2025). We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. USENIX Security Symposium. Link

10. Lei, F.; Chen, J.; Ye, Y. et al. (2025). Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows. ICLR 2025. Link

11. Perry, N.; Srivastava, M.; Kumar, D.; Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS '23. Link

12. Akidau, T.; Bradshaw, R.; Chambers, C. et al. (2015). The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing. Proceedings of the VLDB Endowment, 8, pp. 1792–1803. Link

13. Schelter, S.; Lange, D.; Schmidt, P.; Celikel, M.; Biessmann, F.; Grafberger, A. (2018). Automating Large-Scale Data Quality Verification. PVLDB 11(12). Link

14. Polyzotis, N.; Zinkevich, M.; Roy, S.; Breck, E.; Whang, S. (2019). Data Validation for Machine Learning. Proceedings of Machine Learning and Systems (MLSys) 1. Link

15. Tu, D.; He, Y.; Cui, W.; Ge, S.; Zhang, H.; Shi, H.; Zhang, D.; Chaudhuri, S. (2023). Auto-Validate by-History: Auto-Program Data Quality Constraints to Validate Recurring Data Pipelines. KDD 2023. Link

16. dbt Labs. (s.d.-a). Sources: source data freshness. Documentação oficial. Link

17. dbt Labs. (s.d.-b). Model contracts. Documentação oficial. Link

18. Bitol. (s.d.-a). Open Data Contract Standard (ODCS): Service-Level Agreement. Documentação oficial. Link

19. Bitol. (s.d.-b). Open Data Contract Standard (ODCS): Data Quality. Documentação oficial. Link