Por que agentes de IA têm mais dificuldade com código de ciência de dados do que com código de engenharia de software

Analisei centenas de repositórios no GitHub para entender por que agentes de IA para codificação costumam parecer muito mais capazes em engenharia de software do que em ciência de dados. O que encontrei sugere que não é só uma lacuna de ferramentas. Reflete uma diferença mais profunda: onde o sentido reside em cada tipo de código.

Sobre o que é este artigo

Se você já usou um agente de IA em um codebase de engenharia de software, provavelmente viu o quanto ele pode ser eficaz. O agente navega pela arquitetura, segue abstrações e faz alterações que se encaixam surpreendentemente bem no restante do sistema.

Aí você abre um notebook de ciência de dados, e a experiência muitas vezes muda.

O agente ainda consegue escrever código válido. Ainda segue instruções. Mas, com frequência, não entende totalmente o que realmente importa: por que este conjunto de dados, por que este filtro, por que esta janela de tempo, por que esta saída mudou o rumo da análise. 

Ele trata o notebook como um projeto de software, e isso é só uma parte do que ele é.

Eu queria entender o porquê. Então analisei centenas de repositórios no GitHub, em ciência de dados e engenharia de software, medindo entropia, padrões de referência e acoplamento. 

O que encontrei me surpreendeu — e acho que tem implicações reais para quem constrói ou usa agentes de IA em trabalhos analíticos.

A inversão de entropia: o código de ciência de dados não é o que parece

O que eu realmente medi

Medi a entropia de Shannon em três níveis de abstração para cada repositório: nível de caracteres, nível de tokens e nível de AST. Cada um captura uma dimensão diferente de variação no código.

Distribuição de entropia de código: ciência de dados vs. engenharia de software (gráficos violino)

O padrão que surgiu é o que chamo de inversão de entropia.

A superfície parece complexa; a estrutura, nem sempre

No nível de caracteres, o código de ciência de dados tende a ter maior entropia do que o de engenharia de software. Isso faz sentido: o trabalho em ciência de dados é cheio de nomes de colunas variados, rótulos de conjuntos de dados, variáveis ad hoc e identificadores específicos do domínio, que deixam o código ruidoso e irregular.

No nível de tokens, os dois domínios ficam bem mais próximos. Eles dependem de muitos dos mesmos blocos sintáticos.

Mas, no nível de AST, onde olhamos para a diversidade estrutural, a figura se inverte. 

O código de engenharia de software tende a codificar muito mais variação de estrutura. Ele cria comportamentos distintos por meio de abstrações, interfaces, módulos e lógica interna. 

O código de ciência de dados, por sua vez, frequentemente reutiliza um conjunto menor de operações em contextos que mudam: carregar, filtrar, agrupar, agregar, visualizar, inspecionar, ajustar.

Em poucas palavras: o código de ciência de dados costuma parecer mais complexo na superfície, enquanto o de engenharia de software carrega mais complexidade na estrutura.

Isso não é só estilo. Aponta para uma diferença mais profunda em como cada tipo de trabalho armazena significado.

Indexical vs. simbólico: onde vive o significado

Dois tipos diferentes de código

A inversão de entropia fica mais fácil de entender quando pensamos no que cada tipo de código realmente faz.

Em engenharia de software, o significado costuma ser comprimido na estrutura. Funções, interfaces, módulos, tipos e fronteiras de classes fazem grande parte do trabalho. Uma vez que essas abstrações são estabelecidas, elas estabilizam o comportamento e reduzem a incerteza futura. 

Muito do significado está dentro do próprio código.

Em ciência de dados, o significado fica muito mais atrelado ao contexto externo. Depende do conjunto de dados, das colunas, das saídas intermediárias, das premissas por trás de uma transformação e da pergunta em evolução que o analista tenta responder. O código não está apenas expressando lógica; ele aponta para uma situação analítica específica.

Essa diferença ajuda muito a entender por que agentes se comportam de formas tão distintas nos dois domínios.

Dá para ver por onde o código \"aponta\"

Também medi as densidades de referências externas e internas por 100 linhas de código em ambos os grupos.

Densidade de referências externas e internas, com significância estatística

A distinção é clara. O código de ciência de dados aponta mais para fora: para datasets, tabelas, colunas, objetos temporários e estados que existem fora do próprio código. 

O código de engenharia de software é mais autorreferente internamente. Ele constrói significado apontando para funções, classes, módulos e abstrações definidos em outras partes do codebase.

Código de dados aponta para fora. Código de software aponta para dentro.

Isso importa para agentes. Em um caso, muito do contexto relevante está no próprio codebase. No outro, grande parte está no estado analítico ao redor.

Por que isso faz a abstração se comportar de forma diferente

O problema do acoplamento em notebooks

Uma das descobertas mais interessantes foi sobre acoplamento. Fluxos de trabalho em estilo notebook mostraram acoplamento bem mais apertado por 100 linhas de código do que codebases de engenharia de software.

Isso não é necessariamente um mau design. Reflete algo fundamental na análise exploratória: a própria pergunta ainda está em movimento. Você testa premissas, segue resultados estranhos, verifica casos de borda e muda de direção à medida que aprende.

Nesse cenário, a abstração muitas vezes não compensa do mesmo jeito que em engenharia de software. Estruturar cedo demais pode reduzir opções antes de você entender o que importa. Acoplamento mais apertado costuma ser consequência da exploração, não apenas engenharia ruim.

O papel de comentários e estado

Há também uma diferença importante em como os dois domínios se explicam.

Em engenharia de software, o código muitas vezes se explica pela estrutura. Tipos, interfaces e abstrações carregam grande parte do significado; comentários costumam ser secundários.

Em ciência de dados, comentários, saídas e estado frequentemente carregam parte do significado. Uma nota como \"removidos outliers acima do percentil 99; confirmado que isso não afeta a coorte principal\" não é só documentação extra. 

Ela registra uma decisão analítica que pode não ser recuperável apenas pelo código. Uma tabela ou gráfico no meio do notebook pode explicar por que a próxima parte da análise existe.

Isso importa para agentes. Um agente que ignora comentários, resultados inline e o estado em evolução de um notebook perde parte da análise. Em um codebase de engenharia de software, essa informação muitas vezes é suplementar. Em ciência de dados, muitas vezes não é.

O que isso significa para agentes de IA

Agentes combinam naturalmente com um dos domínios

A implicação prática é: agentes funcionam melhor quando suas ferramentas combinam com onde o significado vive.

Em engenharia de software, um agente eficaz navega pela arquitetura. Segue o call graph, respeita interfaces e mantém as mudanças consistentes no codebase. Isso funciona porque muito do significado está codificado na estrutura.

Em ciência de dados, um agente eficaz precisa ir além de navegar pelo código. Ele precisa entender o que os dados realmente contêm, rastrear o estado ao longo dos passos, seguir a proveniência das variáveis e raciocinar sobre por que uma transformação ou filtro foi aplicado vários passos antes.

Um agente criado para engenharia de software não vai se transferir automaticamente bem para trabalhos de ciência de dados. A questão não é só sintaxe. A estrutura de informação subjacente é diferente.

Por que fluxos em estilo notebook persistem

Isso também ajuda a explicar algo que muitas vezes intriga engenheiros: por que notebooks continuam tão centrais apesar de suas limitações óbvias.

A resposta é que notebooks mantêm o significado perto dos dados enquanto a pergunta analítica ainda está evoluindo. Um notebook não é só um módulo Python mal estruturado. É um artefato diferente, feito para uma etapa diferente do trabalho. Ele mantém código, saídas e decisões próximos enquanto a análise ainda está tomando forma.

É por isso que um notebook pode parecer intuitivo para quem está imerso no contexto — e estranho para um agente que só enxerga o código.

Refatorar um notebook em código limpo e modular antes de a pergunta analítica estar fechada muitas vezes não é uma melhoria. Pode separar a lógica do contexto que deu significado a ela em primeiro lugar.

A oportunidade: fechar o gap de produção

A verdadeira oportunidade para agentes de IA em ciência de dados não é simplesmente copiar o que já funciona em engenharia de software. É ajudar a fechar o gap de produção: a distância entre um insight encontrado na exploração e um fluxo de trabalho reproduzível e implantável.

Esse gap existe porque notebooks preservam o contexto analítico ao custo da limpeza estrutural. Um agente que entenda tanto o contexto analítico quanto os requisitos estruturais de sistemas de produção pode ajudar a fazer essa ponte sem forçar o analista humano a sair do modo exploratório cedo demais.

Esse é um problema mais difícil do que navegar por um codebase. Mas também é o mais importante.

Principais aprendizados

Para resumir o que a análise sugere nos repositórios estudados:

\n
• O código de ciência de dados costuma ter maior entropia na superfície, enquanto o de engenharia de software costuma ter maior entropia estrutural.
\n
• O código de ciência de dados se refere com mais frequência a estados externos como datasets, colunas, tabelas e saídas intermediárias, enquanto o código de engenharia de software é mais autorreferente internamente.
\n
• Fluxos de trabalho em estilo notebook tendem a mostrar acoplamento mais apertado — muitas vezes consequência da exploração, e não apenas de prática ruim.
\n
• Comentários, saídas e estado em evolução fazem parte do conteúdo semântico do trabalho em ciência de dados — não são só detalhes periféricos.
\n
• Agentes otimizados para contextos de engenharia de software tendem a performar abaixo do esperado em ciência de dados se não forem projetados para raciocinar sobre dados, saídas e contexto junto com a estrutura do código.
\n

Conclusão

Quando comecei esta análise, esperava encontrar que o código de ciência de dados era simplesmente menos bem estruturado do que o de engenharia de software. Em vez disso, descobri que ele é estruturado de forma diferente por boas razões — com o significado muitas vezes vivendo em outro lugar.

Isso tem consequências práticas para quem constrói ou avalia agentes de IA para trabalhos analíticos. A verdadeira pergunta não é se um agente consegue escrever Python correto. É se ele entende o que são os dados, por que a análise tem o formato que tem e quais decisões foram tomadas ao longo do caminho que não ficam visíveis só pelo código.

Código de ciência de dados não é engenharia de software imatura. É uma otimização diferente: mais dependente de estado externo, menos apoiada em estrutura interna durável durante a exploração e moldada tanto pelo contexto quanto pelo código.

Depois que você enxerga isso, notebooks deixam de parecer projetos de software fracassados e passam a parecer o que realmente são: superfícies de trabalho para raciocinar sobre dados que mudam.

Estou dando continuidade a esta análise com um conjunto maior de 1.000 ou mais repositórios e métricas adicionais. Se você quer se aprofundar em como agentes de IA estão sendo construídos para trabalhar com dados em contexto (incluindo arquiteturas de execução persistente que mantêm o estado dos dados entre sessões), a trilha de aprendizado AI agent fundamentals da DataCamp é um ótimo ponto de partida.