No-code e low-code AI: cosa si può fare davvero senza essere programmatori

I programmatori sono diventati inutili, ovviamente no! È cambiato il momento in cui entrano in gioco.

No-code e low-code si citano quasi sempre in coppia, ma sono due approcci diversi. Con il no-code si lavora solo con l’interfaccia visuale e si accettano i limiti della piattaforma. Con il low-code si parte dallo stesso tipo di strumenti, ma quando serve si scrive del codice: una chiamata API, una query, una funzione personalizzata.

Finché si tratta di raccogliere dati da un modulo, aggiornare un foglio, mandare un’email o far leggere un documento a un modello AI, il no-code regge benissimo. I problemi arrivano con le regole di business complicate, con i gestionali, con i database che esistono da vent’anni. Lì qualche riga di codice fa comodo molto presto.

Non c’è una piattaforma migliore in assoluto: dipende da cosa si vuole costruire.
Bubble è tra i più completi per fare vere applicazioni web e mobile in modo visuale. Non è però immediato: appena l’app cresce bisogna capire database, workflow, condizioni e gestione degli utenti, cioè gli stessi concetti di un progetto tradizionale.
Glide è più veloce da imparare e dà il meglio quando c’è un foglio di calcolo (o un’altra fonte dati semplice) da trasformare in un’app per smartphone o browser.
Webflow resta uno strumento per siti web con un controllo fine sul design. Da qualche tempo ha aggiunto parecchie funzioni AI, tra cui un generatore di siti.

Per le automazioni i nomi sono Zapier, Make e n8n, tre modi diversi di far parlare applicazioni che da sole non si parlano. Zapier punta sulla semplicità e ha migliaia di integrazioni, più funzioni AI per creare i flussi. Make ha un editor più visuale e gestisce meglio flussi con filtri, rami e condizioni. n8n è pensato per chi ha un po’ più di dimestichezza tecnica: si può installare sui propri server, e per chi tratta dati sensibili non è un dettaglio.

Ci sono poi piattaforme dedicate agli agenti AI, come Relevance AI o FlowHunt, e le offerte dei grandi cloud. Google ha riunito i suoi strumenti (compreso l’ex Vertex AI Agent Builder) nella Gemini Enterprise Agent Platform. Microsoft ha il Foundry Agent Service. AWS, tra le altre cose, offre SageMaker Canvas per fare machine learning da interfaccia visuale. Sono strumenti potenti ma pensati per le aziende strutturate: senza qualche nozione di cloud, API e gestione dei dati si fa fatica a usarli bene.

Ma, di tutti questi strumenti cosa se ne fa, in pratica, una piccola impresa? Prendiamo un’azienda che riceve ogni giorno decine di email. Un’automazione può leggerle, distinguere una richiesta commerciale da una di assistenza, tirare fuori nome, prodotto e urgenza e inserire tutto nel gestionale. Un e-commerce può mettere un assistente AI a rispondere alle domande frequenti, pescando dal catalogo e dalle schede tecniche. Fatture, ordini e moduli in PDF possono essere letti dall’AI e i dati passati a un database senza ricopiarli a mano.

Poi ci sono i casi più banali, che spesso sono quelli che rendono di più. Il file Excel con cui da anni si gestiscono clienti e interventi diventa una piccola app sul telefono del tecnico; quando il commerciale inserisce un ordine, parte da sola la notifica al magazzino.
Non serve costruire la grande piattaforma AI: togliere venti operazioni ripetitive al giorno a una persona è già un risultato concreto.

Comunque, niente codice non vuol dire niente progettazione. E questo è l’equivoco più diffuso. Un’automazione deve sapere cosa fare quando manca un dato, quando un servizio esterno non risponde, quando qualcuno scrive “10,5” invece di “10.5” o quando due sistemi danno due numeri diversi per la stessa cosa. Finché il processo è marginale si può chiudere un occhio. Quando diventa importante, sono proprio questi casi a creare problemi.

Anche le integrazioni sono meno semplici di come sembrano nelle demo dei prodotti software. Collegare Gmail a un foglio Google è questione di minuti. Collegare un gestionale installato sul server in ufficio, un database locale e un servizio cloud è un altro discorso.

E poi ci sono sicurezza e privacy. Se nell’automazione passano dati di clienti, dipendenti o documenti riservati, non basta che la piattaforma funzioni: bisogna sapere dove vengono elaborati i dati, per quanto tempo restano lì, chi può vederli e cosa garantisce il fornitore, anche ai fini del GDPR.

Quindi, quando chiamare uno sviluppatore? Il criterio non è il numero di utenti né il costo dell’abbonamento. La domanda giusta è: quanto dipende l’azienda da questo processo? Se l’automazione copia i dati di un modulo in un foglio Excel, male che vada si perde qualche riga. Se da lì passano ordini, fatture, magazzino o pagamenti, un errore costa soldi e tempo. In quel caso lo sviluppatore non serve solo a scrivere codice: serve a progettare l’architettura, gestire gli errori, proteggere i dati, scrivere le integrazioni che mancano e fare in modo che la soluzione messa in piedi in fretta non diventi, sei mesi dopo, qualcosa che nessuno sa più toccare.

La soluzione che suggerisco è: partire semplice, ma con un’uscita di sicurezza. No-code e sviluppo tradizionale possono stare benissimo nello stesso progetto. Si parte con uno strumento no-code per vedere se l’idea regge, la si fa usare a qualcuno, si raccolgono i commenti. Se il progetto cresce, i pezzi più critici si sostituiscono man mano con servizi o API scritti su misura. È più sensato che progettare subito un sistema enorme su requisiti che nessuno conosce ancora bene.

L’unica accortezza è pensarci dall’inizio: dati esportabili, API disponibili, formati aperti. Sono queste cose a rendere possibile, un domani, cambiare strumento senza ricominciare da zero.

Intanto cambia anche il modo di programmare, infatti a confondere ancora di più il confine tra uomo e macchina c’è la programmazione assistita dall’AI. Strumenti come GitHub Copilot, Cursor o Devin Desktop (il nuovo nome di Windsurf, a sua volta nato da Codeium e oggi di Cognition) permettono di descrivere una funzione a parole, generare parti di applicazione, modificare codice esistente e trovare bug molto più in fretta di qualche anno fa.

Rispetto al no-code, questo approccio lascia il pieno controllo sul codice e sull’architettura. Ma non toglie la necessità di capire cosa si sta costruendo: generare codice oggi è facile, capire se è corretto, sicuro e manutenibile no.

In conclusione, no-code o codice? Posta così, la domanda ha poco senso. Per un prototipo, una piccola automazione o un’app interna, il no-code è spesso la scelta giusta. Per un processo centrale, con tante integrazioni o requisiti particolari, low-code e sviluppo su misura danno più controllo. Nella maggior parte dei progetti reali si finisce per usare un po’ di tutti e due.

Quello che l’AI ha cambiato davvero non è che chiunque possa fare il programmatore. È che molte più persone possono passare da un problema concreto a un primo prototipo funzionante senza aspettare nessuno. Prima ci si chiedeva chi potesse svilupparlo, adesso, sempre più spesso, si prova direttamente a costruirlo.