.webp){kind=small}
Se analisarmos o histórico de commits das plataformas de dados modernas, algo profundo mudou nos últimos dois anos. A dificuldade de escrever sintaxe diminuiu drasticamente. Com o Cursor, o Claude Code e os fluxos de trabalho agentivos agora integrados aos nossos contêineres Docker e IDEs, gerar a primeira implementação de um pipeline de streaming distribuído ou uma integração de API complexa deixou de ser o principal gargalo.
Os agentes podem navegar por repositórios, escrever cobertura de testes, inspecionar rastreamentos de pilha e propor refatorações. Descreva um mapeamento de um coletor Kafka para um coletor Iceberg em linguagem simples, e um agente poderá produzir um ponto de partida confiável antes mesmo que o engenheiro tenha aberto todos os arquivos relevantes.
Isso muda a questão para os engenheiros de software.
Se o agente está se tornando o principal autor da lógica do sistema local, o que exatamente resta para o engenheiro fazer? Estaremos caminhando para uma indústria de revisores que aprovam automaticamente um fluxo interminável de solicitações de pull request plausíveis? Ou o trabalho deixou de ser a construção de lógica e passou a ser algo mais abstrato?
Para responder a essa pergunta, é útil recorrer à perspectiva da termodinâmica, que nos fornece uma linguagem para trabalho direcionado, feedback, perda e os limites que mantêm um sistema complexo coerente.
O agente como motor térmico
Ao despojarmos-nos da ilusão antropomórfica da IA, o que resta é um motor computacional. Ele recebe instruções e as transforma em ação.
Um LLM (Local Learning Machine) instalado em um data center possui imensa capacidade, mas não realiza trabalho útil até receber uma instrução. Um prompt, uma necessidade de negócio, uma instrução do sistema ou uma falha em um teste fornece uma direção ao agente. Ele transforma essa direção em código, chamadas de ferramentas, consultas, testes e alterações em um sistema em execução.
Todo loop de agente também
Quem já deixou um agente rodando em um repositório complexo sabe bem disso. Começa com uma tarefa clara. Depois, parte de uma premissa ultrapassada, corrige um sintoma em vez da causa, trata uma migração antiga como comportamento atual e começa acumulando seu próprio histórico. Algumas chamadas de ferramentas depois, o contexto contém detalhes plausíveis, porém conflitantes, o suficiente para que o próximo passo seja menos certo que o primeiro.
Podemos chamar isso de entropia operacional: o acúmulo de suposições obsoletas, contexto ramificado e dependências não resolvidas dentro de um ciclo que ainda está tentando avançar.
A interrupção humana é útil porque introduz novas informações. O mesmo acontece com um teste falho, um contrato de dados preciso, uma ferramenta determinística ou uma avaliação que indique ao agente exatamente o que ele fez de errado. Sem esse sinal, um agente pode continuar gerando resultados enquanto se distancia cada vez mais de um resultado correto.
Os agentes claramente geram movimento. A verdadeira questão é se o sistema ao seu redor transforma esse movimento em trabalho útil.
O macaco infinito e o espaço de busca acelerado
O teorema do macaco infinito nos dá uma ideia útil do que se segue: tentativas repetidas, restrições finitas e feedback.
O teorema afirma que um macaco digitando aleatoriamente por um tempo infinito quase certamente digitará a obra completa de Shakespeare. Os agentes modernos são macacos muito mais inteligentes. Eles possuem compiladores, ferramentas, repositórios, conjuntos de testes e ciclos de feedback. Seu trabalho não é aleatório — o feedback direciona a próxima tentativa —, mas a dinâmica é familiar: propor, executar, observar, corrigir e tentar novamente.
Em uma tarefa delimitada, esse ciclo é notavelmente eficaz.
Forneça a um agente um esquema de entrada conhecido, um esquema de destino conhecido, uma pequena base de código e testes que detectem as falhas relevantes. Ele pode inspecionar o código, fazer uma alteração, executar os testes, absorver o resultado e tentar novamente. A definição de "concluído" é visível. O espaço de busca é restrito. O loop tem chance de convergir.
Mas os sistemas empresariais raramente oferecem esse tipo de estabilidade. Um mecanismo de precificação em tempo real pode depender de um estado operacional mutável, APIs de terceiros, eventos que chegam com atraso, políticas regionais e regras de negócios que existem em parte no código e em parte na cabeça de alguém. Um data lake pode ser fisicamente consistente e semanticamente incorreto. Um pipeline pode passar nos testes e ainda produzir números que o setor financeiro não reconhece.
O problema dos três corpos da lógica empresarial
É por isso que o problema dos três corpos é uma imagem tão útil para software empresarial.
Com dois corpos — um planeta e uma estrela — é possível prever o movimento com uma descrição matemática precisa. Adicione um terceiro corpo e o problema se torna muito mais difícil de resolver. Não existe uma solução geral em forma fechada, e algumas configurações exibem comportamento caótico. Pequenas mudanças em um ponto podem produzir trajetórias muito diferentes em outros lugares.
As plataformas de dados modernas têm o mesmo formato. Os dados de fluxo de cliques mudam com o comportamento do produto. Os bancos de dados operacionais sofrem mutações de acordo com a atividade do cliente. As APIs impõem limites de taxa e mudam de versão. Os esquemas evoluem. As políticas de segurança mudam. Os sistemas legados carregam regras que ninguém documentou porque ficaram enterradas no tratamento de exceções por anos.
Cada sistema exerce pressão sobre os outros. Uma mudança em um local altera o significado ou o comportamento de outro. O que começa como uma solicitação de recurso local passa a afetar todo o sistema.
Considere um cenário hipotético: um agente é solicitado a adicionar um campo `customer_tier` a um modelo de receita. Ele encontra um campo chamado `status` no banco de dados operacional, mapeia-o para a transformação e passa nos testes de tipo e nulidade existentes. O código está limpo. O pipeline está funcionando corretamente. A resposta ainda está incorreta.
Um contrato de dados semântico afirma que o nível do cliente (customer_tier) é derivado dos gastos dos últimos doze meses, possui um responsável comercial atribuído e não pode ser preenchido a partir do status da conta. O contrato rejeita a alteração antes que ela chegue ao painel de controle. A contribuição do engenheiro não foi a transformação em si, mas sim a delimitação que tornou o erro do agente visível, específico e recuperável.
O trabalho do engenheiro de software não é mais escrever cada linha de micrológica. Os agentes realizarão esse trabalho cada vez mais, e frequentemente mais rápido. O novo objetivo — projetar o equilíbrio — é criar as condições em que a lógica gerada possa ser confiável.
Quando um requisito de negócio muda mais rápido do que um agente consegue absorver o feedback, o engenheiro precisa criar campos de contenção. Camadas semânticas rigorosas, registros de eventos imutáveis, contratos de dados, APIs idempotentes e máquinas de estado determinísticas não são apenas boas práticas de plataforma. Elas reduzem o número de suposições que um agente precisa fazer simultaneamente.
Eles transformam um problema acoplado em um domínio limitado com entradas claras, regras explícitas e feedback confiável.
Uma vez que esse domínio existe, o agente se torna verdadeiramente poderoso. Ele pode escrever a transformação, executar os testes, corrigir as falhas e implementar a alteração sem precisar inferir o histórico não escrito por trás de cada tabela e serviço.
O valor da engenharia de software não desaparece à medida que a geração de código se torna mais barata — ele se torna mais visível, e essa é a mudança que realmente importa.
Os sistemas autônomos gerarão cada vez mais software. Mas os contratos, os ciclos de feedback e os limites que determinam se esse software terá sucesso ou se transformará em caos ainda serão projetados por engenheiros de software.
Ananth Packkildurai é um líder em engenharia de dados, escritor e autor do Data Engineering Weekly, onde compartilha insights sobre plataformas de dados modernas, pipelines de grande escala e arquiteturas orientadas por IA.
.jpg)
.webp)
.webp)
.jpeg)
