# 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.

2026-10-15 · Gustavo Karsten

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](https://gustavokarsten.com/projects/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](https://gustavokarsten.com/projects/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:

```ts
// 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](https://gustavokarsten.com/contact).

---
Página: https://gustavokarsten.com/articles/de-n8n-para-codigo
Contato: gustavo.karsten@outlook.com · https://www.linkedin.com/in/gustavo-karsten-88a04383/ · https://github.com/gustavo-karsten