Da due mesi a tre minuti e quarantaquattro secondi: la soglia di accesso tra un’idea e la sua realizzazione.

Io programmo in R.

Qualcuno storcerà il naso e dirà che R non è “programmare” nel senso più classico del termine. Va bene. Chiamiamolo scripting, analisi dati, bioinformatica applicata, statistica computazionale. Ma alla fine sempre codice è: scrivi istruzioni, costruisci funzioni, organizzi dati, correggi errori, cerchi di far fare a una macchina qualcosa che prima esisteva solo nella tua testa.

E io, con R, ci ho passato parecchio tempo.

Durante il PhD ero praticamente attaccato al computer. Dovevo capire la bioinformatica, imparare a trattare dati, costruire script, sbagliare, correggere, ricominciare. R mi è servito moltissimo. Non solo per produrre analisi, ma soprattutto per imparare a ragionare in modo strutturato. Perché il codice, anche quando è brutto, ti obbliga a chiarire il pensiero. Se non sai spiegare a una macchina cosa vuoi fare, probabilmente non l’hai ancora capito davvero nemmeno tu.

Poi però la vita cambia.

Oggi ho un lavoro diverso. R continua a servirmi, ma non è più il centro della mia attività. È diventato una utility. Uno strumento. Una leva. Non qualcosa su cui posso permettermi di passare settimane intere ogni volta che mi viene un’idea.

E il problema è proprio questo: le idee arrivano.

Ti viene in mente uno script utile, una pipeline più elegante, un sistema per automatizzare un’analisi, un modo migliore per visualizzare i dati, una procedura che potrebbe far risparmiare tempo a tutti. Solo che poi fai due conti e capisci che, per svilupparla bene, ti servirebbero due mesi di lavoro quasi costante.

Due mesi che non hai.

Non perché l’idea non serva. Non perché non sia valida. Non perché l’azienda non ne avrebbe beneficio. Semplicemente perché ci sono altre priorità, altre urgenze, altre responsabilità. E quindi molte idee restano lì, ferme a metà strada tra “sarebbe utile” e “non ho tempo di farlo”.

Poi sono arrivati gli LLM.

ChatGPT, Claude, Gemini e compagnia. All’inizio li ho usati come tanti: per fare domande, tradurre, sistemare testi, chiarire concetti. Poi, una sera del 2023, ho provato a fare una cosa diversa: ho descritto a un’AI lo script che volevo realizzare.

Non le ho chiesto una riga di codice. Le ho spiegato il problema.

Le ho detto quali dati avevo, quali analisi volevo ottenere, quali grafici mi servivano, quali output mi aspettavo.

In pratica ho fatto quello che oggi viene chiamato vibe coding: non partire dal codice, ma dall’intenzione. Non scrivere subito la soluzione, ma descrivere bene il risultato desiderato, correggere il tiro, dialogare, testare, rientrare nel codice, chiedere modifiche, rompere qualcosa, aggiustarlo, riprovare.

Il primo risultato non era perfetto.

C’erano errori, parti da sistemare, cose che non funzionavano come volevo. Ma la cosa interessante era un’altra: il lavoro era partito. Non ero più davanti a una pagina bianca. Avevo una struttura, una base, un interlocutore instancabile con cui iterare (e che mi ha portato via le notti perché ero più instancabile di lei!). Dopo circa 18-20 ore di lavoro intenso, distribuite in un botta e risposta serrato con l’AI, ne sono uscito con uno script funzionante. Non un giochino. Uno script vero, utile, abbastanza solido da produrre risultati che poi ho presentato in azienda. E con un discreto successo.

Quella cosa, fatta da solo, mi avrebbe richiesto probabilmente un paio di mesi.

Con l’AI, l’ho portata a casa in meno di un giorno di lavoro reale.

Già questo, per me, era impressionante.

Poi è successa una cosa ancora più interessante.

Dopo circa un anno sono tornato su quello script. Nel frattempo avevo imparato cose nuove (anche tramite vibe-learning!), avevo capito meglio cosa volevo ottenere, erano emerse nuove esigenze. Invece di modificare il vecchio codice pezzo per pezzo, ho deciso di ripartire da zero.

Ho descritto di nuovo all’AI cosa volevo.

Questa volta ero più preciso. Sapevo meglio come formulare la richiesta. Sapevo quali errori evitare. Sapevo quali output chiedere. Sapevo come ragiona l’AI e come guidarla.

Risultato: in 3 minuti e 44 secondi mi ha generato direttamente lo script pronto.

L’ho provato.

Funzionava.

Fine.

Ed è qui che secondo me si capisce davvero il punto.

Non è solo che l’AI scrive codice. Non è solo che fa risparmiare tempo. Non è nemmeno la solita frase pigra: “l’AI farà il lavoro al posto nostro”.

No.

Il punto è che cambia la soglia di accesso tra un’idea e la sua realizzazione.

Prima avevo un’idea e mi chiedevo: “Ho due mesi per svilupparla?”

Poi ho iniziato a chiedermi: “Ho venti ore per costruirla con l’AI?”

Oggi, in alcuni casi, la domanda è diventata: “Riesco a descriverla abbastanza bene da farmela generare in pochi minuti?”

Questa è una differenza enorme.

Perché non elimina il bisogno di competenza.

Anzi, lo rende ancora più importante.

Se non capisci nulla di dati, statistica, codice o logica, rischi solo di ottenere qualcosa che sembra funzionare ma non sai valutare. L’AI accelera, ma non sostituisce il giudizio.

Ti dà una Ferrari, ma se non sai guidare puoi comunque finire fuori strada.

Però, se hai già una base, anche non da programmatore professionista, succede qualcosa di potente: inizi a trasformare più idee in prototipi, più prototipi in strumenti, più strumenti in risultati.

Nel mio caso, in dieci anni, il percorso è stato questo: da due mesi di lavoro potenziale, a venti ore di sviluppo assistito, a tre minuti e quarantaquattro secondi per ottenere una prima versione funzionante.

Non è magia.

È un cambio di interfaccia tra pensiero e codice.

E forse è proprio qui che il vibe coding diventa interessante: non perché rende tutti programmatori, ma perché permette a chi ha idee, competenze di dominio e un minimo di logica tecnica di costruire cose che prima restavano bloccate nel cassetto del “sarebbe bello, ma non ho tempo”.