Vibe Coding: come l’AI riscrive le regole dello sviluppo prodotto. Un caso studio, parte 1.

Il Vibe Coding è un approccio innovativo allo sviluppo software che sfrutta l’intelligenza artificiale per trasformare descrizioni in linguaggio naturale in codice eseguibile. Invece di scrivere codice riga per riga, chi sviluppa definisce ciò che desidera ottenere e lascia all’IA il compito di generare il codice necessario.

Agile Reloaded e Tech Reloaded hanno collaborato per la realizzazione di un prodotto digitale sviluppato con l’approccio del Vibe Coding. Noi di Agile Reloaded ci siamo occupati del processo, mentre i colleghi di Tech Reloaded della parte tecnica.

In questo primo articolo sul tema raccontiamo il caso studio e di come abbiamo testato il Vibe Coding per sviluppare un prodotto software reale, coprendo l’intero ciclo di vita: dalla raccolta dei requisiti fino al deploy online. Il Vibe Coding, secondo la nostra esperienza, potrebbe evolvere da prototipo a soluzione concreta per lo sviluppo software Agile.

I 4 principi chiave del Vibe Coding

I principi del Vide Coding sono quattro:

1. Fondato sull’intelligenza artificiale
   Alla base del Vibe Coding ci sono modelli linguistici avanzati (Large Language Models) addestrati specificamente per comprendere e generare codice sorgente.
2. Guidato dai prompt
   Gli utenti interagiscono con l’IA descrivendo obiettivi e requisiti in linguaggio naturale, senza la necessità di scrivere direttamente istruzioni di programmazione.
3. Focalizzato sugli obiettivi
   Questo approccio libera i creatori dall’onere di dettagli implementativi, consentendo loro di concentrarsi su design, strategia e user experience.
4. Efficienza
   Il Vibe Coding riduce tempi e sforzi di sviluppo, automatizzando attività ripetitive e velocizzando la produzione di software funzionante.

Un supporto, non un sostituto

È fondamentale sottolineare che il Vibe Coding non sostituisce integralmente lo sviluppo tradizionale. L’IA è in grado di generare codice operativo, ma è imprescindibile che chi la utilizza sia in grado di comprenderlo, verificarlo e correggerlo. Errori, incoerenze o comportamenti imprevisti possono emergere: per questo, la supervisione umana resta un elemento cruciale, soprattutto durante il debugging, dove è spesso necessario intervenire manualmente per identificare e correggere eventuali errori. L’IA può sbagliare, generare codice non coerente o addirittura inserire comportamenti inattesi, quindi non è pensabile lasciarla agire in autonomia completa senza una supervisione attenta.

Il caso studio: un progetto end-to-end

In questa serie di articoli descriviamo come abbiamo testato il Vibe Coding per sviluppare un prodotto software reale, coprendo l’intero ciclo di vita: dalla raccolta dei requisiti fino al deploy online. Abbiamo strutturato il lavoro in due ambienti distinti ma interconnessi:

• AI Product Ownership: un contesto per definire backlog, creare user stories e gestire l’evoluzione del prodotto con l’aiuto dell’IA.
• AI Dev: l’area dedicata alla generazione del codice, al setup dell’infrastruttura e al rilascio, dove l’IA lavora come co-sviluppatore sotto monitoraggio umano.

Questa divisione ci ha permesso di mantenere il controllo delle decisioni e del codice, pur delegando all’intelligenza artificiale compiti operativi.

Obiettivo del progetto

Lo scopo del nostro progetto è stato quello di verificare la fattibilità di sviluppare un prodotto digitale considerando l’intero processo (prima from vision to backlog e poi from backlog to code&deploy) mantenendo gli stessi standard di qualità che sono utilizzati in un comune progetto sviluppato in Agile.
Per la parte di sviluppo, abbiamo seguito i principi del clean code promossi da autori come Robert C. Martin: nomi chiari, funzioni concise, responsabilità definite e design semplice. Questi principi e convenzioni sono serviti come linee guida per istruire l’IA su come generare codice leggibile e manutenibile.
Anche la raccolta dei requisiti ha rispettato best practice consolidate. Le user stories sono state create in modo chiaro, con obiettivi espliciti e rispettando il pattern INVEST. Per ridurre il rischio di errori dovuti ad allucinazioni dell’IA, abbiamo mantenuto le storie di dimensioni ridotte e facilmente verificabili.

Il ruolo essenziale degli operatori umani

Nel nostro esperimento hanno collaborato tre membri umani e tre entità artificiali: due agenti AI (uno per la definizione dei requisiti e uno per la raccolta dei feedback) e un ambiente di sviluppo potenziato dall’AI. Gli operatori umani hanno supervisionato ogni output generato, applicando un principio ispirato al motto You Only Live Once (YOLO): concentrarsi sulle attività strategiche e delegare quelle operative e ripetitive all’IA.
Un utente reale è stato coinvolto come utilizzatore finale: ha partecipato a interviste preliminari e rilasciato feedback dopo ogni sprint.

Synthetic Product Ownership: dalla vision al backlog

Abbiamo creato due customGPT: due Synthetic PO specializzati in modo differente. Il secondo lo vedremo nei paragrafi successivi, mentre il primo è stato addestrato a condurre interviste con l’utente finale per raccogliere esigenze di business e definire la vision di prodotto. Le conversazioni si sono svolte principalmente tramite interazione vocale, consentendo interviste più naturali e approfondite.
Tramite le interviste, il customGPT ha poi generato una prima bozza di Vision, un Business Model Canvas, un elenco iniziale di user stories e una relativa mappa (User Story Mapping).
Questo customGPT ha lavorato alla Inception del prodotto seguendo il classico processo From Vision to Backlog, ovvero dalla classica fase di envisioning fino alla creazione del primo backlog di alto livello. Abbiamo iniziato da un esercizio di immaginazione guidata per capire che tipo di prodotto volevamo costruire: non tanto dal punto di vista delle feature, quanto dal tipo di esperienza che volevamo abilitare per chi lo usa.

L’approccio narrativo

In questa fase iniziale abbiamo privilegiato un approccio narrativo: l’obiettivo era co-creare con l’utente una storia condivisa, da cui far emergere la visione implicita del prodotto più che raccogliere requisiti dettagliati.
L’output generato dall’agente è stato validato/revisionato dal PO umano e quindi inserito sotto forma di user stories nel tool di project management Nifty nello stato “todo”. Da lì sono state prese in carico dal team di sviluppo, fino allo stato di test. Qui abbiamo svolto una prima validazione manuale da parte dello HumanPO, sono state spostate in UAT (User Acceptance Testing).

La Sprint Review automatizzata

A questo punto è intervenuto il secondo customGPT (nuovamente un Synthetic PO), dedicato alla fase di validazione, che ha intervistato utente finale per raccogliere i suoi feedback sulle nuove funzionalità appena rilasciate a fine sprint.
L’intervista è stata condotta anche in questo caso tramite interazione vocale, simulando un confronto diretto con l’utente. Le risposte ottenute sono state interpretate dall’agente che ha poi trasformato i feedback raccolti in nuove user story, strutturate e pronte per essere inserite nel backlog. Anche questo passaggio è stato mediato dallo HumanPO.
Nello specifico questo agente è partito ricavando direttamente dal tool Nifty le storie in stato UAT, per dedurre quali funzionalità fossero state effettivamente completate dal team di sviluppo per effettuare la verifica con utente finale. L’agente ha quindi costruito in autonomia uno script di intervista personalizzato, mirato a ottenere un feedback puntuale dall’utente rispetto alle funzionalità sviluppate.

Per esempio da un elenco di storie trovate dall’agente in Nifty in UAT:

Come editor di un viaggio
voglio caricare contenuti multimediali nel viaggio
affinché gli utenti abbiano informazioni visive oltre al testo, per valutare se il viaggio è di loro interesse.
AC:

• Utente può aggiungere testo esteso che racconti fatti, luoghi e approfondimenti.
• Utente può caricare foto (JPG, PNG), link a video pubblicati su YouTube.
• Per ogni elemento visuale si può aggiungere una didascalia
• L’utente può inserire i contenuti in un form di inserimento che sarà poi quello usato per la visualizzazione.
• Per questa versione usiamo una gabbia grafica semplificata e non modificabile.

Il Synthetic PO ha creato una domanda (inserita come parte della intervista) di questo tipo:

Per quanto concerne la creazione del viaggio, come hai trovato la parte di caricamento degli elementi multimediali? pensi che sia facile aggiungere una immagine o un video? Ogni elemento è facile da completare con la sua descrizione testuale? Come hai trovato la gabbia grafica semplificata? Ti è piaciuta o pensi che debba essere resa più sofisticata?

Viceversa alcune risposte dell’utente fornite all’agent durante l’intervista sono state sintetizzate e poi trasformate in storie di correzione da passare al dev team. Per esempio — riportiamo un caso molto semplice) quando durante la review l’utente ha detto:

“La procedura di creazione del viaggio è chiara, ma le caratteristiche del viaggio vanno ripensate: non ‘evita pedaggi’ ma ‘presenza di pedaggi’ ecc. Aggiungere voci come durata visite, gastronomia, interesse culturale…”

Il custom bot ha poi creato una storia di questo tipo:

User Story 3.7.2 – Caratteristiche del viaggio [CORREZIONE]
In qualità di utente autorizzare a creare un viaggio (ranger/admin),
vorrei che le caratteristiche del viaggio indicassero ciò che è presente (p.e.: presenza di pedaggi, attrazioni culturali, ecc.),
affinché il viaggio, una volta pubblicato, sia facilmente ricercabile da un motociclista per complessità o attività da svolgere. 

Criteri di accettazione

• Checkbox o tag riformulati in forma positiva (es. “presenza di pedaggi” anziché “evita pedaggi”).
• Aggiunta di nuove voci: durata visite, gastronomia, interesse storico-culturale.
• Validazione che queste caratteristiche influenzino la creazione dell’itinerario.

Questo sistema ci ha permesso di orchestrare un flusso semi-automatico dalla raccolta del bisogno alla trasformazione in storie, fino alla validazione e riformulazione iterativa, mantenendo sempre il controllo umano nelle fasi cruciali.

Lo schema dell’intero processo che vede alternarsi utenti e agenti GPT. Il tutto sotto la supervisione di un PO umano.

Considerazioni finali

Questa prima parte del nostro esperimento ha dimostrato come l’intelligenza artificiale possa supportare e in parte guidare fasi complesse come la definizione della vision e la validazione del prodotto. Tuttavia, l’integrazione tra agenti GPT, interfacce vocali e strumenti di project management è risultata ancora macchinosa. Molte operazioni hanno richiesto interventi manuali e soluzioni ad hoc.
Nonostante ciò, i risultati ottenuti indicano che, con un’infrastruttura più integrata e fluida, il Vibe Coding potrebbe evolvere da prototipo a soluzione concreta per lo sviluppo software Agile.

Nella seconda parte approfondiamo come abbiamo sfruttato gli agenti AI per la generazione del codice.