De n8n para código: quando um fluxo com IA vira produto

n8n é ótimo para prototipar automação com IA. Veja os sinais de que um fluxo precisa virar código: testes, versionamento, permissões, multi-tenant e custo.

Entre 2024 e janeiro de 2026, na PowerX, eu montei fluxos com LangChain, Ollama e n8n ligados a dados internos e APIs. Hoje construo apps e agentes de IA direto em código, com Claude Code e Codex. Este texto não é uma lista de defeitos do n8n. É uma comparação de engenharia: para que ferramentas visuais de automação com IA servem bem, e em que ponto um fluxo pede para virar código.

O que o n8n faz bem

Ferramenta visual de fluxo resolve muito problema real. Os pontos fortes são claros:

• Prototipar rápido. Você liga um webhook a uma API e a uma planilha em minutos e vê os dados passando por cada etapa.
• Integração simples. Copiar um registro de um sistema para outro, mandar um aviso quando algo muda, agendar uma rotina. Para isso, um nó pronto vale mais que um SDK.
• Visibilidade para quem não programa. O desenho do fluxo serve como documentação. Uma pessoa de operação entende o que acontece sem ler código.
• Testar uma ideia de agente de IA. Encadear um modelo, uma busca e uma resposta para ver se a ideia para em pé é exatamente o tipo de coisa em que o canvas brilha.

Se o fluxo tem poucos passos, um dono só e erro que dá para corrigir na mão, eu não vejo motivo para trocar. Código custa mais para começar.

Os dados de busca mostram uma mudança

No Google Trends, comparando o primeiro com o último trimestre de um período de 12 meses, as buscas por "n8n" caíram cerca de 58% no Brasil e pela metade no mundo. No mesmo período, "Claude Code" cresceu quase 5 vezes no Brasil e dobrou no mundo. Isso não prova que uma ferramenta é melhor que a outra. Mostra que muita gente está procurando uma alternativa ao n8n, ou pelo menos olhando para o lado: escrever o agente em código ficou mais barato quando um assistente de código faz boa parte da digitação.

Sinais de que o fluxo virou produto

O problema não é o n8n. O problema é quando o fluxo deixa de ser automação interna e passa a ser produto: tem usuários, dados de terceiros, dinheiro e regras que não podem quebrar. Estes são os sinais que eu uso.

1. Você precisa de testes

Num fluxo visual, testar costuma ser rodar de novo e olhar a saída. Funciona até a décima regra. Depois disso, cada mudança pode quebrar um caso antigo sem ninguém ver.

No LedgerJob, um SaaS para empresas de construção nos EUA, o backend tem 59 arquivos de teste (Vitest) com 347 casos declarados. Um bug real mostra por que isso importa: o assistente conseguia agendar um compromisso "das 18h às 17h". A correção levou a regra para a camada de serviço, com um teste que garante que ela não volta.

2. Você precisa versionar e revisar

Um fluxo exportado é um JSON grande, com posição de cada nó na tela. Dá para guardar no Git, mas o diff mistura mudança de lógica com mudança de layout. Revisar isso num pull request é difícil.

Em código, a mudança aparece como mudança. Uma ferramenta nova do agente é um arquivo, com tipo, descrição e schema. O revisor lê a regra, não a posição de uma caixa.

3. Permissões e multi-tenant

Quando várias empresas usam o mesmo sistema, cada leitura precisa saber de quem é o dado. Isso é fácil de esquecer num nó e difícil de auditar depois.

No Reachant, um gerador de listas de prospecção B2B, toda leitura passa por uma função scoped(Model) que lança erro se não houver conta definida. Uma rota sem esse guard falha alto em vez de devolver dados de outra conta. No LedgerJob, a identidade vem da API key, nunca do modelo: a chave carrega empresa, usuário e papel, e o servidor MCP age como aquele usuário, com os mesmos limites.

4. Muitas ferramentas para o mesmo agente

Um agente de IA com três ferramentas cabe bem num canvas. Com dezenas, o desenho vira um mapa que ninguém lê, e a mesma ação acaba duplicada em dois fluxos.

O LedgerJob tem uma lista única de 66 ferramentas. Ela serve ao chat interno e ao servidor MCP ao mesmo tempo. Ferramenta nova aparece nos dois lugares no mesmo deploy, sem código duplicado. Um exemplo genérico do formato:

// exemplo genérico, não é código do projeto
export const sendQuoteEmail: AgentTool = {
  name: "send_quote_email",
  description: "IRREVERSIBLE. Envia o orçamento por e-mail ao cliente.",
  requiresConfirmation: true,
  input: z.object({ quoteId: z.string().uuid() }),
  run: (ctx, { quoteId }) => quotes.sendEmail(ctx, quoteId),
};

Schema tipado, flag de confirmação e regra chamando o service. Tudo isso é testável e aparece no diff.

5. Ações que não podem voltar atrás

Enviar e-mail, mandar SMS, gastar com terceiros, apagar dados. Num fluxo automático, essas ações rodam quando o nó é alcançado. Num produto com agente de IA, você quer um freio.

No LedgerJob, 16 das 66 ferramentas exigem confirmação humana. A ação irreversível não roda dentro do loop do agente: vira um card que o usuário confirma com um clique. O resultado volta ao histórico, para o modelo não afirmar que fez algo que não aconteceu.

6. Regra de negócio fora da rota

Um detalhe que só aparece quando o mesmo sistema tem mais de uma porta de entrada. No LedgerJob, a regra de negócio fica no service, não na rota, porque o agente e o MCP não passam pelo validador HTTP. Em fluxo visual, a validação tende a ficar no nó de entrada. Se surge uma segunda entrada, a regra precisa ser copiada.

7. Observabilidade e controle de custo

Agente chama modelo, e modelo cobra por token. Fornecedor de dados cobra por chamada. Sem limite explícito, uma resposta grande ou um loop sem fim vira conta.

No LedgerJob, o loop do agente tem teto de 8 iterações por turno, e o resultado de cada ferramenta é cortado em 6.000 caracteres para uma listagem grande não estourar o contexto. No Reachant, os créditos são debitados com um UPDATE condicional, então dois workers não gastam o mesmo saldo. Sem saldo, a etapa paga é pulada e o lead fica com os dados básicos. Cada débito registra o custo do fornecedor num ledger. Esse tipo de regra é poucas linhas em código, com teste.

Uma alternativa ao n8n não é outra ferramenta visual

Quando um fluxo cruza esses sinais, trocar por outro canvas resolve pouco. O que resolve é ter as práticas normais de software: testes, tipos, revisão, deploy versionado.

O Reachant é um exemplo dessa troca. Ele substituiu um scraper antigo de Google Maps por um produto com busca fora da requisição, num pool de threads, scraping que bloqueia IPs privados e revalida cada redirect, webhook do Stripe idempotente e 558 funções de teste pytest em 82 arquivos, mais 17 no pacote MCP. Nenhuma dessas partes é exótica. Juntas, são o que separa um script que roda de um sistema que outra pessoa pode usar.

Como eu decido hoje

Uma regra simples:

• Fica no fluxo visual: poucos passos, um dono, sem dados de clientes de terceiros, erro barato.
• Vai para código: qualquer um destes aparece: precisa de teste, mais de uma pessoa mexe, há mais de um cliente no mesmo sistema, o agente tem muitas ferramentas, alguma ação é irreversível, ou o custo por execução importa.

Escrever código também ficou mais rápido. Desenvolvo com Claude Code: o LedgerJob, por exemplo, foi construído assim, e eu arquitetei o backend, o agente e o servidor MCP. O assistente acelera a digitação. As decisões de arquitetura, os limites e os testes continuam sendo o trabalho de engenharia.

Se você tem um fluxo de automação com IA que começou a pedir essas coisas, fale comigo.