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. 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.