n8n vs codice custom per l'automazione AI: cosa comprare, cosa costruire

Usate un motore di workflow come n8n quando l'automazione è interna, a basso volume, e un'esecuzione fallita è un fastidio piuttosto che un cliente perso. Scrivete codice custom quando il flusso coinvolge i clienti, gira migliaia di volte al giorno, richiede test veri, o contiene un prompt LLM che continuerete ad affinare. L'errore costoso non è scegliere quello sbagliato. È scegliere uno dei due e rifiutarsi di cambiare quando i segnali dicono che lo avete superato.

Perché questa domanda si pone adesso

n8n è diventato la risposta di default quando un founder dice "dovremmo automatizzare questo con l'AI". È source-available sotto la Sustainable Use License proprietaria di n8n, potete auto-ospitarlo, e include nodi per la maggior parte degli strumenti SaaS oltre a nodi generici per LLM e HTTP. Chi non è un ingegnere può costruire qualcosa che funziona in un pomeriggio. Questo ha un valore genuino, ed è anche esattamente il motivo per cui i team finiscono con una dozzina di workflow fragili che nessuno osa toccare.

La decisione riguarda meno n8n contro codice e più quali parti della vostra automazione meritano disciplina ingegneristica. Abbiamo trattato la distinzione concettuale tra agenti e workflow in AI agents vs workflows. Questo articolo è la versione pratica, con i soldi sul tavolo.

In cosa n8n è davvero bravo

Siate onesti sui punti di forza, perché sono reali:

• Velocità verso una prima versione funzionante. L'autenticazione a Gmail, HubSpot, Slack, Notion e Postgres è un menu a tendina, non una settimana di idraulica OAuth.
• Visibilità per i non ingegneri. Le persone di ops e vendite possono leggere una canvas. Non possono leggere un servizio NestJS.
• Esperimenti economici. Potete testare se uno step LLM aggiunge valore prima che qualcuno scriva una riga di codice di produzione.
• Collante interno. "Quando una trattativa si chiude, crea una cartella, posta su Slack, prepara una bozza di email di onboarding" è il punto ideale. Il volume è basso, il fallimento è visibile, e c'è un umano nei dintorni.

Se la vostra automazione vive interamente in quella lista, fermatevi e costruitela in n8n. Assumere un'agenzia per questo è eccessivo.

Dove comincia a far male

I problemi arrivano gradualmente, e ognuno preso singolarmente sembra tollerabile.

I prompt diventano non testabili

Un prompt LLM dentro un nodo è una stringa in un database. Non c'è diff, non c'è review, non c'è una suite di eval. Quando la qualità dell'output peggiora, l'unico strumento di debug è rieseguire il workflow e scrutare il risultato. Confrontate questo con come vive il prompt nel nostro motore di outreach: un file versionato, un set fisso di siti web di prospect come fixture, e uno schema di output rigido che ogni email redatta deve soddisfare. Quando abbiamo cambiato la call to action da un link al calendario a "rispondi SÌ", è stato un diff di una riga che qualcuno poteva revisionare e annullare. Quando l'accuratezza dell'estrazione scende, un test fallisce in CI invece che un venditore se ne accorga una settimana dopo. Se siete seri sulla affidabilità, leggete guardrail deterministici per feature AI. Quasi nulla di tutto questo è ergonomico dentro un editor visuale.

La gestione degli errori è dove gli strumenti visuali perdono

Una pipeline reale ha bisogno di: retry con backoff, idempotenza affinché un retry non invii l'email due volte, gestione dead-letter per input che l'LLM non riesce a interpretare, e alerting quando un'esecuzione pianificata silenziosamente non avviene. Riprendiamo il motore di outreach. Un crawl di Firecrawl può andare in timeout su un sito prospect lento, l'LLM locale può restituire qualcosa che non supera lo schema di output, e un'esecuzione ritentata non deve inviare una seconda cold email alla stessa azienda. Ognuna di queste cose è possibile in n8n. Ognuna è anche un groviglio di nodi e rami extra che rende la canvas illeggibile, il che annulla l'unico vantaggio che la canvas aveva. Nel codice, questi sono pochi pattern ben conosciuti: un wrapper di retry attorno al crawl, un controllo di schema che instrada i fallimenti verso una coda di revisione, e un flag "inviato" per azienda controllato prima che qualcosa parta.

Il volume cambia le economie

A dieci esecuzioni al giorno, a nessuno importa come viene eseguito un workflow. A diecimila, vi importa di concorrenza, profondità delle code, e di come i log di esecuzione vengono archiviati e ripuliti. n8n può essere scalato in queue mode, ma a quel punto state comunque gestendo infrastruttura, e avete assunto il costo operativo di un motore di workflow senza ottenere la testabilità del codice. A quel punto potreste tanto valere possedere direttamente il codice.

Proprietà e lock-in

La licenza di n8n è permissiva per l'uso interno ma limita l'offerta come servizio ospitato ad altri. Se l'automazione fa parte di ciò che vendete, controllate la licenza con qualcuno che sappia leggere le licenze, e assumete che la logica dovrebbe vivere in codice interamente vostro. Lo stesso vale per qualsiasi cosa con esposizione a compliance: audit log, residenza dei dati e controllo degli accessi sono più facili da dimostrare quando il flusso è un servizio che controllate end to end.

Un esempio concreto dal nostro stack

Facciamo girare il nostro motore di outreach su codice custom, non su uno strumento di workflow, e il motivo è istruttivo. La pipeline esegue il crawl del sito web di ogni prospect con un'istanza Firecrawl auto-ospitata, passa il contenuto a un LLM locale, e produce un'email su misura per azienda. L'istinto iniziale era una catena multi-step: una chiamata per estrarre i fatti, un'altra per scegliere un angolo, un'altra per redigere il testo. L'abbiamo provata e abbiamo anche provato una singola chiamata che estrae i fatti e redige l'email insieme, con uno schema di output rigido. La versione a singola chiamata ha vinto sia su costo che su qualità. Approfondiamo il perché in single call vs agent chains.

Il punto rilevante qui: scoprirlo ha richiesto decine di esecuzioni controllate contro lo stesso set di fixture, confrontando gli output fianco a fianco, e cambiando una variabile alla volta. Questo è un test harness, ed è banale in un repository TypeScript. È miserabile in una canvas drag-and-drop. Se avessimo costruito il motore in n8n, probabilmente staremmo ancora facendo girare la catena più lenta e più costosa perché il costo di sperimentare sarebbe stato troppo alto.

La seconda lezione dallo stesso strumento: il miglioramento più grande nel tasso di risposta è venuto da un cambio di copy, non da un cambio di modello. Spostare la call to action da un link al calendario a un soft "rispondi SÌ" ha costantemente ottenuto più risposte da prospect freddi. Quel cambiamento è costato una riga in un prompt versionato. Poterlo fare e misurare in modo economico è l'intero argomento a favore del codice quando il flusso conta per il fatturato.

Un framework decisionale applicabile in dieci minuti

Valutate ogni automazione su queste cinque domande. Tre o più risposte "sì" significa costruirla nel codice.

1. Un cliente vede l'output direttamente? Email, risposte WhatsApp, preventivi, risposte di supporto.
2. Girerà più di qualche centinaio di volte al giorno nel giro di un anno?
3. Contiene uno step LLM la cui qualità continuerete ad affinare? Estrazione, classificazione, redazione.
4. Un'esecuzione fallita o duplicata costa denaro o fiducia? Doppio addebito, doppio invio, lead persi.
5. Tocca dati regolamentati o sensibili? Sanità, finanza, pubblica amministrazione, dati personali di residenti UE o del Golfo.

Zero o un "sì": n8n, costruito da chi possiede il processo. Due: n8n per l'orchestrazione, ma mantenete prompt e regole di business in un piccolo servizio di codice che n8n richiama via HTTP. Questo approccio ibrido è sottovalutato. Mantiene la canvas leggibile per le ops mentre dà all'ingegneria un nucleo testato e versionato. Tre o più: codice, con n8n al massimo come fonte di trigger.

Com'è l'ibrido in pratica

• Una piccola API NestJS o Next.js con un endpoint per capacità: extract-company-facts, draft-email, qualify-lead.
• Prompt, schemi Zod per l'output strutturato, e fixture vivono nel repository e girano in CI.
• n8n gestisce i bordi noiosi: trigger cron, prelievo dal CRM, posting su Slack.
• Quando i requisiti di volume o affidabilità crescono, sostituite l'orchestrazione n8n con una coda. Nulla nella logica cambia.

Questo rende anche più facile la questione delle assunzioni. Potete far fare il collegamento n8n a una persona di ops o a un freelancer. Portate ingegneri per il servizio, che è la parte che richiede test e un piano di manutenzione. Per capire come si presenta realisticamente questo costo continuativo, vedete il vero costo di manutenzione di un agente AI.

Cosa chiedere a chiunque assumiate

• "Quali parti di questo terreste deliberatamente fuori da n8n, e perché?" Una buona risposta nomina prompt, retry e idempotenza.
• "Come testeremo un cambio di prompt prima che vada live?" Se la risposta è "eseguire il workflow e controllare", continuate a cercare.
• "Cosa succede quando l'LLM restituisce spazzatura alle 3 del mattino?" Volete sentire dead-letter queue, alert, e un passaggio di revisione umana.
• "Chi possiede i prompt e gli schemi, e dove vivono?" La risposta dovrebbe essere "voi, nel vostro repository".

La versione breve

n8n è un ottimo strumento di prototipazione e una buona casa per il collante interno. È una casa povera per la logica AI che guida il fatturato, perché quella logica ha bisogno di esperimenti, test e storico delle versioni, e gli strumenti visuali rendono tutti e tre costosi. Prototipate in n8n, dimostrate il valore, poi spostate il nucleo nel codice che possedete. Se volete aiuto a tracciare quella linea per il vostro stack specifico, parliamone.