Un’automazione che funziona in demo e un’automazione che regge la produzione sono due cose diverse. La demo la costruisci in un pomeriggio, la produzione la mantieni per due anni. Ed è nella manutenzione che l’approccio scelto, workflow visuale o codice, inizia a mostrare il conto.
Per capire davvero la differenza ho costruito lo stesso sistema editoriale (autopublisher AI collegato a WordPress, Brevo, storage e un modello LLM) prima con n8n, poi riscritto interamente in codice. Non era un esercizio teorico: serviva capire dove il visuale bastava e dove iniziava a costare più di quanto rendeva. Di seguito i criteri operativi che ne ho tirato fuori, con esempi concreti su cosa cambia in ogni fase.
Cosa fa n8n e cosa fa il codice, senza mitologia
n8n è una piattaforma di workflow automation open source. Costruisci l’automazione trascinando nodi su un canvas: ogni nodo è un’operazione (una chiamata HTTP, una trasformazione dati, un branch condizionale). Sotto il cofano è un motore JavaScript che esegue i nodi in sequenza o in parallelo, con supporto a webhook, cron, code interne. Puoi self-hostarlo con Docker o usare la versione cloud.
Scrivere la stessa automazione “in codice” significa un progetto software con una struttura precisa: linguaggio (tipicamente Python, TypeScript, Go), un orchestratore (uno script principale, oppure un framework come Prefect, Temporal, Celery), gestione delle dipendenze (poetry, npm, uv), test automatici, versionamento su Git, deploy su un server o container. Non è più complicato in assoluto: è più esplicito, e ogni pezzo lo devi mettere tu.
La differenza vera non è “clicchi vs scrivi”. È il modello di gestione del cambiamento: nel visuale il cambiamento è locale (sposti un nodo, riconnetti un cavo); nel codice il cambiamento è tracciato (commit, diff, review).
Lo stesso sistema in due versioni: cosa è cambiato davvero
Il sistema in questione prende un topic, fa content gap analysis, genera l’articolo con un modello LLM, applica una skill di humanization, salva la bozza su WordPress via REST API, notifica su Brevo. Sette step logici, tre servizi esterni, un modello AI.
Versione n8n
Tempo di costruzione della prima versione funzionante: circa quattro ore. Il canvas mostra a colpo d’occhio il flusso, e questo aiuta quando devi spiegarlo a qualcuno. I nodi HTTP Request coprono le chiamate a WordPress e Brevo, il nodo OpenAI/Anthropic gestisce la chiamata al modello, un nodo Function permette di iniettare JavaScript quando la trasformazione dati diventa complessa.
Problemi emersi in produzione:
- Debug faticoso quando la logica cresce. Con dodici nodi tutto è leggibile. A venticinque nodi con tre branch condizionali, capire dove si è rotto qualcosa richiede aprire ogni execution e ispezionare i payload uno a uno.
- Il nodo Function diventa il buco nero. Ogni volta che la logica supera il “prendi campo A e mettilo in B”, finisce dentro un nodo Function con codice JavaScript non versionato, non testato, non riutilizzabile fuori da quel workflow.
- Le modifiche non sono diff-abili. n8n esporta il workflow in JSON, ma il diff tra due versioni è illeggibile: cambia l’ordine di serializzazione dei nodi anche quando la logica non è cambiata.
- Riutilizzo limitato. Se ho tre workflow che chiamano WordPress con la stessa autenticazione e trasformazione, mi ritrovo tre copie della stessa logica. I sub-workflow aiutano ma non risolvono.
Versione in codice
Tempo di riscrittura: circa tre giornate, con test. Struttura del progetto:
autopublisher/
├── pyproject.toml
├── src/
│ ├── clients/
│ │ ├── wordpress.py # wrapper REST API
│ │ ├── brevo.py
│ │ └── llm.py
│ ├── pipeline/
│ │ ├── gap_analysis.py
│ │ ├── generate.py
│ │ ├── humanize.py
│ │ └── publish.py
│ ├── orchestrator.py # esegue la pipeline
│ └── config.py
├── tests/
└── .github/workflows/deploy.yml
Ogni client esterno è una classe con metodi tipizzati. La pipeline è una sequenza di funzioni pure che prendono uno stato e restituiscono lo stato modificato. L’orchestratore è uno script di 40 righe che le chiama in ordine.
Cosa è migliorato in produzione:
- Debug con strumenti veri. Log strutturati, breakpoint, replay locale con dati di produzione anonimizzati. Un errore lo isolo in minuti.
- Test. Ogni step della pipeline ha test unitari con mock delle chiamate esterne. Prima di andare in produzione so se la modifica rompe qualcosa.
- Versionamento reale. Ogni modifica è un commit con diff leggibile. Se una release rompe qualcosa, faccio rollback con un comando.
- Riuso. Il client WordPress lo importo anche in altri progetti. Non lo riscrivo tre volte.
Cosa è peggiorato: la leggibilità “a colpo d’occhio” per un non-sviluppatore. Il canvas di n8n si spiega a chiunque in trenta secondi. La cartella di codice no.
I criteri di scelta, in ordine di peso
Complessità della pipeline
Regola pratica: se il flusso ha meno di quindici step logici, poche condizioni, poche trasformazioni dati non banali, il visuale basta e avanza. Se supera i venti step, o ha logiche condizionali annidate su tre livelli, il codice diventa più economico da mantenere anche se costa di più da scrivere all’inizio.
Frequenza di modifica
Un workflow che tocchi una volta al mese vive bene su n8n. Un workflow che modifichi due volte a settimana perché stai iterando sulla logica di business, in visuale ti brucia tempo: ogni modifica è un click-e-verifica manuale. In codice hai i test che ti dicono se hai rotto qualcosa in trenta secondi.
Chi lo mantiene
Se la persona che manutiene l’automazione non scrive codice, n8n è l’unica scelta ragionevole. Se sei tu che scrivi codice e sei tu che mantieni, il codice ti costa meno nel lungo periodo. Se il team è misto, valuta se il visuale copre il 90% dei casi e il codice serve solo per le librerie condivise.
Integrazioni disponibili
n8n ha oltre 400 nodi pre-costruiti. Se la tua automazione tocca Google Sheets, Slack, Airtable, Notion, HubSpot, Stripe e simili, ti risparmi ore di lavoro. Se invece tocca sistemi custom (un gestionale interno, un’API poco documentata, un modello AI con chiamate particolari) la comodità dei nodi pre-fatti sparisce e ti ritrovi a scrivere codice dentro nodi Function.
Costo del cambiamento
È il criterio che nessuno considera all’inizio e che fa la differenza dopo un anno. Ogni modifica in un workflow n8n ha un costo di verifica manuale (apri, modifichi, esegui, guardi il risultato). In codice il costo è la stesura del test, ma da lì in poi ogni modifica è verificata gratis. Sotto una certa frequenza di modifica il visuale vince, sopra vince il codice. Il punto di pareggio, nella mia esperienza, sta intorno alle 2-3 modifiche al mese sostanziali sulla stessa automazione.
Osservabilità richiesta
Se ti basta sapere “è andato o non è andato”, n8n ti dà execution history e retry automatici. Se hai bisogno di metriche aggregate (quanti articoli generati per settore, quale step è più lento, quale prompt LLM produce più errori) il codice con logging strutturato e una dashboard tipo Grafana è un altro pianeta.
Quando il visuale inizia a costare più di quanto rende
Ci sono segnali precisi che indicano che sei fuori dal perimetro di comfort di n8n:
- Più di tre nodi Function con codice non banale. Se stai scrivendo logica dentro Function, tanto vale scriverla in un progetto vero.
- Workflow che chiamano altri workflow che chiamano altri workflow. La composizione visuale a più livelli diventa illeggibile in fretta.
- Necessità di test automatici. n8n non ha una story credibile sui test unitari. Se hai bisogno di garanzie prima di ogni deploy, il codice è obbligato.
- Modifiche in team con code review. Un diff JSON di n8n in una pull request è illeggibile. Il review si fa aprendo il canvas, cioè non si fa.
- Automazione che diventa prodotto. Quando l’automazione smette di essere un flusso interno e inizia a essere un componente di prodotto (magari esposto ai clienti), il codice è l’unica scelta seria.
Ho scritto nel dettaglio come è nato l’autopublisher AI e come la pipeline modulare a skill mi permetta oggi di gestire l’automazione con la stessa leggibilità del visuale, ma con i vantaggi del codice.
L’approccio ibrido, che è quello che funziona davvero
La domanda “n8n o codice” nella pratica è una falsa dicotomia. Il pattern che regge nel tempo è ibrido:
- n8n per l’orchestrazione di superficie: trigger (webhook, cron), routing, notifiche, integrazioni standard con SaaS di terze parti. Tutto quello che è “colla” tra servizi.
- Codice per la logica di business: generazione contenuti, elaborazione dati, chiamate a modelli AI con prompt strutturati, trasformazioni non banali. Il codice espone un endpoint HTTP che n8n chiama come un qualunque nodo esterno.
Così n8n resta uno strato di orchestrazione leggero e leggibile, mentre la logica complessa vive in un progetto versionato con test. Nessuno dei due strumenti fa cose per cui non è fatto. È lo stesso principio che applico quando parlo di automazioni AI messe in produzione nelle PMI: non conta la piattaforma, conta la separazione delle responsabilità.
Checklist prima di decidere
Prima di iniziare un’automazione, rispondi a queste sette domande. Se hai più di quattro “sì” nella colonna codice, non partire da n8n.
- L’automazione ha più di 15 step logici o condizioni annidate? → codice
- La modifichi più di 2 volte al mese? → codice
- La manutiene una persona che scrive codice? → codice
- Ha bisogno di test automatici prima del deploy? → codice
- Deve integrarsi con sistemi custom o API non standard? → codice
- Serve osservabilità con metriche aggregate? → codice
- La logica cambia in team con review? → codice
Se invece rispondi “no” a quasi tutte, n8n ti fa risparmiare settimane di lavoro senza costi nascosti significativi.
Domande frequenti
Posso iniziare in n8n e migrare in codice dopo?
Sì, ed è spesso la scelta più razionale. Costruisci il prototipo funzionante in n8n in poche ore, lo tieni in produzione finché regge, e quando inizi a sentire attrito (troppi nodi Function, modifiche frequenti, necessità di test) migri progressivamente in codice. La migrazione non è banale ma è fattibile: il workflow visuale ti serve come documentazione della logica da riprodurre.
n8n cloud o self-hosted?
Per uso personale o piccoli team, il cloud toglie il pensiero della manutenzione infrastrutturale. Se hai vincoli di conformità sui dati (GDPR con dati sensibili, dati che non possono uscire dall’UE su determinate condizioni) o volumi elevati, il self-hosted su un server dedicato o VPS diventa più conveniente sia per il controllo sia per il costo.
Quale linguaggio scegliere per la versione codice?
Se l’automazione è centrata su AI e trasformazione dati, Python è la scelta più ricca di librerie. Se il team è già su ecosistema JavaScript o l’automazione è web-heavy, TypeScript va benissimo. Evita di scegliere il linguaggio in base alla moda: scegli quello che tu o il team mantenete meglio.
Quanto costa mantenere un progetto in codice rispetto a n8n?
All’inizio il codice costa di più: setup del progetto, CI/CD, test, deploy. Superato quel costo iniziale (una settimana di lavoro solida), la manutenzione ordinaria costa meno del visuale su automazioni complesse. Su automazioni semplici e stabili n8n resta più economico a vita.
E strumenti come Make o Zapier al posto di n8n?
Il ragionamento è lo stesso: sono piattaforme di orchestrazione visuale con caratteristiche diverse. Zapier è il più semplice e il più costoso a volume, Make ha un modello di prezzo più aggressivo e una logica visuale più espressiva, n8n è l’unico self-hostabile con licenza fair-code. La scelta tra questi non cambia il criterio di fondo: sotto una certa complessità sono tutti validi, sopra una certa complessità serve codice.
Il punto operativo
Non esiste una risposta universale a “n8n o codice”. Esiste una risposta per la tua specifica automazione, che dipende da complessità, frequenza di modifica, chi la mantiene, integrazioni richieste e costo del cambiamento. La regola pratica che uso oggi è semplice: parti dal visuale se il flusso è lineare e stabile, passa al codice appena inizi a scrivere logica dentro nodi Function o a fare modifiche settimanali. E quando il progetto diventa serio, tieni entrambi: n8n per la colla, codice per la sostanza.
