Introduzione

Vibe coding è un approccio allo sviluppo software che utilizza l’intelligenza artificiale per generare codice da descrizioni in linguaggio naturale. Anziché scrivere codice manualmente, l’utente descrive le funzionalità desiderate, che l’IA traduce in codice eseguibile.

Concetti principali:

• Basato su IA: utilizza modelli linguistici (LLM) addestrati per programmare.
• Prompt-based: gli utenti interagiscono tramite descrizioni in linguaggio naturale, non con codice.
• Focalizzato sugli obiettivi: permette ai creatori di concentrarsi sulla progettazione e sull’esperienza utente.
• Efficienza: accelera lo sviluppo riducendo la necessità di scrivere codice.

È importante chiarire che questo approccio non sostituisce completamente lo sviluppo tradizionale. Anche se l’intelligenza artificiale può generare codice funzionante, resta fondamentale che chi utilizza questi strumenti comprenda il codice prodotto. Questo è particolarmente vero in fase di 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.

In questa miniserie di articoli raccontiamo il lavoro che abbiamo svolto per sperimentare l’approccio AI alla creazione di un prodotto software vero e proprio.

In questo lavoro abbiamo applicato il VibeCoding non solo alla scrittura del codice, ma all’intero ciclo di vita del prodotto: dalla raccolta dei requisiti intervistando utente finale alla scrittura del codice e al deploy online. Per fare questo, abbiamo creato due ambienti di lavoro distinti ma integrati:

• AI Product Ownership: uno spazio in cui sperimentiamo come definire backlog, scrivere storie utente, gestire il refinement e l’evoluzione del prodotto con il supporto dell’AI
• AI Dev: l’ambiente dedicato alla generazione del codice, al setup dell’infrastruttura e alla gestione dei deploy, dove l’intelligenza artificiale assume il ruolo di co-sviluppatore sotto supervisione umana.

Questo approccio ci ha permesso di mantenere il controllo delle decisioni e del codice, pur delegando all’AI una parte significativa dell’esecuzione operativa.

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 esempio, per la scrittura del codice, ci siamo ispirati alle regole del clean code, promossi da autori come Robert C. Martin (“Uncle Bob”), cioè principi e convenzioni necessari per scrivere codice leggibile, mantenibile e privo di ambiguità. Questi principi, includono l’uso di nomi significativi, funzioni brevi, responsabilità chiare per ogni componente e attenzione alla semplicità del design. In un contesto come il nostro, dove il codice è generato dall’IA, il riferimento al clean code serve come criterio per valutare la qualità del codice prodotto, e per dare istruzioni chiare agli agenti su come strutturarlo.

Discorso analogo per la parte di raccolta dei requisiti dove la creazione del backlog è stata possibile grazie all’inserimento di items (user stories) in cui fosse chiaro lo scopo di ogni elemento le conseguenze attese e che fosse rispettato il pattern INVEST. Per quanto concerne taglia degli item del backlog, pur essendo il codice sviluppato in modo autonomo dagli agenti AI, abbiamo preferito tenere storie piccole per ridurre il rischio che l’insorgere di allucinazioni portasse alla creazione di elementi fuori controllo.

Ruolo degli operatori umani

Nel progetto hanno collaborato tre umani e tre attori sintetici. Questi ultimi comprendono due agenti AI (utilizzati rispettivamente per la fase di envisioning e per la raccolta dei feedback) e un ambiente di sviluppo integrato con agenti e strumenti basati su intelligenza artificiale.

Il compito degli umani è stato quello di controllare e supervisionare l’output generato dai sintetici. Questo controllo è avvenuto secondo una logica che si rifà all’espressione You Only Live Once (YOLO) nato nel mondo giovanile post covid per significare una volontà di concentrarsi sulle cose importanti della vita, che è un sola, e tralasciare quelle meno importanti: in VibeCoding indica la volontà di lavorare sulle parti importanti della creazione del prodotto, lasciando alla AI la creazione di quelle ripetitive, non strategiche, ormai elementi standard del sistema; l’architetto del prodotto è interessato a definire la architettura del sistema, non a scriver le routine di apertura di un file o accesso al db. Analogamente sulla parte di definizione dei requisiti ci interessa definire la strategia di prodotto non i dettagli di una maschera UI.

Fra gli utenti umani del progetto abbiamo inserito anche una persona (reale) in qualità di utente finale e che è stato intervistato dai vari bot per raccogliere informazioni prima dello sviluppo e feedback dopo ogni rilascio.

AI Product Ownership

Su questo ambito Abbiamo lavorato sulla vision del prodotto partendo dalla creazione di due customGPT, ciascuno dedicato a una fase specifica del ciclo di vita del prodotto. Il primo agente, una sorta di SyntheticPO , è stato addestrato per intervistare utente finale e raccogliere i suoi Business Needs; tramite l’addestramento ricevuto da parte del PO umano (HumanPO), ha preparato le interviste da fare all’utente finale in modo da raccogliere la visione di alto livello e i vari user business needs. Questa interazione è avvenuta tramite chat testuale, mentre tutte le interazioni agente-utente finale sono avvenute tramite supporto vocale che ha permesso all’agente di fare delle vere e proprie interviste all’utente.

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.

In questa fase abbiamo seguito un approccio più narrativo che analitico: il focus non era tanto sulla formalizzazione di requisiti o sulla raccolta di specifiche dettagliate, ma sulla costruzione di un racconto condiviso con l’utente, fatto di conversazioni, domande aperte e ipotesi da esplorare. È stato un modo per far emergere, attraverso il dialogo, la visione implicita che l’utente aveva del prodotto e tradurla in materiale utile alla fase di progettazione.

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 “sintetica”

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, come per il primo customGPT, è 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, innescando così un nuovo ciclo iterativo di sviluppo e validazione. 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 intervista son 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.

Considerazioni finali

Questa prima parte del lavoro, dedicata alla raccolta dei requisiti e alla costruzione del backlog, è stata particolarmente interessante per il tipo di processo che abbiamo messo in piedi. Si è trattato di un’esplorazione concreta su come strumenti AI possano supportare, e in alcuni casi guidare, fasi delicate come l’envisioning e la validazione. Tuttavia, il sistema nel suo insieme si è rivelato ancora piuttosto macchinoso, in gran parte per via delle difficoltà nell’integrare i vari elementi coinvolti: agenti GPT personalizzati, sistemi vocali, interfacce REST con tool esterni come Nifty. È un limite che al momento abbiamo gestito con diverse soluzioni manuali e accorgimenti tecnici, ma che potrebbe essere superato nel momento in cui decidessimo di evolvere da prototipo a un vero e proprio prodotto integrato, pensato sin dall’inizio per funzionare in modo fluido e orchestrato.

Nel prossimo articolo vedremo come abbiamo usato gli agenti AI per la creazione del codice.