- Título:
- De cinco dias para trinta minutos: IA numa esteira de ETL
Quando assumi a operação de dados na Liquid AI, receber a base de um cliente e entregá-la pronta na pipeline levava em torno de cinco dias. Quando saí, em setembro de 2026, levava até trinta minutos.
Esse número costuma provocar a pergunta errada: "qual modelo vocês usaram?". O ganho não veio de um modelo. Veio de tirar o trabalho manual do caminho, pôr a IA onde ela de fato ajuda, cercar com testes o que ela pode errar e transformar o prazo numa regra do sistema, e não numa planilha.
Este texto conta como foi, sem nomes de cliente e sem dados. O que importa aqui é a arquitetura e as decisões.
O problema
A esteira transforma bases de incorporadoras em indicadores de financiamento imobiliário dentro dos produtos da empresa. São mais de vinte clientes, e cada um manda seus dados do seu jeito: formatos diferentes, colunas com nomes diferentes, convenções diferentes para a mesma informação.
Antes, cada base era um pequeno projeto. Alguém recebia o arquivo, quase sempre uma planilha, entendia o formato daquela vez, tratava os dados à mão e só então colocava na pipeline. O tratamento era um conjunto de notebooks rodados um cliente de cada vez, e o conhecimento de "como a base do cliente X costuma vir" morava na cabeça de quem já tinha feito.
E o controle de tudo isso vivia numa ferramenta de terceiros, desconectada do trabalho. Saber em que fase estava cada base, quem era o responsável e se ia atrasar dependia de alguém atualizar um quadro.
Cinco dias não eram cinco dias de processamento. Eram cinco dias de fila, de espera e de retrabalho.
Primeiro, a automação. Depois, a IA
A tentação, em 2026, é começar pela IA. Eu comecei pelo contrário: automatizar tudo o que era previsível.
A leitura e a preparação dos dados viraram serviços, disparados por chamada e não por pessoa. O desenho separa o que muda do que não muda: o jeito de ler a base de cada cliente fica nas bordas, e a regra que prepara os dados fica estável no meio. Cliente novo vira uma peça nova na borda, não um if a mais no meio da regra. (O nome disso é arquitetura hexagonal; a engine é escrita em Python e roda no Google Cloud.)
A IA entra depois, ajudando naquilo que é ambíguo: o que uma regra fixa não resolve bem, porque cada cliente descreve a mesma coisa de um jeito. Ela acelera a parte que antes exigia uma pessoa interpretando o arquivo. O que é previsível continua em regra fixa.
Essa ordem importa. IA em cima de um processo manual só deixa o processo manual mais rápido de errar. IA em cima de um processo automatizado resolve a sobra que a automação não alcança.
A operação ganhou um produto
O segundo movimento foi tirar o controle da ferramenta de terceiros e trazer para dentro de casa. Construí o Play Manager, um produto interno que virou a fonte da verdade da operação: fase, responsável, prazo e saúde de cada base, num lugar só, para o time e para a liderança. (Por baixo, React 19 e uma API própria em Hono sobre Firebase, com controle de acesso por papel e um editor de insights assistido por IA.)
O passo que fez diferença foi levar a automação para dentro dele. A preparação dos dados passou a ser disparada pela própria tela, e não por alguém rodando um script. Três propriedades sustentam isso:
- Fila. Cada base entra numa fila em vez de competir por atenção, e nada se perde porque alguém esqueceu.
- Repetir não estraga. Disparar duas vezes a mesma etapa não duplica o resultado. Parece detalhe até alguém clicar duas vezes num botão, ou até uma etapa falhar no meio e precisar ser refeita. (Em engenharia, isso se chama idempotência.)
- Uma etapa puxa a próxima. Quando uma etapa termina, a próxima entra na fila sozinha. A esteira anda sem alguém empurrar.
É aqui que boa parte dos cinco dias desaparece. Não porque algo processa mais rápido, mas porque a base não fica parada esperando a próxima pessoa.
Como as peças se conectam
Os dados continuam chegando em vários formatos, e quase sempre sobem pelo próprio card da base. Dali em diante, nada depende de alguém lembrar: todo trabalho entra numa fila, cada etapa concluída avança o card e põe a próxima na fila, e uma base com problema não segura as outras. Quando algo sai do esperado, o card mostra um alerta em vez de travar a esteira. O controle é a ação aparecer só quando dá para executá-la, em vez de um bloqueio que alguém precisa destravar.
O prazo virou regra do produto
Prazo em planilha é uma intenção. Descobre-se o atraso depois que ele aconteceu.
No Play Manager, o prazo de entrega é regra do sistema. Cada fase tem um orçamento de tempo, e cada base é classificada automaticamente em uma de três situações: no prazo, em risco ou atrasada.
Cada fase tem dono: preparar a base é do time de dados, e daí em diante é dos analistas. O responsável troca sozinho quando a base muda de fase, então ninguém precisa lembrar de passar o bastão.
A diferença entre "em risco" e "atrasada" é o ponto todo. Com ela, a gestão vê o atraso chegando enquanto ainda dá para agir, em vez de constatá-lo depois do vencimento. A conversa deixa de ser "por que atrasou?" e vira "o que fazemos com essa que está em risco?".
Onde a IA pode errar, testes
Uma esteira de dados tem um modo de falha cruel: ela não quebra, ela entrega errado. Um número preparado de um jeito sutilmente diferente passa por todas as etapas, chega ao indicador e ninguém percebe.
Por isso a velocidade veio junto com uma rede de testes:
- A engine de preparação é sustentada por mais de 4.800 testes automáticos. Os que mais importam numa mudança assim são os que comparam o resultado de antes com o de depois, para garantir que uma alteração não muda o que deveria continuar igual.
- Dois pipelines que já rodavam em produção não tinham nenhum teste automatizado. Escrevi 920 testes, levei a cobertura de 0% para 84% e 92%, e o deploy passou a ser bloqueado sempre que a suíte falhava.
Com IA no meio do processo, isso deixa de ser boa prática e vira requisito. O teste é o que permite deixar a IA ajudar sem ter que conferir cada saída à mão. Vale para o código também: o que eu escrevia com IA passava por teste antes e por portões antes de cada commit, e contei esse fluxo em Fluxo RPI com três agentes.
A virada sem trauma
Ferramenta nova costuma falhar por um motivo que não é técnico: o time precisa reaprender a trabalhar.
Conduzi a migração replicando no Play Manager os padrões de interação que o time já dominava na ferramenta anterior. Quem usava o sistema antigo encontrava no novo os mesmos caminhos. A carteira inteira migrou sem nenhuma divergência que bloqueasse a operação.
Não foi a parte mais interessante tecnicamente, mas foi uma das que mais pesaram no resultado. Um produto melhor que ninguém adota não reduz prazo nenhum.
O que fica
Se eu tivesse que resumir em três decisões:
- Automatizar antes de pôr IA. A IA resolve a sobra ambígua; o que é previsível vira código.
- Tirar a fila da cabeça das pessoas. Fila, repetição segura e uma etapa puxando a próxima fazem a base andar sozinha.
- Transformar intenção em regra. Prazo com orçamento por fase, deploy bloqueado quando o teste falha. O que depende de alguém lembrar acaba esquecido.
Os cinco dias não sumiram porque um modelo ficou mais esperto. Sumiram porque o trabalho parou de esperar.
sys.exit(0)
---
title: De cinco dias para trinta minutos: IA numa esteira de ETL
url: https://nandomoreira.dev/de-cinco-dias-para-trinta-minutos
date: 2026-10-15
---
Quando assumi a operação de dados na Liquid AI, receber a base de um cliente e entregá-la pronta na pipeline levava em torno de cinco dias. Quando saí, em setembro de 2026, levava até trinta minutos.
Esse número costuma provocar a pergunta errada: "qual modelo vocês usaram?". O ganho não veio de um modelo. Veio de tirar o trabalho manual do caminho, pôr a IA onde ela de fato ajuda, cercar com testes o que ela pode errar e transformar o prazo numa regra do sistema, e não numa planilha.
Este texto conta como foi, sem nomes de cliente e sem dados. O que importa aqui é a arquitetura e as decisões.
## O problema
A esteira transforma bases de incorporadoras em indicadores de financiamento imobiliário dentro dos produtos da empresa. São mais de vinte clientes, e cada um manda seus dados do seu jeito: formatos diferentes, colunas com nomes diferentes, convenções diferentes para a mesma informação.
Antes, cada base era um pequeno projeto. Alguém recebia o arquivo, quase sempre uma planilha, entendia o formato daquela vez, tratava os dados à mão e só então colocava na pipeline. O tratamento era um conjunto de notebooks rodados um cliente de cada vez, e o conhecimento de "como a base do cliente X costuma vir" morava na cabeça de quem já tinha feito.
E o controle de tudo isso vivia numa ferramenta de terceiros, desconectada do trabalho. Saber em que fase estava cada base, quem era o responsável e se ia atrasar dependia de alguém atualizar um quadro.
Cinco dias não eram cinco dias de processamento. Eram cinco dias de fila, de espera e de retrabalho.
## Primeiro, a automação. Depois, a IA
A tentação, em 2026, é começar pela IA. Eu comecei pelo contrário: automatizar tudo o que era previsível.
A leitura e a preparação dos dados viraram serviços, disparados por chamada e não por pessoa. O desenho separa o que muda do que não muda: o jeito de ler a base de cada cliente fica nas bordas, e a regra que prepara os dados fica estável no meio. Cliente novo vira uma peça nova na borda, não um `if` a mais no meio da regra. (O nome disso é arquitetura hexagonal; a engine é escrita em Python e roda no Google Cloud.)
A IA entra depois, ajudando naquilo que é ambíguo: o que uma regra fixa não resolve bem, porque cada cliente descreve a mesma coisa de um jeito. Ela acelera a parte que antes exigia uma pessoa interpretando o arquivo. O que é previsível continua em regra fixa.
Essa ordem importa. IA em cima de um processo manual só deixa o processo manual mais rápido de errar. IA em cima de um processo automatizado resolve a sobra que a automação não alcança.
## A operação ganhou um produto
O segundo movimento foi tirar o controle da ferramenta de terceiros e trazer para dentro de casa. Construí o Play Manager, um produto interno que virou a fonte da verdade da operação: fase, responsável, prazo e saúde de cada base, num lugar só, para o time e para a liderança. (Por baixo, React 19 e uma API própria em Hono sobre Firebase, com controle de acesso por papel e um editor de insights assistido por IA.)
O passo que fez diferença foi levar a automação para dentro dele. A preparação dos dados passou a ser disparada pela própria tela, e não por alguém rodando um script. Três propriedades sustentam isso:
- **Fila.** Cada base entra numa fila em vez de competir por atenção, e nada se perde porque alguém esqueceu.
- **Repetir não estraga.** Disparar duas vezes a mesma etapa não duplica o resultado. Parece detalhe até alguém clicar duas vezes num botão, ou até uma etapa falhar no meio e precisar ser refeita. (Em engenharia, isso se chama idempotência.)
- **Uma etapa puxa a próxima.** Quando uma etapa termina, a próxima entra na fila sozinha. A esteira anda sem alguém empurrar.
É aqui que boa parte dos cinco dias desaparece. Não porque algo processa mais rápido, mas porque a base não fica parada esperando a próxima pessoa.
## Como as peças se conectam
Os dados continuam chegando em vários formatos, e quase sempre sobem pelo próprio card da base. Dali em diante, nada depende de alguém lembrar: todo trabalho entra numa fila, cada etapa concluída avança o card e põe a próxima na fila, e uma base com problema não segura as outras. Quando algo sai do esperado, o card mostra um alerta em vez de travar a esteira. **O controle é a ação aparecer só quando dá para executá-la**, em vez de um bloqueio que alguém precisa destravar.
## O prazo virou regra do produto
Prazo em planilha é uma intenção. Descobre-se o atraso depois que ele aconteceu.
No Play Manager, o prazo de entrega é regra do sistema. Cada fase tem um orçamento de tempo, e cada base é classificada automaticamente em uma de três situações: **no prazo**, **em risco** ou **atrasada**.
Cada fase tem dono: preparar a base é do time de dados, e daí em diante é dos analistas. O responsável troca sozinho quando a base muda de fase, então ninguém precisa lembrar de passar o bastão.
A diferença entre "em risco" e "atrasada" é o ponto todo. Com ela, a gestão vê o atraso chegando enquanto ainda dá para agir, em vez de constatá-lo depois do vencimento. A conversa deixa de ser "por que atrasou?" e vira "o que fazemos com essa que está em risco?".
## Onde a IA pode errar, testes
Uma esteira de dados tem um modo de falha cruel: ela não quebra, ela entrega errado. Um número preparado de um jeito sutilmente diferente passa por todas as etapas, chega ao indicador e ninguém percebe.
Por isso a velocidade veio junto com uma rede de testes:
- A engine de preparação é sustentada por mais de **4.800 testes automáticos**. Os que mais importam numa mudança assim são os que comparam o resultado de antes com o de depois, para garantir que uma alteração não muda o que deveria continuar igual.
- Dois pipelines que já rodavam em produção não tinham **nenhum teste automatizado**. Escrevi 920 testes, levei a cobertura de 0% para **84% e 92%**, e o deploy passou a ser bloqueado sempre que a suíte falhava.
Com IA no meio do processo, isso deixa de ser boa prática e vira requisito. O teste é o que permite deixar a IA ajudar sem ter que conferir cada saída à mão. Vale para o código também: o que eu escrevia com IA passava por teste antes e por portões antes de cada commit, e contei esse fluxo em [Fluxo RPI com três agentes](/fluxo-rpi-claude-code-grok-codex).
## A virada sem trauma
Ferramenta nova costuma falhar por um motivo que não é técnico: o time precisa reaprender a trabalhar.
Conduzi a migração replicando no Play Manager os padrões de interação que o time já dominava na ferramenta anterior. Quem usava o sistema antigo encontrava no novo os mesmos caminhos. A carteira inteira migrou sem nenhuma divergência que bloqueasse a operação.
Não foi a parte mais interessante tecnicamente, mas foi uma das que mais pesaram no resultado. Um produto melhor que ninguém adota não reduz prazo nenhum.
## O que fica
Se eu tivesse que resumir em três decisões:
1. **Automatizar antes de pôr IA.** A IA resolve a sobra ambígua; o que é previsível vira código.
2. **Tirar a fila da cabeça das pessoas.** Fila, repetição segura e uma etapa puxando a próxima fazem a base andar sozinha.
3. **Transformar intenção em regra.** Prazo com orçamento por fase, deploy bloqueado quando o teste falha. O que depende de alguém lembrar acaba esquecido.
Os cinco dias não sumiram porque um modelo ficou mais esperto. Sumiram porque o trabalho parou de esperar.
`sys.exit(0)`