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

Nella prima parte di questa serie abbiamo introdotto l’approccio allo sviluppo con agenti AI, partendo dalla definizione della vision, del backlog e dalla raccolta dei primi feedback. In questa seconda puntata entriamo nella fase operativa: le idee prendono forma concreta, il codice inizia a scorrere e il prodotto a delinearsi.

Non si tratta solo di mettere alla prova tool di generazione automatica del codice, ma di costruire un flusso di lavoro efficace, riflettendo su come stia evolvendo il mestiere dello sviluppatore. Per farlo abbiamo allestito ambienti di sviluppo personalizzati, comparato diverse soluzioni e testato agenti AI con approcci distinti.

In questo articolo raccontiamo il percorso che abbiamo seguito: strumenti scelti, ostacoli incontrati, soluzioni adottate e lezioni apprese.

Strumenti AI per lo sviluppo: il panorama attuale

Il cosiddetto Vibe Coding si basa sull’impiego di agenti AI specializzati nella scrittura del codice. Ne abbiamo testati diversi, suddivisibili in tre categorie principali:

1. AI Code Generators

Sono strumenti in grado di generare interi progetti a partire da un semplice prompt: frontend, backend, struttura, tutto automatizzato. Esempi includono Lovable, Bolt e V0. Tuttavia, per quanto impressionanti, li abbiamo accantonati per via della loro scarsa trasparenza e del limitato controllo offerto allo sviluppatore.

2. IDE potenziati dall’AI

Questi strumenti integrano agenti AI direttamente in ambienti di sviluppo (IDE), permettendo di scrivere codice, modificare file o eseguire comandi tramite chat. Offrono maggiore controllo e flessibilità, e si presentano sia come editor autonomi (Cursor, Windsurf, Trae.AI), sia come estensioni per IDE esistenti (Copilot, Cline, Augment Code).

3. Agentic coding tool

Si tratta di agenti utilizzabili da terminale, capaci di generare, modificare ed eseguire codice. Claude Code e Gemini CLI sono due esempi significativi di questa categoria in rapida evoluzione.

Cosa cambia tra uno strumento e l’altro

Tutti questi tool condividono lo stesso nucleo tecnologico: i Large Language Model (LLM) come GPT, Claude o Gemini. In comune hanno anche l’interfaccia conversazionale, attraverso la quale si impartiscono comandi e richieste di generazione codice.

La differenza reale emerge nel modo in cui i prompt vengono elaborati: ogni ambiente arricchisce le richieste dell’utente con un contesto personalizzato (visibile o implicito), che influisce direttamente sul risultato prodotto. Il prompt finale è sempre una combinazione tra input dell’utente e system prompt predefiniti dal tool.

Per il nostro progetto, abbiamo scelto Claude (prima 3.7, poi 4.0) per la sua eccellente capacità di comprendere strutture complesse e generare codice coerente tra file e moduli.

L’importanza degli MCP Server

Accanto agli agenti, abbiamo integrato anche i cosiddetti MCP Server (Model Context Protocol), che ampliano le capacità dell’agente AI permettendogli di dialogare con fonti esterne e servizi.

Nel nostro caso, abbiamo utilizzato:

• Context 7: per accedere a documentazione aggiornata.

• BraveSearch: per ricerche web.

• Sequential Thinking: per la generazione di task.

• Playwright: per test automatizzati via browser.

• GitHub-MCP: per interagire con i repository.

• File System-MCP: per la gestione dei file locali.

Come abbiamo istruito l’agente AI

La fase preliminare di sviluppo è fondamentale per evitare false partenze: è il momento in cui si fornisce il contesto generale e le prime istruzioni al nostro agente AI, per facilitare il più possibile la fase di implementazione.

Nel nostro esempio siamo partiti, come lecito aspettarsi, dai requisiti di prodotto. Il Product Requirement Document (PRD) è stato essenziale per fornire al nostro agente le informazioni generali di contesto e aiutarci a compiere le prime scelte importanti: quali architetture e tecnologie adottare. Tramite il dialogo con il nostro agente AI, abbiamo optato per un’applicazione in Next.js e un database PostgreSQL per la persistenza dei dati.

Per consolidare le scelte fatte e arricchire ulteriormente l’agente AI di informazioni utili, abbiamo creato alcuni file di istruzione personalizzati che includono convenzioni di design, indicazioni architetturali e riferimenti stilistici, fungendo da “galateo” per l’agente AI. Questo “apprendimento contestuale” ha permesso di mantenere uno stile uniforme e di ridurre la necessità di correzioni manuali.

Dal task alla funzionalità: il ciclo di sviluppo

Come in ogni processo agile, siamo partiti dalla scomposizione del PRD in micro-task. Abbiamo chiesto all’agente AI di generarci un file JSON con task, complessità stimata e stato di avanzamento.

Questo semplice “task manager in chat” ci ha permesso di iniziare subito a collaborare con l’AI: in pochi minuti avevamo uno scheletro dell’app funzionante, una home page e delle pagine placeholder, già presentabili agli stakeholder.

Lo sviluppo è proseguito con grande rapidità. Il nostro ruolo si è progressivamente spostato da quello di esecutori a quello di supervisori e orchestratori.

Il nostro flusso di lavoro: 4 fasi chiave

Abbiamo strutturato il lavoro in quattro macro-fasi:

1. Ideazione e pianificazione
   Dalla definizione della vision alla stesura del PRD, passando per la scomposizione in task prioritari.

2. Design e prototipazione
   Con l’ausilio dell’AI abbiamo creato wireframe, sitemap e componenti UI esportabili in Figma, supportati da un design system coerente.

3. Setup dell’ambiente
   Selezione dell’IDE AI, impostazione delle regole operative, creazione del boilerplate e attivazione del CI/CD.

4. Ciclo di sviluppo operativo
   Task per task, l’AI ha proposto piani d’azione, separato logica e test, eseguito il codice e supportato nei commit. Il controllo finale è sempre rimasto umano.

Un nuovo ruolo per lo sviluppatore

È quantomai evidente che il ruolo dello sviluppatore sta subendo un cambiamento sostanziale. Gli sviluppatori sono ancora indispensabili, ma il loro ruolo sta evolvendo: meno focus sull’operatività di basso livello, più sulla strategia. Meno codice scritto a mano, più pensiero critico, architettura e capacità di guidare gli strumenti di intelligenza artificiale.

Trascurare questo aspetto e affidarsi troppo al lavoro dell’IA porta rapidamente all’impossibilità di sviluppare nuove funzionalità, perché il sistema rischia di commettere errori, rompere funzionalità precedenti o semplicemente non rispettare le aspettative sulle nuove feature.

Un altro aspetto meritevole di attenzione è che, tramite il dialogo con l’agente IA, non solo abbiamo la possibilità di controllare e correggere il codice generato, ma anche di imparare nuove competenze. Se ci approcciamo con curiosità al codice che l’IA genera e che non comprendiamo o condividiamo subito, potremmo scoprire nuovi approcci, pattern e tecnicismi in realtà più efficaci di quelli che avremmo adottato sviluppando manualmente.

Etica e responsabilità del vibecoder

Con l’AI lo sviluppatore ottiene veri e propri superpoteri. Ma, come insegna lo zio Ben: “Da grandi poteri derivano grandi responsabilità.”

Abbiamo quindi definito un nostro codice etico da vibecoder:

• Responsabilità: ogni riga che va in produzione è tua, anche se scritta dall’AI.

• Comprensione: non mettere in produzione nulla che non capisci.

• Qualità: l’AI non giustifica codice mediocre.

• Leadership: sei tu a guidare. L’AI è il tuo strumento, non il contrario.

Conclusione

Il Vibe Coding non è solo una nuova tecnica, ma un vero e proprio cambiamento di paradigma nello sviluppo software. Abbiamo visto come, partendo da un’idea, sia possibile costruire rapidamente un’applicazione concreta grazie a un processo strutturato e alla collaborazione con agenti AI ben configurati.

Ma siamo solo all’inizio. Nei prossimi articoli approfondiremo le insidie più comuni, analizzeremo casi concreti e mostreremo codice reale. Perché l’AI accelera, sì, ma solo chi la guida con consapevolezza può davvero farne un vantaggio competitivo.