Vibe coding: cos'è e come costruisco tool senza team di sviluppo

Sei qui per capire cos’è il vibe coding. Prima che inizi, sappi in cosa ti stai imbarcando. Sono un marketer, non uno sviluppatore, e ho spedito quattro tool interni funzionanti senza un team di sviluppo. Ecco come, quanto è costato, e dove mi fermo.

Il vibe coding è descrivere un software in italiano semplice e lasciare che un’AI scriva il codice. Tu guidi. Il modello digita. Non apri mai un manuale. Il termine è molto in voga in questo momento, e come ogni termine di moda viene stiracchiato per vendere corsi.

Quasi tutto quello che leggerai arriva da due schieramenti. Ingegneri che sanno già programmare, e spiegano perché la novità è pericolosa. Oppure venditori che spiegano perché la novità è magica. Io non sto in nessuno dei due. Sono un praticante che costruisce tool perché aspettare un ticket di sviluppo trasforma piccoli task in progetti trimestrali.

In sintesi

• Non devi essere uno sviluppatore. Ti servono gusto, uno stack che sai spiegare, e regole che rifiuti di infrangere.
• Il termine esagera la facilità. Il vibe coding è reale, ma il lavoro vero è rivedere l’output dell’AI abbastanza duramente da fidartene in produzione.
• Ho spedito quattro tool funzionanti senza un team di sviluppo: un dashboard di task, un kit di lead attribution, un servizio di ingestion dei contenuti, e un elenco di 900 pagine.
• Il costo vero non è l’abbonamento. È la tua attenzione al momento della revisione, e le ore che bruci quando la salti.
• Tre regole non sono opzionali: mai credenziali in chiaro, mai dati cliente a un modello, sempre revisione prima del deploy.

Il vibe coding per marketer non è quello che pensi

I venditori ti diranno che il vibe coding significa spedire la prossima grande app. Mostrano un marketer che lancia un prodotto SaaS in un weekend. Quella è la versione fantasia, e punta alla tua carta di credito.

Per un marketer, il vibe coding significa qualcosa di più piccolo e più utile. Significa costruire i tool interni che nessuno prioritizzerà mai per te. Un dashboard che traccia i task su cinque progetti. Uno script che attribuisce i lead alla fonte giusta. Un servizio che trasforma i feed RSS in articoli puliti. Un elenco che cataloga novecento espositori.

Non stai costruendo un prodotto da vendere. Stai costruendo la macchina che ti serve per fare il tuo lavoro. Quella distinzione trasforma tutto, perché i tool interni hanno due proprietà clementi. Primo, l’utente sei tu, quindi la posta in gioco è più bassa e il feedback è immediato. Secondo, nessuno fa audit del tuo codice. L’unico giudice è se il tool funziona quando ti serve.

Ecco la parte che l’hype ignora. Il collo di bottiglia nel vibe coding non è mai stato scrivere il codice. È sempre stato sapere cosa vuoi, con abbastanza dettaglio da permettere a una macchina di produrlo. Una richiesta vaga produce codice vago. Una richiesta precisa produce un tool che funziona. La skill che stai imparando è come specificare, non come digitare.

Quella è la vera differenza tra la fantasia e le ricevute. I corsi vendono la digitazione. Il lavoro è la specifica. E la specifica è una skill di marketing che hai già, perché è lo stesso muscolo che usi per fare un brief a un freelance o scrivere un brief creativo.

Come fare vibe coding: il flusso esatto che uso, passo per passo

Questo è il processo che seguo, raffinato sui tool della prossima sezione. Funziona sia che il tuo modello sia Claude, ChatGPT o qualunque cosa arrivi dopo. Il modello cambia. Il loop no.

Passo 1. Parti dal dolore, non dal tool. Scrivi il task che ti mangia il tempo. Non il software che immagini. Se il task è “perdo venti minuti a settimana a controllare a mano cinque dashboard”, quello è il brief. Il tool è la risposta, non la domanda. Costruisci dal dolore e userai il risultato. Costruisci da un’idea accattivante e lo abbandonerai in una settimana.

Passo 2. Scrivi la specifica in un paragrafo. Descrivi cosa fa il tool, cosa riceve, cosa restituisce, e cosa non deve mai fare. Un paragrafo. Se non ci sta in un paragrafo, non sei pronto a costruire. Il paragrafo è il contratto. Il modello lo segue, e tu lo tieni contro il risultato. La disciplina qui è la parte che nessun corso vende, perché è noiosa e non fa screenshot. Quando costruisci più di un tool, tieni le regole fisse in un breve file di istruzioni. Cosa ci va dentro è spiegato in best practice per CLAUDE.md dopo Claude 5.

Passo 3. Taglialo alla fetta più piccola che funziona. Prendi il paragrafo e riducilo a una cosa che il tool deve fare per prima. Costruisci quella. La fetta per il mio dashboard di task era una singola pagina che elenca i task aperti. Non cinque viste, non regole di alert. Una lista. Una fetta piccola che funziona oggi batte un grande design che non funziona mai.

Passo 4. Lascia che il modello costruisca, file per file. Chiedi pezzi piccoli e rivedibili. Un singolo file, o una singola funzione. Quando chiedi tutto in una volta, il modello costruisce tutto in una volta, e ottieni un pasticcio di cui non puoi fare audit. I pezzi piccoli tengono onesta la revisione, e la revisione è tutto il lavoro.

Passo 5. Eseguilo e leggi gli errori. È qui che la maggior parte molla, ed è qui che impari. Il messaggio di errore è il modello che ti fa una domanda. Leggilo, incollalo di nuovo, e lascia che il modello lo spieghi in italiano semplice. Ripeti finché non gira. Ogni loop ti insegna cosa sta facendo il modello, che è la skill per cui sei qui.

Passo 6. Aggiungi test per le parti che contano. Non ti serve una suite di test per uno script usa e getta. Te ne serve una per tutto ciò che tocca dati reali o gira senza di te. Il mio dashboard di task è stato spedito con 34 test, e hanno preso 3 bug reali prima che arrivassero in produzione. I test sono la linea tra un tool e una responsabilità.

Passo 7. Rivedi prima del deploy. Apri il file che ha scritto il modello. Leggilo. Non riga per riga come un ingegnere, ma abbastanza da rispondere a una domanda: capisco cosa fa? Se la risposta è no, non stai facendo deploy. Stai giocando d’azzardo. Il modello è un dattilografo veloce senza giudizio. Il giudizio è tuo, su ogni file.

Quattro tool interni di marketing che ho spedito senza un team di sviluppo

Questi sono reali. Non demo, non esperimenti secondari morti dopo un weekend. Tool che uso, e le ricevute dietro ognuno.

The Nexus. Un dashboard di task in Python con zero dipendenze. Cinque viste, sette regole di alert, un watcher SSE per gli aggiornamenti live, e scritture atomiche su file così un crash non corrompe mai lo stato. Trentaquattro test. Tre bug reali presi prima della spedizione. Questo è il tool che ha ucciso il mio rituale da venti minuti a settimana sui dashboard, ed è partito come la singola lista del Passo 3.

Un kit di lead attribution. Quarantaquattro vettori di attribuzione, che tracciano da dove arriva un lead attraverso i canali. Gira in Node e PHP, entrambi verdi, quindi si inserisce in un progetto indipendentemente da cosa ci gira sopra. L’attribuzione è il tipo di idraulica noiosa che non riceve mai un ticket di sviluppo, perché è invisibile finché i numeri non sono sbagliati. Ora è mia, e i numeri sono giusti.

Un servizio di ingestion da RSS ad articoli, Corpus. Prende i feed, pulisce il contenuto, e li trasforma in articoli usabili. Centosessantuno test, tutti verdi. Questo è quello che mi ha insegnato il valore del passo dei test, perché la prima versione falliva in silenzio sui feed malformati e me ne sono accorto solo una settimana dopo. La suite che passa non è vanto. È la cicatrice di quella settimana, trasformata in un guardrail.

Un elenco di espositori AI da 900 pagine su Astro. Un sito statico generato dai dati, che elenca novecento espositori attraverso gli eventi. Astro ha fatto il lavoro pesante sulle performance. Il modello ha fatto la forma dei dati. Il risultato ranka, carica veloce, e costa quasi niente da ospitare. Novecento pagine a mano avrebbero richiesto un mese. Con il vibe coding, sono servite poche sere di revisione.

Il pattern attraverso tutti e quattro è lo stesso. Scope piccolo. Uno stack che so spiegare. Test sulle parti che toccano dati reali. E una revisione dura prima che qualunque cosa vada live. Nessuno ha richiesto un giorno di studio formale. Tutti hanno richiesto quel passo di revisione, ogni volta.

Lo stack che funziona davvero (e cosa costa davvero)

La gente chiede che stack usare. Ecco il mio, ed è noioso apposta. Noioso è una feature, perché noioso è ciò che un modello scrive pulito e che tu puoi spiegare a uno sviluppatore dopo.

Per script e tool interni, Python. Si legge come l’italiano, ha una libreria per tutto, e un modello lo scrive pulito. The Nexus è Python con zero dipendenze, il che significa che non c’è niente da rompere quando lo sposti. Quella scelta era deliberata: meno cose da cui un tool dipende, meno cose che un futuro te deve sistemare.

Per tutto ciò che vive in un sito web, Node e PHP funzionano entrambi, ed è per questo che il kit di attribuzione esce in entrambi. Abbina il tool a ciò su cui il sito già gira. Non introdurre un nuovo runtime per un tool che potrebbe girare su quello che hai.

Per siti statici ed elenchi, Astro. È veloce, semplice, e il modello lo conosce bene. L’elenco di espositori è Astro, e novecento pagine renderizzano in una frazione di secondo.

Ora il costo, perché la pagina prezzi non ti dice mai quello vero. L’abbonamento è la riga piccola. Il mio abbonamento AI gira intorno ai 200 al mese per uso intenso. Un power user che spinge ogni tool al limite arriva a 400-600. La riga costosa è un’altra. Sono le ore che passi a rivedere l’output, e i giorni che passi a sistemare ciò che hai saltato. Non esiste tool che rimuove la revisione. Chiunque te ne venda uno sta vendendo di nuovo la versione fantasia.

Se vuoi la mappa completa di cos’altro giro, l’ho scritta a parte. Ecco il mio marketing tech stack.

Esempi di vibe coding: una vittoria e un pasticcio costoso

Lascia che ti mostri entrambi i lati, perché una lista di vittorie senza il pasticcio sarebbe disonesta. Le vittorie sono reali. Così come il conto quando salti le regole.

La vittoria. The Nexus è partito come una singola lista di task aperti. Era tutta la cosa. Ha funzionato il primo giorno, il che mi ha dato la fiducia di aggiungere una seconda vista, poi le regole di alert, poi il watcher SSE. Ogni fetta è partita piccola e rivista. I test sono arrivati dopo, quando l’avevo usato abbastanza a lungo da sapere cosa contava, e hanno preso tre bug che avrei spedito a mano. È tutto il metodo in un tool: parti piccolo, rivedi duro, lascia che i test crescano mentre il tool cresce.

Il pasticcio costoso. All’inizio ho chiesto a un modello di ristrutturare uno script che toccava dati reali, l’ho lasciato girare, e non ho letto il diff. Ha funzionato nella demo e ha fallito in produzione, e ho bruciato quasi un giorno intero a tracciare cosa aveva cambiato. La lezione non era che il vibe coding è pericoloso. Era che il passo di revisione non è opzionale, e saltarlo non è mai più economico. La correzione era lo stesso passo di revisione che ora tratto come una regola dura.

Il pasticcio era colpa mia, non del modello. Il modello ha fatto esattamente ciò che fa un dattilografo veloce senza giudizio: ha prodotto qualcosa che sembrava giusto e non lo era. Ho scritto prima la versione profonda di questo fallimento, quello che affonda interi progetti AI nelle aziende. Falliscono in quattro modi prevedibili. La maggior parte sono lo stesso errore su scala: trattare l’output del modello come finito.

Vibe coding sicurezza: le regole che non infrango

Questa è la sezione che i venditori di corsi saltano, ed è quella che conta di più. La sicurezza nel vibe coding non è una feature che avviti dopo. È un insieme di regole che segui prima di scrivere un singolo prompt.

Mai credenziali in chiaro. Niente chiavi API nello script. Niente password in un file di config che committi. Usa un file di ambiente o un gestore di segreti, e tienilo fuori dal controllo versione. Un modello ti scriverà volentieri uno script con la chiave incollata dentro se glielo permetti. Non glielo permettere. Questa regola non ha eccezioni, nemmeno per un tool interno che “uso solo io”.

Mai dati cliente a un modello. Liste di clienti, numeri di fatturato, specifiche di prodotti non lanciati, qualsiasi cosa ti metterebbe in imbarazzo in una violazione. Niente di tutto ciò entra in una chat pubblica. Se i dati sarebbero un problema nelle mani di uno sconosciuto, non incollarli nella chat di uno. Il mio datore di lavoro vieta i modelli frontier per i dati aziendali, e non è arretratezza. È l’unico default difendibile.

Sempre revisione prima del deploy. Il modello non conosce il tuo ambiente di produzione. Non sa quale file è portante. Scrive codice che funziona in isolamento e si rompe nel contesto. L’unica persona che può accorgersene sei tu, leggendo il diff. Il pasticcio costoso della sezione scorsa è successo esattamente così: saltando questo passo.

Ce ne sono altre tre che tratto come legge. Tieni un backup di tutto ciò che lo script tocca. Gira i tool nuovi su una copia dei dati prima, mai sul file live. E se non capisci un blocco di codice, non eseguirlo, non importa quanto il modello suoni sicuro. L’aria sicura non è correttezza. Ho coperto quella verità brutta in dettaglio nel mio pezzo su ChatGPT nel marketing.

Come imparare il vibe coding senza sprecare sei mesi

Non comprare il corso da sei mesi. Non ti serve, e la maggior parte è imbottitura attorno ai sette passi sopra. Ecco il percorso che ha funzionato, compresso in tre traguardi.

Costruisci un piccolo tool per te questa settimana. Uno script che rinomina i file, una pagina che elenca le tue tab aperte, un modulo che ti manda un riepilogo via email. L’obiettivo non è il tool. È chiudere un loop: richiesta, esegui, leggi l’errore, correggi, esegui di nuovo. Quel loop è tutta la skill. Tutto dopo è ripetizione con una posta in gioco più alta.

Fai toccare al secondo tool il tuo lavoro vero. Automatizza qualcosa che fai a mano. Un report che assembli, una lista che aggiorni, una notifica che controlli. Ora la posta è reale e il feedback è immediato, che è esattamente ciò che ti serve per imparare il passo di revisione. Il secondo tool è dove la fantasia muore e inizia la disciplina.

Aggiungi i test al terzo. Entro il terzo tool avrai sentito il dolore di un fallimento silenzioso. Quel dolore è il miglior insegnante per capire perché i test esistono. Aggiungine qualcuno per le parti che toccano i dati, e guarda quanto diversamente tratti l’output del modello dopo. I test non riguardano la purezza ingegneristica. Riguardano il non bruciarti due volte.

Puoi imparare il loop in un weekend. Il giudizio, la parte che sa quando l’output è sbagliato, richiede mesi di tool reali che falliscono. La buona notizia è che il fallimento è il programma. La cattiva notizia è che accade sul tuo tempo. Non esiste una scorciatoia per saltarlo, qualunque cosa dica il corso.

Quando fermarti e chiamare uno sviluppatore (e come capirlo)

Il vibe coding ha un soffitto, e la parte onesta di questo articolo è dirti dove sta. Ho costruito cose senza un team di sviluppo. Ho anche riconsegnato cose e detto, questa è tua. La linea non riguarda la skill. Riguarda il raggio di esplosione.

Fallo da te quando il tool è interno, sei l’unico utente, il raggio di esplosione è il tuo pomeriggio, e puoi spiegare completamente cosa fa. Un dashboard, uno script di attribuzione, un servizio di ingestion, un elenco statico. Tutti questi si qualificavano. La modalità di fallimento è un’ora persa, non un cliente perso.

Chiama uno sviluppatore quando il tool tocca dati cliente su scala, gestisce pagamenti, affronta l’internet pubblico, deve essere sicuro contro chi prova a romperlo, o deve girare quando non guardi. Un flusso di checkout. Un portale clienti. Qualunque cosa dove un bug significa perdere soldi o far trapelare dati. Quelli non sono progetti di vibe coding. Quelli sono progetti di ingegneria.

C’è una terza categoria, ed è quella di cui nessuno parla. Il momento in cui sei il collo di bottiglia, perché il tool che hai costruito ora conta per altre persone. Se tre colleghi dipendono dal tuo script e si rompe di domenica, non sei più l’eroe del tool interno. Sei il punto singolo di fallimento. Quello è il segnale per consegnarlo a uno sviluppatore con test e deploy appropriati.

Il test che uso è semplice. Chiediti cosa succede quando questo si rompe nel momento peggiore possibile. Se la risposta è “perdo un’ora”, costruiscilo da te. Se la risposta è “qualcuno perde soldi o dati”, chiama lo sviluppatore. Tutto il resto è programmare il dolore.

Vibe coding: il mio verdetto dopo due anni

Dopo due anni a costruire in questo modo, ecco il mio verdetto sul vibe coding. È la skill più utile che ho aggiunto al mio lavoro di marketing in un decennio, e la più fraintesa.

Non ti renderà uno sviluppatore. Ti renderà pericoloso nel modo migliore: capace di spedire i tool noiosi che muovono il tuo lavoro avanti, senza aspettare un ticket che non arriva mai. I quattro tool che ho descritto mi hanno risparmiato settimane di lavoro manuale, e nessuno ha richiesto un singolo giorno di studio formale.

Le persone che si fanno male con il vibe coding sono quelle che saltano la revisione, incollano segreti nelle chat, e lasciano il modello libero sui dati di produzione. Le persone che prosperano sono quelle che trattano il modello come un dattilografo veloce senza giudizio. Prendi ancora ogni decisione che conta. Prendi le stesse decisioni, dieci volte più veloce.

Ho scritto la versione lunga di ciò che mi hanno insegnato due anni e mezzo di uso quotidiano dell’AI altrove. Questo articolo è il lato costruzione della stessa storia. Parti da un tool che risolve un dolore reale. Taglialo piccolo. Testa le parti che toccano i dati. Rivedi prima del deploy. È tutto il metodo, ed è tuo al prezzo di un weekend.

Se vuoi vedere l’estremo opposto della costruzione assistita dall’AI, un piccolo team ha appena rilasciato dodici app open source in nove giorni. Ho verificato il codice per capire cosa regge.

Domande frequenti

Devo saper programmare per fare vibe coding?

No. Devi saper descrivere cosa vuoi in italiano semplice, leggere un messaggio di errore senza andare nel panico, e pensare a piccoli passi. Tutto il resto lo fa il modello. Quello che non puoi saltare è il giudizio: sapere quando l’output è sbagliato, e controllare prima di fidarti.

Il vibe coding è sicuro da usare al lavoro?

Solo dentro le regole. Mai credenziali in chiaro. Mai dati cliente o aziendali a un modello pubblico. Sempre revisione prima del deploy, e gira i tool nuovi su una copia dei dati prima. Se il tuo datore di lavoro vieta i modelli frontier per i dati aziendali, quella policy esiste per un motivo. Rispettala.

Qual è il miglior tool per iniziare a fare vibe coding?

Quello che già paghi. La skill si trasferisce tra i modelli, quindi parti con quello che hai, scegli un piccolo tool interno, e chiudi il loop: richiesta, esegui, leggi l’errore, correggi, esegui di nuovo. Il tool conta meno dell’abitudine alla revisione. Quell’abitudine è tutta la differenza tra un tool di cui ti fidi e una responsabilità che spedisci.