Per raccontare come lavoro oggi devo partire da molto lontano, perché il presente ha senso soltanto se lo leggo alla luce di un percorso che è cominciato in modo del tutto laterale rispetto al settore in cui poi sono finito. Da dove vengo: BASIC a 9 anni, lettere all’università e nessuna formazione informatica strutturata Chi …
Per raccontare come lavoro oggi devo partire da molto lontano, perché il presente ha senso soltanto se lo leggo alla luce di un percorso che è cominciato in modo del tutto laterale rispetto al settore in cui poi sono finito.
Indice dei contanuti
Toggle- Da dove vengo: BASIC a 9 anni, lettere all’università e nessuna formazione informatica strutturata
- Cosa intendo davvero quando parlo di vibe coding
- Come si distribuisce il mio lavoro oggi: una collaborazione misurata con l’intelligenza artificiale
- Il vero terreno di gioco: la prototipazione rapida
- Cosa cambia in concreto per chi mi affida un progetto
- I limiti reali, raccontati senza filtri
- Tornare indietro? Onestamente, non ci penso.
Da dove vengo: BASIC a 9 anni, lettere all’università e nessuna formazione informatica strutturata
Chi mi conosce sa che ho scritto le prime righe di codice a nove anni, in BASIC, su un computer di famiglia che faceva più rumore di una vecchia stampante a matrice. Era un gioco, una forma di esplorazione che non aveva ancora un nome preciso nella mia testa. Poi è arrivata l’adolescenza e, come succede spesso, il computer è passato in secondo piano per parecchi anni, sostituito da altri interessi più analogici.
Quando mi sono iscritto all’università ho scelto lettere, non informatica. La programmazione è rientrata nella mia vita su un binario parallelo e completamente autonomo: mentre studiavo testi classici, filologia e linguistica, imparavo da solo HTML, CSS, PHP e JavaScript. Nessun corso strutturato, nessun percorso accademico tecnico, soltanto curiosità sistematica, tentativi falliti, errori metabolizzati lentamente e moltissime ore davanti allo schermo a smontare il codice degli altri per capire come funzionasse davvero.
Non racconto questa storia come un vanto, ma come contesto utile per leggere il resto. Quindici anni di lavoro nel web sono costruiti su fondamenta che ho posato un mattone alla volta, in modo disordinato ma genuino. Questo background atipico, fatto di lettere antiche e righe di codice imparate in solitudine, influenza ancora oggi il modo in cui guardo agli strumenti che uso, soprattutto a quelli più nuovi e dirompenti.
Cosa intendo davvero quando parlo di vibe coding
Il termine vibe coding circola in rete da relativamente poco tempo e viene usato in modi spesso contraddittori, a volte come complimento, a volte come accusa di superficialità. Nella mia pratica quotidiana indica una cosa abbastanza precisa: scrivere codice in dialogo continuo con un modello linguistico, descrivendo l’intento prima di scrivere la sintassi, lasciando che il modello produca la prima stesura e intervenendo poi con consapevolezza tecnica per validare, correggere, raffinare. Non è programmazione automatizzata, è programmazione conversazionale, in cui l’umano resta responsabile di ogni decisione strutturale.
La differenza rispetto al passato non sta nello strumento in sé, perché autocompletamento e snippet esistono da decenni, ma nel livello di astrazione del dialogo. Posso descrivere un comportamento desiderato in linguaggio naturale e ottenere una bozza di implementazione coerente nel giro di pochi secondi. Questo cambia la geometria del lavoro in modo non banale, soprattutto nelle prime fasi di un progetto, dove le idee si trasformano rapidamente e ogni minuto risparmiato sulla parte meccanica si traduce in più tempo per la parte progettuale.
Come si distribuisce il mio lavoro oggi: una collaborazione misurata con l’intelligenza artificiale
Se dovessi fotografare la mia giornata lavorativa attuale con un minimo di rigore, direi che circa il 60% del codice che produco nasce in collaborazione diretta con modelli di intelligenza artificiale generativa: scaffolding di componenti, logiche ripetitive, ottimizzazioni di routine, prime stesure di funzionalità nuove, refactoring di porzioni esistenti, generazione di test. Il restante 40% rimane saldamente nelle mie mani: decisioni architetturali, controllo qualità, risoluzione di problemi complessi, gestione del rapporto con il cliente, scelte di sicurezza, vincoli di accessibilità, integrazioni delicate con servizi esterni.
Questa proporzione non è una regola universale, è semplicemente quello che funziona per me dopo mesi di osservazione del mio stesso flusso di lavoro. Non si tratta di delegare il lavoro a una macchina. Si tratta di trovare un ritmo nuovo, in cui la velocità del modello e il giudizio umano si completano in modo coordinato. Il modello propone, io dispongo, dopo aver verificato ogni output secondo criteri tecnici precisi che includono leggibilità, efficienza, manutenibilità nel lungo periodo.
Il vero terreno di gioco: la prototipazione rapida
Se devo indicare il singolo ambito in cui il vibe coding ha cambiato in modo profondo il mio modo di lavorare, scelgo senza esitazione la prototipazione rapida. È qui che la collaborazione con l’AI mostra il suo valore più alto, ed è qui che il beneficio si trasferisce in modo più diretto e misurabile a chi mi affida un progetto.
Per anni la prototipazione è stata uno dei nodi più scomodi del mio lavoro. Costruire un prototipo navigabile, anche minimo, richiedeva un investimento di ore che difficilmente trovava spazio nei budget reali dei clienti, soprattutto per progetti di piccole o medie dimensioni. Il risultato era un compromesso costante: si discuteva il progetto su wireframe statici, su mockup grafici, su descrizioni testuali, sapendo che molte decisioni sarebbero state riviste solo dopo aver visto il prodotto funzionante. Questo generava un effetto a fisarmonica, con cicli di revisione lunghi e talvolta frustranti per entrambe le parti.
Oggi la situazione è molto diversa. Posso costruire un prototipo navigabile, dotato di logica reale per quanto semplificata, in tempi che fino a poco tempo fa erano impensabili. Non parlo di un mockup interattivo, parlo di un’applicazione che gira davvero, con dati di esempio coerenti, schermate collegate, comportamenti realistici. Il cliente non guarda più un’immagine, interagisce con qualcosa che si muove sotto le sue dita.
Perché un prototipo navigabile cambia la qualità delle decisioni
Esiste una differenza qualitativa enorme tra il feedback che si ottiene da un wireframe e quello che si ottiene da un prototipo cliccabile. Davanti a un wireframe il cliente ragiona per intuizioni e immagina come potrebbe funzionare il sistema. Davanti a un prototipo prova il sistema, lo usa, scopre attriti che non aveva previsto, identifica passaggi superflui, riconosce funzionalità mancanti che a parole non sarebbe mai riuscito a esprimere. Il salto cognitivo è notevole.
Questa qualità diversa del feedback ha conseguenze concrete sul progetto finale. Le revisioni diventano più mirate, gli incomprensioni si riducono, le sorprese a fine sviluppo praticamente scompaiono. Il prodotto consegnato somiglia molto più a quello che il cliente aveva davvero in mente, perché il cliente stesso ha avuto modo di chiarirsi le idee toccando con mano un sistema che si comportava come quello finale.
Cosa significa prototipare oggi rispetto a cinque anni fa
Provo a dare qualche esempio concreto, perché senza esempi questi discorsi rischiano di restare astratti. Cinque anni fa, per costruire una bozza navigabile di un’area riservata con autenticazione, dashboard, gestione di profilo utente, avrei impiegato probabilmente tra le quaranta e le sessanta ore di lavoro, considerando setup, scrittura del codice, test minimi, deploy su un ambiente accessibile al cliente. Oggi lo stesso tipo di prototipo, con un livello di realismo paragonabile o persino superiore, lo costruisco in una frazione di quel tempo, con una qualità del codice di partenza che spesso è già discreta.
Lo stesso vale per piccole utility, per landing page con logiche dinamiche, per configuratori di prodotto, per dashboard di reportistica. Tutta una categoria di artefatti che prima richiedevano una valutazione attenta sul rapporto tra costo e beneficio, oggi si producono con una leggerezza che mi permette di proporli quasi sempre, anche su progetti dal budget contenuto.
Cosa cambia in concreto per chi mi affida un progetto
I vantaggi che ho riscontrato nel mio flusso di lavoro non restano sulla mia scrivania, si riflettono in modo abbastanza diretto su chi lavora con me. Provo a descriverli senza enfasi commerciale, soltanto come osservazioni emerse nei mesi recenti.
Prezzi più accessibili senza compromessi sulla qualità
Non perché il lavoro valga meno, ma perché alcune fasi che prima richiedevano molte ore di lavoro manuale ora si completano in tempi sensibilmente più brevi. Cerco di trasferire questo risparmio ai clienti in modo diretto, perché ritengo che sia il modo più sano di restituire il guadagno di efficienza che ottengo dagli strumenti. La qualità del prodotto finale resta sotto il mio controllo, perché il codice generato dall’AI viene comunque letto, validato, riscritto dove serve.
Prototipi live fin dalle prime fasi del progetto
Prima era difficile proporli, oggi è diventata una pratica normale nel mio modo di lavorare. Il cliente può vedere e toccare qualcosa di reale molto prima che venga scritto il codice definitivo, e questo gli permette di prendere decisioni informate quando ancora il costo di cambiare strada è basso. È uno dei cambiamenti più sostanziali della mia pratica professionale negli ultimi anni.
Revisioni più precise e cicli più corti
Quando il cliente interagisce con qualcosa di concreto invece di guardare elementi statici, le sue indicazioni diventano più mirate, meno generiche, più operative. Il risultato finale tende ad essere più vicino a quello che aveva davvero in mente, e i cicli di revisione si accorciano in modo significativo.
Tempi di consegna più rapidi
Alcune fasi di sviluppo che in passato richiedevano giorni si completano in ore. Questo non significa abbassare la qualità del codice finale, che rimane comunque sotto il mio controllo in ogni momento, significa soltanto eliminare attriti meccanici che non aggiungevano valore al prodotto.
I limiti reali, raccontati senza filtri
Sarebbe disonesto raccontare soltanto il lato luminoso di questa pratica. Esistono limiti precisi che è bene tenere presenti, soprattutto quando si valuta se affidarsi a un professionista che lavora in questo modo.
Il primo limite riguarda la complessità. Su applicazioni con logica di business molto articolata, integrazioni delicate, vincoli di performance stringenti, requisiti di sicurezza non banali, l’AI da sola non basta. Anzi, può generare codice che appare corretto ma nasconde problemi sottili, e individuare quei problemi richiede esperienza diretta, non scorciatoie. È esattamente qui che il 40% di lavoro umano fa la differenza tra un risultato professionale e un disastro mascherato da prototipo funzionante.
Il secondo limite riguarda le allucinazioni del modello. Capita ancora con regolarità che il codice generato faccia riferimento a funzioni inesistenti, a librerie con nomi simili ma non identici, a comportamenti documentati in modo errato. Senza una lettura critica costante questi errori si propagano in silenzio e finiscono per emergere nel momento peggiore, in produzione.
Il terzo limite riguarda la manutenibilità nel lungo periodo. Codice scritto velocemente con un modello, senza una revisione attenta, tende ad accumulare debito tecnico in modo subdolo. Per questo dedico tempo a riscrivere porzioni di output che funzionano ma non rispettano gli standard che voglio mantenere nei miei progetti.
Tornare indietro? Onestamente, non ci penso.
Il vibe coding è ancora una pratica giovane e gli strumenti evolvono a una velocità che non avevo mai visto prima in questo settore. Ci sono ancora molti limiti, molte cose che non funzionano come promesso, tanto margine di miglioramento, tanti slogan da cui prendere le distanze con un certo scetticismo.
Quello che posso dire, dopo averlo usato concretamente per mesi, è che qualcosa di reale sta succedendo, soprattutto sul fronte della prototipazione rapida. Non perché l’AI faccia tutto da sola, ma perché, unita a quindici anni di pratica sul campo, permette di offrire qualcosa che prima era difficile da proporre: velocità, qualità accettabile fin dalle prime fasi, prezzi ragionevoli, prototipi navigabili che cambiano la qualità della conversazione con il cliente.
Non è magia. Richiede ancora competenza, attenzione, disciplina, un po’ di esperienza per non fidarsi ciecamente di quello che il modello produce. Tuttavia, rispetto a tante promesse che ho sentito nel corso della mia carriera, questa volta mi sembra che ci sia qualcosa di concreto sotto la superficie. La prototipazione rapida, in particolare, è il terreno in cui questa concretezza si vede meglio, perché è lì che la velocità della macchina e il giudizio dell’umano si incontrano nel modo più produttivo che abbia mai sperimentato.
