Esempi di programmazione con Vibe: 6 progetti pratici da esplorare

Introduzione

Il Vibe coding permette praticamente a chiunque di descrivere un'idea in parole semplici e ottenere in cambio una prima versione funzionante, privilegiando la rapidità rispetto al lungo processo di ingegnerizzazione che richiederebbe una build tradizionale. Capire da dove iniziare, però, è un altro problema, soprattutto per i team abituati a inviare un ticket e ad aspettare una build.

Il Vibe coding può concretizzarsi sotto forma di un rapido mockup visivo, di un prototipo funzionante o di una piccola prova di concetto, a seconda di ciò che si sta cercando di capire. Questo articolo illustra sei esempi che i professionisti possono provare a realizzare. Si tratta di progetti esemplificativi che chiunque potrebbe realizzare, non di prodotti finiti o commerciali.

6 esempi pratici di "vibe coding" per i team aziendali

L’uso di strumenti di IA per il “vibe coding” può generare rapidamente codice eseguibile e componenti di app sulla base di semplici descrizioni fornite dagli utenti, ma è importante familiarizzare con il processo prima di lanciare qualsiasi cosa. Questi sei esempi, che rappresentano il tipo di progetti che si incontrano sul lavoro, passano da soluzioni semplici e visive a soluzioni più complesse, più vicine a qualcosa che si basa su dati reali e logiche di flusso di lavoro. Ciascuno parte dall’esigenza aziendale, illustra un prompt di esempio e un possibile primo risultato, e si conclude con gli aspetti da verificare prima di procedere oltre.

1. Visualizzare una landing page prima di realizzarla

Trasformare un'idea di pagina in qualcosa su cui un team possa lavorare significa solitamente attendere tempi di sviluppo che nessuno ha a disposizione. Il Vibe coding elimina questa attesa. Un singolo prompt può generare un layout funzionante con una gerarchia e un flusso reali, fornendo al team qualcosa di concreto su cui discutere piuttosto che un brief scritto che le persone interpretano in modi diversi.

Esempio di prompt: «Crea una landing page per i titolari di piccole imprese che stanno valutando [prodotto]. Includi una sezione hero con titolo e CTA, tre schede sui vantaggi, una sezione dedicata alle testimonianze e una tabella di confronto dei prezzi. Rendi il pulsante CTA "sticky" mentre il visitatore scorre la pagina.”

Possibile primo risultato. Una singola pagina funzionante con layout e spaziatura reali, anche se il testo e le immagini sono segnaposto, è sufficiente per valutare la gerarchia e il flusso prima ancora che raggiunga il primo utente.

Cosa verificare successivamente. Seguono ancora l’approvazione del testo, la verifica dell’accessibilità, le linee guida del marchio e l’implementazione effettiva. Un mockup cliccabile permette di verificare se la struttura funziona, non se è pronta per la pubblicazione.

2. Testare un selettore di prodotti interattivo

Le gamme di prodotti complesse sono difficili da consultare. Aiutare i clienti a individuare l’opzione giusta di solito comporta un lungo elenco di filtri o molte congetture. Un prompt può generare in pochi minuti un flusso guidato di domande, ponendo alcune domande e indirizzando i clienti verso un consiglio prima ancora che qualcuno consulti il catalogo vero e proprio.

Esempio di prompt: «Crea un’app web per la selezione dei prodotti che ponga tre domande relative al caso d’uso, al budget e allo spazio disponibile, per poi raccomandare uno dei cinque tipi di prodotto con una breve spiegazione per ciascuna raccomandazione».

Possibile primo risultato: un flusso di quiz funzionante con una logica di raccomandazione provvisoria, sufficiente per cliccare su ogni percorso e vedere dove porta una risposta.

Cosa verificare successivamente. Questo test valuta l’interazione, non l’accuratezza dei consigli. Domande confuse o percorsi senza uscita emergono rapidamente. I dati reali dei prodotti, la logica di raccomandazione e la disponibilità delle scorte devono ancora essere verificati separatamente prima che lo strumento acceda al catalogo attivo.

3. Esplorare una dashboard con dati di esempio

Non tutte le idee di reportistica richiedono una pipeline di dati completa prima di poter capire se il layout sia effettivamente utile. Un prompt può assemblare una dashboard costruita interamente con record inventati, che gli stakeholder possano sfogliare e alla quale possano rispondere immediatamente.

Esempio di prompt: «Crea una dashboard utilizzando dati di esempio relativi a 50 richieste di assistenza. Includi schede riassuntive con il numero di richieste aperte, in corso e risolte, un filtro per priorità e team assegnato, e una tabella che mostri i tempi medi di risposta per categoria».

Possibile primo risultato. Una dashboard funzionante che gli stakeholder possono filtrare e su cui possono reagire immediatamente, utilizzando record inventati anziché dati estratti da un sistema live.

Cosa verificare successivamente. Una dashboard convincente costruita su dati di esempio non ha ancora chiarito da dove proverranno i dati live, se saranno alimentati da un database reale, con quale frequenza si aggiorneranno o se i numeri significano effettivamente ciò che le persone suppongono.

4. Realizzare un prototipo del flusso di lavoro di onboarding dei fornitori

L’inserimento dei fornitori spesso si svolge tra thread di e-mail, fogli di calcolo e chiunque si ricordi l’ultimo passaggio. Nessuno si rende davvero conto di quanto sia disorganizzato il processo finché qualcuno non lo mappa. Un prompt può generare schermate cliccabili che coprono l’inserimento, il monitoraggio dello stato e l’approvazione, consentendo agli uffici acquisti e alle operazioni di ripercorrere insieme l’intero processo per la prima volta.

Esempio di prompt: «Crea un flusso di onboarding dei fornitori con un modulo di invio per i dati aziendali e i documenti richiesti, una vista dello stato che mostri a che punto si trova ogni richiesta e una schermata di approvazione che consenta ai revisori di accettare o rifiutare una richiesta con commenti».

Possibile primo risultato. Schermate che gli acquirenti e il reparto operativo possono esaminare insieme per individuare passaggi mancanti o passaggi di consegne poco chiari prima di impegnarsi in qualcosa di concreto.

Cosa verificare successivamente. Una versione definitiva richiede strutture di dati concordate, regole di accesso reali per ciascun ruolo, una gestione dei documenti che soddisfi tutti i requisiti di conformità applicabili e collegamenti ai sistemi che già tracciano fornitori e pagamenti.

5. Creare un prototipo di esperienza utente self-service

I clienti non dovrebbero essere costretti a chiamare qualcuno solo per controllare un ordine o aggiornare le impostazioni dell’account. Costruire un’infrastruttura di account reale per verificare questa ipotesi richiede un impegno iniziale notevole. Una serie di schermate navigabili, basate su dati di esempio, può rispondere alla domanda se gli utenti riescano effettivamente a trovare ciò di cui hanno bisogno molto prima che tale infrastruttura esista.

Esempio di richiesta: «Crea un’esperienza di account cliente con una dashboard che mostri gli ordini recenti, una pagina per aggiornare i dati di contatto e le preferenze di pagamento, e un modulo di richiesta di assistenza con un tracciatore di stato, utilizzando cinque account cliente di esempio».

Possibile primo risultato: schermate che un utente reale può sfogliare utilizzando dati di account fittizi, sufficienti a verificare se il layout e le etichette abbiano effettivamente senso.

Cosa verificare successivamente. Questo test verifica se i clienti riescono a trovare le informazioni e a completare un’attività senza aiuto. La verifica dell’identità reale, le autorizzazioni e le connessioni al sistema di account effettivo, insieme a tutto ciò che riguarda i dati sensibili, costituiscono un ambito di lavoro separato che il prototipo non copre.

6. Verificare un’idea di integrazione con una piccola prova di concetto

È raro che due sistemi siano d’accordo su come i dati debbano essere strutturati. Scoprirlo a metà dell’integrazione è costoso. Con una prova di concetto di portata limitata, uno sviluppatore può realizzare una piccola funzione che trasformi i dati di esempio provenienti da un sistema nel formato previsto da un altro sistema, rispondendo alla domanda in un pomeriggio anziché in una settimana.

Esempio di prompt: «Data questa risposta JSON di esempio proveniente dal [sistema A], scrivi una funzione che la trasformi nella struttura dei campi prevista dal [sistema B]. Gestisci i campi mancanti lasciandoli vuoti e contrassegna qualsiasi campo che non corrisponda al tipo previsto».

Possibile primo risultato: Logica di trasformazione funzionante sul lato client che gestisce correttamente l’input di esempio, testata su una manciata di record di esempio anziché su una connessione live.

Cosa verificare successivamente. Un esempio riuscito non verifica come si comportino effettivamente le API live , come vengano memorizzate e ruotate le credenziali come le chiavi API, cosa accada quando una richiesta fallisce o chi si occupi della mappatura una volta che i sistemi di origine cambiano.

Cosa si può imparare provando gli esempi di Vibe Coding?

Ciascuno di questi esempi insegna qualcosa di diverso, ma la lezione di fondo è la stessa. Si scopre se un’idea regge una volta che esiste come qualcosa di reale, non solo come descrizione in una riunione. Descrivere ciò che si desidera in linguaggio naturale a un agente di IA , esaminare ciò che viene restituito e fornire ulteriori indicazioni finché non funziona è il modo per raggiungere l’obiettivo.

Il vero valore va oltre il primo prompt. Si osserva l’interfaccia o il comportamento effettivo che ne deriva. Si impara anche cosa deve cambiare quando qualcuno reagisce ad esso. A volte quella reazione rimanda allo strumento stesso. Spesso si inizia con uno strumento per una rapida valutazione visiva, per poi passare a qualcosa come Cursor o Claude Code quando il codice sottostante richiede un’attenzione più approfondita. Gli strumenti di Vibe coding e le piattaforme low-code adottano approcci davvero diversi in questo ambito: uno si basa sui prompt e sul codice, l’altro sulla configurazione visiva.

Nessuno degli esempi sopra riportati è completo o pronto per la produzione. Sono un punto di partenza. Ciò che impari dalla prima versione determina se vale la pena portarla avanti.

Come scegliere un progetto di Vibe Coding da provare?

Sei diverse direzioni tra cui scegliere sono davvero tante. Il progetto giusto dipende da ciò che si sta effettivamente cercando di imparare. Alcune domande aiutano a restringere il campo:

• Cosa stai cercando di imparare? Il layout di una pagina, il flusso utente, una vista di report, un flusso di lavoro o un collegamento tecnico richiedono ciascuno un tipo diverso di prototipo, poiché compiti diversi richiedono tipi diversi di verifica.
• Puoi iniziare con dati di esempio? Usa informazioni che consentano alle persone di valutare l’idea senza accedere a dati aziendali reali, in modo che l’esperimento non comporti rischi elevati.
• Chi deve reagire al risultato? A seconda che l’esempio sia destinato a clienti, stakeholder aziendali, designer o sviluppatori, cambia il significato stesso di “utile”.
• Cosa renderebbe utile l’esperimento? Identificate una decisione specifica su cui dovrebbe fornire indicazioni, ad esempio se valga la pena o meno sviluppare ulteriormente un flusso di lavoro.

Non si tratta di trasformare il tutto in una revisione completa della sicurezza. Vale comunque la pena prenderlo sul serio. Una ricerca di Veracode ha rilevato che il 45% degli esempi di codice generati dall’IA contiene falle di sicurezza. Un controllo rapido ora è meglio di uno costoso in seguito.

Cosa succede quando un esempio diventa un’applicazione duratura?

Scegliere il prototipo giusto da realizzare è solo la prima decisione. Ciò che accade in seguito è altrettanto importante. Alcuni prototipi rispondono alla domanda iniziale e possono essere accantonati immediatamente. Altri rivelano un flusso di lavoro che l’azienda desidera effettivamente continuare a utilizzare.

Prendiamo l’esempio dell’onboarding dei fornitori citato in precedenza. Una volta che le persone iniziano ad affidarsi regolarmente a questo sistema, il team ha bisogno di registrazioni affidabili, autorizzazioni chiaramente definite, un vero e proprio processo di approvazione, integrazioni funzionanti e qualcuno che ne assuma la responsabilità in futuro. Si tratta degli stessi requisiti necessari a qualsiasi flusso di lavoro operativo, indipendentemente dal fatto che la prima versione sia stata scritta o meno da uno degli attuali modelli di IA .

Le funzionalità low-code di Liferay DXP possono supportare gran parte di questo processo. Gli oggetti gestiscono i dati strutturati, i moduli gestiscono l’inserimento dei dati, i flussi di lavoro gestiscono le fasi di approvazione, mentre le autorizzazioni e le integrazioni collegano il tutto ai sistemi già esistenti, creando di fatto un livello di governance attorno a ciò che era iniziato come un prototipo veloce. Le funzionalità specializzate potrebbero comunque richiedere uno sviluppo personalizzato e una propria revisione, specialmente quando un team deve aggiungere caratteristiche non coperte da funzionalità predefinite o desidera un maggiore controllo sul comportamento esatto di una determinata funzionalità. Il punto non è che Liferay DXP abbia realizzato il prototipo originale. Si tratta piuttosto di scegliere le fondamenta giuste una volta che il prototipo diventa qualcosa da cui l’azienda dipende effettivamente.

Parti dall’idea che devi testare

Inizia con una domanda ben definita, non con una richiesta generica di realizzare un’app. Gli strumenti di intelligenza artificiale gestiscono rapidamente il codice standard, ed è in parte per questo che il primo risultato, per quanto approssimativo, ti offre qualcosa su cui reagire e che puoi perfezionare immediatamente. Quella reazione è solitamente più utile del prototipo stesso. Condividetelo con un breve post per ricevere feedback, oppure tenetelo privato: scegliete la soluzione che vi consenta di ottenere una reazione sincera nel minor tempo possibile.

Il vero valore di un esempio sta nel rendere un’idea verificabile, indipendentemente dal fatto che diventi o meno un’applicazione permanente. Se uno di questi esperimenti dovesse trasformarsi in un flusso di lavoro che la vostra organizzazione deve gestire e mantenere, esplorate le funzionalità low-code di Liferay DXP per capire come potrebbe essere una base governata.

Domande frequenti sugli esempi di "vibe coding"

Da dove deriva il termine "vibe coding"?

Il ricercatore di intelligenza artificiale Andrej Karpathy ha reso popolare il termine nel 2025, descrivendo un modo per sviluppare software partendo da ciò che si desidera, anziché scrivere codice riga per riga. Il nome ha preso piede perché coglieva un aspetto concreto della rapidità con cui un'idea può trasformarsi in una prima versione funzionante.

Quali sono alcuni semplici esempi di "vibe coding" per principianti?

Un mockup di una landing page, una calcolatrice di base, semplici giochi per browser o una dashboard che utilizza dati di esempio sono tutti ottimi punti di partenza. Nessuno di questi richiede competenze di programmazione per essere realizzato. Ognuno ha un obiettivo ben definito e offre qualcosa di concreto da esaminare e perfezionare, piuttosto che un'idea astratta. Inizia con una singola funzionalità, invece di cercare di creare un'applicazione completa.

È possibile realizzare un "vibe coding" per uno strumento aziendale interno?

Sì, e spesso è meglio partire da lì, poiché gli strumenti interni hanno una maggiore tolleranza per le imperfezioni. Un sistema di tracciamento delle richieste interne o una dashboard di reportistica potrebbero facilmente nascere come progetto secondario o prototipo realizzato con il "vibe coding". "Interno" non significa però automaticamente basso rischio, una volta che lo strumento entra in contatto con i dati aziendali o diventa parte di un flusso di lavoro regolare. Il team deve comunque valutare l’accesso, l’affidabilità e la titolarità prima di fare affidamento su di esso quotidianamente. Qualunque lacuna emersa dalla revisione dovrà comunque essere risolta.

Cosa dovresti includere nelle istruzioni per il vibe coding?

Specificare chi utilizzerà il progetto, quale attività dovrebbe supportare, le informazioni o i dati di esempio necessari e cosa dovrebbe accadere quando gli utenti interagiscono con esso, il tutto in un linguaggio semplice piuttosto che con dettagli tecnici. Includere regole importanti o casi limite, se pertinenti. È sempre possibile perfezionare il risultato tramite istruzioni di follow-up dopo aver testato la prima versione.

Gli esempi di codice generato da Vibe sono pronti per l’uso con dati reali dei clienti?

No. Il codice generato dall’IA richiede spesso una revisione professionale prima del lancio. Un prototipo funzionante non garantisce che l’autenticazione, le autorizzazioni, la gestione dei dati o le integrazioni siano pronte per l’uso da parte dei clienti. Iniziate con dati sintetici, quindi sottoponeteli a un’adeguata revisione ingegneristica e di sicurezza prima di collegare qualsiasi cosa a record reali.