Era il 30 Novembre 2022 quando OpenAI rilasciò il proprio LLM come Software As A Service, divenuto disponibile al grande pubblico sotto le sembianze di un chatbot.
Non ci volle molto per vedere i primi post su Reddit del tentativo di sfruttarlo per generare codice, ma forse molti ignorano che tutto e' iniziato già dall'anno precedente, quando GitHub rilasciò Copilot come agente di supporto per l’auto completamento del codice. La differenza però era lampante:
Andiamo 2 anni in avanti quando Cursor, il famoso Editor di Codice AI-first, presentò all'interno del proprio software la modalità Agent, capace di essere autonomo nello sviluppo del codice, potendo esplorare il progetto, modificare i file e utilizzare il terminale.
È la nascita per il grande pubblico dell'Agentic Coding, che nel Febbraio del 2025 prende il nome di Vibe Coding: un modo di creare un prodotto dove l'agente segue le vibe di chi sta sviluppando un software, fidandosi dell'autonomia degli LLM.
Ad oggi il de facto standard nel mondo del vibecoding è l'uso degli strumenti da terminale, come Claude Code e ChatGPT Codex, che mettono a disposizione dei propri modelli di frontiera, tutta la strumentazione per accedere al computer dell'utente, di fatto pareggiando le capacità di uno sviluppatore umano.
VibeCoding e specchietti per le allodole
Persone e aziende, dichiarano pubblicamente di pendere verso Claude, che di fatto sembra essere ad oggi il modello più apprezzato.
La mia tesi è che una parte importante del successo del modello di Anthropic, derivi dall’aver trasformato lo sviluppo assistito dall’AI in un’esperienza di delega e orchestrazione.
La metafora ricorda spesso una gerarchia aziendale:
in alto ci sei tu, che descrivi in chat ciò che vuoi ottenere;
l’agente principale interpreta la richiesta, elabora un piano e definisce la struttura del prodotto;
il lavoro viene suddiviso in attività più piccole;
alcune di queste attività vengono affidate a sotto-agenti specializzati, che operano in parallelo e riportano i risultati all’agente principale.
Sono anche nati esperimenti nei quali l’utente dispone di dashboard per osservare le attività, seguirne l’avanzamento e vederle spostarsi all’interno di una Kanban board. In alcuni sistemi gli agenti possono persino comunicare tra loro in forma di chat di gruppo, usata per potersi coordinare, dividersi il lavoro o segnalare conflitti sulle risorse condivise.
L’esperienza non assomiglia più a quella di una persona che utilizza uno strumento, ma a quella di un dirigente che osserva un team al lavoro.
Ed è qui che entra in gioco quella che considero una forma di gamification.
La potenza percepita di questi sistemi risiede anche nella capacità di massimizzare la sensazione di produttività dell’utente:
Ma attività e avanzamento non sono necessariamente la stessa cosa.
Più agenti significano maggiore parallelismo, che probabilmente portano a duplicazione del lavoro, perdita di contesto, errori di coordinamento e una quantità crescente di codice da revisionare. Le ricerche sull'agentic coding evidenziano problemi ricorrenti legati ad affidabilità, debugging, specifiche incomplete e carico di revisione o economico.
Le campagne di marketing dell’industria dell’intelligenza artificiale hanno contribuito a diffondere l’idea che un utilizzo più esteso degli agenti equivalga automaticamente a una maggiore efficacia. Più attività vengono delegate, più l’utente ha la sensazione di risparmiare tempo e massimizzare il proprio rendimento. Tuttavia, ogni agente aggiuntivo genera nuove conversazioni, nuove letture del contesto, nuove chiamate agli strumenti e nuove risposte.
Articolo sul rewrite di Bun, alternativa a Node, posseduta da Anthropic, fatto totalmente via agentic coding.
Il punto, quindi, non è stabilire se gli agenti siano utili. Lo sono, e in molti casi cambiano radicalmente il modo in cui possiamo costruire software.
La domanda da porci è un’altra:
stiamo realmente diventando più produttivi, oppure stiamo soltanto osservando una rappresentazione della produttività?
My Take
Non sarò io a stabilire quale metodologia sia la migliore in assoluto, anche perché molto dipende dal tipo di progetto, dal tempo a disposizione e dal risultato che si vuole ottenere.
Posso però spiegare il modo in cui utilizzo personalmente questi strumenti.
Prototipazione
Prima di aprire una sessione di programmazione definisco il dominio applicativo, le funzionalità necessarie e le condizioni che permettono di considerare il progetto completato. Arrivo quindi al confronto con il modello avendo già un’idea del problema da risolvere, degli utenti coinvolti e dei flussi principali dell’applicazione.
In questa fase utilizzo l’intelligenza artificiale per verificare il ragionamento, individuare casi trascurati e chiarire requisiti ancora ambigui. Quando si lavora da soli è facile dare per scontati alcuni passaggi, mentre il confronto con il modello costringe a esporli in modo più preciso e rende visibili eventuali mancanze prima che diventino problemi durante lo sviluppo.
Dopo aver definito il prodotto individuo le tecnologie principali: linguaggio, framework, database, librerie fondamentali e modalità di distribuzione. Espongo quindi lo stack al modello per valutarne i limiti e confrontarlo con possibili alternative.
Il confronto può evidenziare problemi di compatibilità, difficoltà di distribuzione, dipendenze poco mantenute o strumenti più adatti a un requisito specifico. Valuto ogni proposta considerando la complessità introdotta, la qualità della documentazione e la manutenzione futura. Il costo di una tecnologia, infatti, raramente coincide con il solo prezzo del servizio.
Inizializzazione del progetto
Una volta scelto lo stack, inizializzo manualmente il progetto.
Potrei delegare anche questa fase, ma preferisco sapere con precisione quali dipendenze sono state installate, quali configurazioni sono presenti e quale struttura viene generata dal framework.
Gli agenti tendono ad ampliare le richieste aggiungendo elementi utili e contemporaneamente i framework provano a farti utilizzare librerie e servizi sponsor.
Considerando che il setup iniziale viene ormai eseguito attraverso un comando e una procedura guidata, preferisco occuparmene direttamente e partire da una base riconoscibile.
In seguito, le funzionalità definite in precedenza vengono trasformate in issue, dove ognuna descrive il risultato atteso, i vincoli, le parti interessate e le verifiche necessarie per considerare concluso il lavoro. Una richiesta circoscritta riduce le decisioni lasciate all’agente e rende più semplice controllare il codice prodotto.
La documentazione prima del codice
Prima dell’implementazione installo le skill che ritengo utili. La scelta avviene in autonomia, sulla base dei comportamenti che voglio ottenere dai miei agenti.
Una parte delle skill riguarda la creazione della documentazione tecnica e i diagrammi UML. Questi file servono a descrivere la struttura dell’applicazione, le relazioni tra i componenti, il modello dei dati e i flussi principali, che accompagneranno lo sviluppo e rimarranno nel repository come riferimento per le sessioni successive, evitando che le decisioni importanti vengano perse.
Le altre skill applicano le regole con cui voglio che venga scritto il codice. Gli agenti tendono spesso ad accumulare responsabilità nello stesso file, produrre codice ripetitivo e risolvere ogni richiesta nel punto più vicino senza osservare il resto del progetto. Con il tempo questo comportamento può generare componenti troppo grandi, logiche duplicate e astrazioni difficili da giustificare.
Per questo stabilisco che i file mantengano responsabilità chiare, che le astrazioni vengano introdotte in presenza di un’utilità concreta e che le funzionalità condivise siano collocate in punti comuni.
Questo perché l’AI tende a concentrarsi sulla richiesta corrente. Senza indicazioni esplicite può risolvere bene il problema locale, non accorgendosi che sta duplicando una logica già presente altrove.
A queste regole generali aggiungo skill specifiche per il linguaggio e il framework. Le convenzioni di un progetto React non sono le stesse di un backend sviluppato con Laravel, NestJS o Spring. Il modello conosce in generale queste tecnologie, ma questo non significa che utilizzi automaticamente le convenzioni che preferisco.
T3 Code e la gestione del lavoro
Come programma per l’AI coding utilizzo T3 Code, strumento gestito da Theo, programmatore con anni di esperienza nella gestione di team e noto divulgatore nell'ambito dello sviluppo software.
I motivi per i quali uso questo piuttosto che altri sono molteplici:
FOSS e Fork-friendly, è gratis e posso sempre ampliarlo in autonomia;
Unisce tutte le funzionalità dei competitor in un'unica interfaccia, da preview del frontend integrata a gestione della repository, fino a terminale e anteprima delle directory;
Non è vendor-locked, quindi il suo funzionamento non è legato a nessun provider AI.
Ha un collegamento diretto con gli IDE, non obbligandomi a rimanere all'interno del software, qualora volessi fare revisioni più approfondite o edit manuali.
La prima cosa che configuro nel software è il comportamento che automaticamente associa ad ogni thread a un nuovo worktree e un nuovo branch. Questo per garantire:
una tracciabilità degli interventi eseguiti;
avere un main pulito e funzionante;
poter parallelamente eseguire almeno un'altra task.
Subito dopo la creazione del worktree e branch, serve un comando di setup che prepara automaticamente l’ambiente di lavoro, questo perché i file non tracciati da git non vengono portati. Grazie all'agente creo quindi lo script e tramite T3code lo associo come comando da eseguire in automatico.
Dopodiché l'agente può iniziare a lavorare sulla propria task e modificare il progetto, senza interferire con le altre attività eseguite in parallelo.
Seppur abbia ribadito che il "mio take" è un'alternativa all'agentic coding, spesso ci sono issue così distanti tra loro, che mi è possibile lavorarci contemporaneamente in 2 sessioni separate, ma sono sempre io che gestisco e non delego il mio compito ad un altro agente.
Al termine di ogni task vengono eseguite l’analisi statica, la suite di test e la build del progetto. Si tratta di un comportamento che ciascun vendor ha integrato nei propri agenti, ma è comunque importante sottolinearlo: queste verifiche riducono il rischio di sprecare ulteriori token, affidandosi a strumenti consolidati, deterministici e ampiamente collaudati.
Poiché tali controlli vengono eseguiti durante lo svolgimento della task, è altrettanto importante mantenersi aggiornati sulle evoluzioni delle alternative disponibili. A seconda della tecnologia utilizzata, infatti, le alternative possono essere numerose e presentare compromessi differenti in termini di tempo di esecuzione, costo computazionale e consumo di token. Questo perché se uno dei controlli fallisce, l’attività non è considerata terminata e il tool aiuta l'agente nella risoluzione.
Quando il task è completo e il progetto supera tutti i controlli previsti passo alla revisione del diff. Controllo la struttura del codice, verifico che la modifica sia coerente con la issue e valuto se siano state aggiunte complessità o astrazioni non richieste.
A quel punto viene aperta una pull request per il merge su main.
Il workflow associato alla pull request esegue nuovamente i controlli automatici prima del merge, integrandoli con test più approfonditi che simulano l'interazione umana. Queste verifiche sono pensate per prevenire regressioni nei flussi critici dell’applicazione, ma non possono essere eseguite al termine di ogni task poiché richiedono diversi minuti per essere completate.
Una volta integrate le funzionalità e testate a dovere tramite un canale di test, utilizzo le release per distribuire la nuova versione.
In questo modo posso ricostruire quali issue e pull request sono entrate in una determinata versione e mantenere un collegamento chiaro tra sviluppo, test e distribuzione.
Il modello che utilizzo
Al momento utilizzo principalmente ChatGPT 5.6 con effort Light o Medium.
Nella mia esperienza è una delle configurazioni con il miglior rapporto tra qualità, costo e velocità per questo tipo di workflow.
Uno degli aspetti che apprezzo maggiormente di questo modello è la sintesi. Quando la documentazione e la issue sono scritte bene, il modello tende a seguire le indicazioni in modo letterale e a produrre modifiche circoscritte, senza aggiungere troppe spiegazioni o proporre continuamente una nuova architettura.
Più il codice è aderente alla richiesta, più la revisione resta semplice. Ma la sintesi nasce anche dalla capacità di riconoscere le responsabilità condivise e centralizzarle, introducendo astrazioni solo quando hanno una reale utilità.
Grazie alle regole applicate dalle skill, riesco a ottenere questo risultato anche utilizzando il modello con un livello di ragionamento ridotto, perché gran parte delle decisioni strutturali è già definita nel contesto del progetto.
Ovviamente esistono attività nelle quali è utile impiegare un modello con maggiore capacità di ragionamento, ma per gran parte delle attività quotidiane bastano già modelli più economici.
Questo mio flusso di lavoro si è dimostrato efficace nello sviluppo di applicazioni mobili, siti web e gestionali, quindi può adattarsi bene ai tanti software sviluppati quotidianamente, che rappresentano la maggior parte del codice scritto.
I livelli di ragionamento più elevati diventano veramente utili quando il problema richiede analisi veramente profonde e un margine di errore necessariamente ridotto, come in casi di refactoring o introduzione a progetti abbandonati, sviluppo a basso livello o realizzazione di sistemi complessi e critici.
Quindi, che ruolo ha realmente l’AI?
Non considero l’LLM il responsabile tecnico del progetto e nemmeno un team al quale affidare un’idea aspettando che restituisca un prodotto completo.
L’LLM mi deve evitare di dover scrivere manualmente ogni riga, di ripetere operazioni meccaniche e di passare tempo su parti che posso descrivere in modo sufficientemente preciso.
Questo mi permette di concentrare più attenzione sulle decisioni che incidono davvero sulla qualità del progetto: la struttura, la semplicità, la manutenibilità, i test e il comportamento finale dell’applicazione.
Un processo ancora lineare
Come si può osservare, il mio modello di sviluppo rimane abbastanza lineare.
C’è ancora molto intervento personale, soprattutto nelle scelte iniziali, nella definizione della struttura, nella suddivisione delle attività e nella revisione del risultato.
Il workflow serve però a ridurre al minimo il lavoro manuale, che non aggiunge valore, e a mantenere sotto controllo i diversi passaggi.
L’inizializzazione è definita, i worktree vengono preparati automaticamente, le regole sono applicate attraverso le skill e ogni task termina con test, static analysis e build.
Una metodologia più agentica potrebbe sicuramente essere più autonoma. Potrebbe prendere più decisioni, coordinare più attività contemporaneamente e richiedere un intervento umano minore durante l’esecuzione.
Personalmente, però, con questo stile di programmazione sono riuscito a presentare MVP realizzati in una manciata di ore di lavoro e distribuite nell’arco di qualche giornata.
Prima dell’introduzione di questi strumenti, progetti simili avrebbero richiesto settimane.
Per me questo rappresenta già un enorme vantaggio.
Non sento quindi la necessità di eliminare anche l’ultima parte di controllo umano soltanto per rendere il processo più autonomo.
Se chi progetta il codice possiede gusto estetico e capacità di giudizio sulle implementazioni, può guidare il modello verso un software che non si limita a funzionare. Può invece ottenere un prodotto coerente, gradevole da utilizzare e strutturato in modo da richiedere meno revisioni.
I tempi di consegna rimangono comunque paragonabili a quelli promessi dai workflow più agentici, ma con costi inferiori e con una maggiore consapevolezza di ciò che è stato costruito.
Questo approccio ha un vantaggio anche dopo la prima consegna, perché un codice scritto bene, organizzato e documentato può essere ampliato senza distruggere ciò che già funzionava.
Le manutenzioni evolutive diventano più rapide perché il modello non deve ogni volta interpretare un progetto privo di regole. Può leggere la documentazione, seguire le skill, individuare la parte corretta dell’applicativo e intervenire senza alterare il resto.
La mia idea è quindi quella di creare software che possano sopravvivere alla “bolla” dell’AI, con prodotti che non dipendano dal modello utilizzato oggi, da una particolare interfaccia o dalla moda del momento. Sono progetti costruiti per ricalcare le mie pratiche di sviluppo, utilizzando l’intelligenza artificiale per accelerarle.
Quando gli strumenti cambieranno, il codice, la documentazione, i test e le decisioni architetturali rimarranno. Ed è proprio questo il risultato che mi interessa ottenere.