> ## Content Index > Fetch the complete content index at: https://www.andreacasarin.com/llms.txt > Use this file to discover other available public pages before exploring further. # Un Mese di Vibe Coding: Lezioni Pratiche da un Esperimento Reale - URL: https://www.andreacasarin.com/2025/06/28/mese-vibe-coding-lezioni-pratiche-esperimento-reale/ - Published: 2025-06-28T13:31:56.000Z - Updated: 2026-10-30T11:27:48.000Z - Description: Sviluppo full-AI per 30 giorni: successi, code creep, test ingannevoli e consigli pratici per sfruttare l’intelligenza artificiale senza farsi travolgere. - Author: Andrea Casarin - Tags: annotiquo, italiano Questo mese ho deciso di buttarmi in un esperimento che avevo in mente da tempo: sviluppare un progetto intero usando principalmente l'AI come partner di coding. **Spoiler:** è stata un'esperienza affascinante, ma con qualche sorpresa che non mi aspettavo. --- ## Il contesto dell'esperimento L'idea era semplice: prendere un progetto di media complessità e vedere fino a che punto riuscivo a delegare il lavoro di sviluppo all'intelligenza artificiale. Non parliamo di semplici *snippet* di codice o refactoring minori, ma di **architettura**, **implementazione di feature complete** e **debugging**. Il risultato? Un mese di lavoro intenso che mi ha fatto capire molte cose su come l'AI può (e non può) aiutarci nel nostro lavoro quotidiano. --- ## La regola d'oro: specificità estrema La prima lezione, e probabilmente la più importante, è che con l'AI la **vaghezza è il nemico numero uno**. Se con un developer junior puoi permetterti di dire «implementa un sistema di autenticazione» e aspettarti che faccia le domande giuste, con l'AI questo approccio porta dritto al disastro. Ogni feature va descritta come se stessi scrivendo documentazione per qualcuno che non ha mai visto il progetto. I **Product Requirement Documents** dettagliati non sono un lusso, ma una necessità. L'AI ha bisogno di sapere esattamente cosa fare, come farlo e — soprattutto — cosa **non** fare. > Specificare cosa **non** vuoi è altrettanto importante quanto dire cosa vuoi: evita iniziative creative che poi dovrai sistemare a mano. --- ## Il paradosso delle tecnologie popolari L'AI performa molto meglio su stack mainstream e ben documentati. Ha senso: è stata addestrata su montagne di codice pubblico, tutorial e documentazione di **React**, **Node.js**, **Python** e simili. Quando ho provato a usare librerie più di nicchia o pattern architetturali meno comuni, la qualità delle soluzioni proposte è calata drasticamente: API inventate, approcci teoricamente corretti ma impraticabili. > **La lezione:** se vuoi massimizzare l'efficacia dell'AI, punta su tecnologie con **grandi community** e **documentazione abbondante**. Non è il momento di sperimentare con quella nuova libreria *experimental* trovata su GitHub. --- ## Debugging: dove l'AI mostra i limiti Il debugging è stata l'area più frustrante. L'AI è bravissima a scrivere codice che *sembra* sensato, ma quando qualcosa va storto la sua capacità di analisi sistematica lascia a desiderare. Spesso si fissa su una singola ipotesi e continua a proporre variazioni dello stesso approccio sbagliato. In questi casi conviene fermarsi, analizzare il problema da soli, e poi dare all'AI indicazioni **molto specifiche** su cosa cercare e dove. > **Code Creep**: Ogni ciclo di debug con l'AI — direi il **99 %** delle volte — si traduce nell'**aggiunta di nuovo codice**: patch, controlli extra, logging ridondante. Il risultato è un gonfiarsi costante della *codebase*, con effetti negativi su leggibilità e futura manutenzione. Tenere la situazione sotto controllo richiede **refactoring frequenti** e una **sorveglianza umana costante**. --- ## Test: tra copertura e soluzioni apparenti Di fronte a test falliti, l'AI spesso «risolve» il problema aggiungendo eccezioni, *mock* o log per mascherare l'errore invece di correggere il bug reale. > Questo porta a un **falso senso di sicurezza**: i test passano, ma il difetto di fondo rimane. --- ## Gestione della complessità architetturale Per singole funzioni o moduli isolati i risultati sono spesso eccellenti. Ma mantenere coerenza in un'intera applicazione è un'altra storia. L'AI tende a **ottimizzare localmente** piuttosto che globalmente: crea funzioni perfette per il contesto immediato, che però introducono **inconsistenze** o **duplicazioni** altrove. > **Soluzione:** definire chiaramente pattern e convenzioni *prima* di iniziare, e richiamarli costantemente quando chiedi nuove implementazioni. --- ## Velocità vs Qualità: trovare il giusto equilibrio La velocità di sviluppo con l'AI può essere impressionante, ma c'è un trade‑off importante: il codice generato funziona spesso al primo colpo, ma non sempre è **quello che avresti scritto tu**. A volte mancano ottimizzazioni, altre la struttura non è ideale per future estensioni. Devi decidere quando accettare una soluzione «abbastanza buona» per procedere e quando invece investire tempo nel **raffinare** ciò che l'AI ha prodotto. --- ## Lessons learned e prossimi passi ### Dove l'AI brilla - Boilerplate e setup iniziale di progetti - Implementazione di pattern ben consolidati - (Con supervisione) scrittura di test unitari - Refactoring di codice esistente ### Dove serve ancora la mano umana - Decisioni architetturali complesse - Debugging di problemi non ovvi e prevenzione del *Code Creep* - Ottimizzazioni di performance - Sicurezza, gestione degli errori *edge‑case* e reale copertura dei test --- ## Conclusioni pratiche Se stai pensando di integrare l'AI nel tuo workflow di sviluppo, **inizia gradualmente**. Usala per accelerare le parti più meccaniche, ma mantieni sempre il controllo sulle decisioni architetturali critiche. Investi tempo nella **documentazione**: più specifico sei nei prompt, migliori saranno i risultati. E ricorda: l'AI è uno strumento, non un sostituto del tuo giudizio da developer esperto. Il progetto di cui parlo in questo articolo è online su [annotiquo.com](https://annotiquo.com/?ref=andreacasarin.com). L'estensione del browser è in fase di revisione, ma conto di pubblicarla a breve: l'ho creata principalmente perché ne avevo bisogno io, e spero possa tornare utile anche ad altri. --- Continuerò questo esperimento nei prossimi mesi, esplorando nuovi approcci e condividendo ciò che imparo, iscriviti alla newsletter se vuoi seguirmi in questo percorso. Nel frattempo, spero che queste riflessioni ti siano utili se decidi di provare qualcosa di simile nel tuo team.