Cos’è il vibe coding, il metodo e i suoi confini (prima parte)

Il vibe coding non è una scorciatoia per ottenere software senza saperlo scrivere, è un metodo di delega che vale in qualunque dominio produttivo. Questo percorso mette in fila i tre articoli del blog che lo trattano come metodo. I primi due dicono cos’è e quale competenza richiede, che è analitica e non tecnica. Il terzo mostra dove il discorso sul metodo finisce, perché un’applicazione, una volta che esiste, è un programma come tutti gli altri. I progetti in cui il metodo è stato applicato sono la seconda parte.

Il vibe coding viene raccontato come una scorciatoia tecnica, il modo di ottenere software senza saperlo scrivere. Sul come si costruisce un’applicazione il materiale abbonda, su cosa il metodo chiede a chi lo pratica molto meno. Quasi nessuno dice cosa ne è dell’applicazione una volta che esiste, che è già un’altra questione. Per questo ho voluto fare un percorso usando il materiale che ho già pubblicato.

Fra dicembre 2025 e agosto 2026 sul blog sono stati pubblicati diversi articoli sul vibe coding. Ho separato quelli che ragionano sul metodo da quelli che raccontano i progetti in cui è stato applicato, e ne sono venute due parti che si leggono in sequenza. Questa prima raccoglie i tre articoli di metodo, la seconda i progetti, ordinati per complessità crescente.

L’ordine conta. I progetti se letti per primi somigliano a un portfolio, una serie di cose costruite una dopo l’altra. Letti dopo il metodo diventano la verifica di ciò che il metodo afferma. Chi si ferma a questa prima parte ha comunque una risposta completa alla domanda su cosa sia il vibe coding. Chi prosegue trova i casi su cui quella risposta si è formata.

Le prime due tappe stanno su una linea sola, la terza la interrompe. La prima toglie di mezzo l’idea che il vibe coding riguardi il codice, il modo di delegare la produzione a un’AI è lo stesso quando si genera un programma e quando si scrive un testo. La seconda dà un nome alla competenza che il metodo richiede, analitica e non tecnica, e la traduce nel lavoro che precede la costruzione. La terza cambia oggetto, non parla di come si costruisce ma di cosa succede a ciò che è costruito, e lì il metodo non fa differenza. Il punto di partenza è la domanda che dà il titolo al primo articolo, quale delle due parole conti di più.

Il metodo è alla portata di chiunque e in qualunque dominio, perché non richiede di saper produrre ciò che si delega. Ma la qualità del risultato dipende da quanto chi delega sa verificare, e quella capacità non è distribuita allo stesso modo. Nel proprio mestiere la verifica è quasi immediata, un fotografo vede i difetti di un’immagine e uno scrittore quelli di un testo. Fuori dal proprio mestiere richiede tempo e studio. Costruire software è un mestiere che chi arriva al vibe coding di solito non ha. Per questo la competenza che gli si richiede si sposta dal sapere analizzare il codice ad un livello superiore.

Fin qui il discorso riguarda il metodo, cioè come si decide cosa costruire e come si verifica il risultato. Quando l’applicazione è finita, però, il metodo con cui è nata smette di contare. Il programma dipende da software scritto da altri, e quegli altri non sanno che esiste. Quando uno di quei pezzi cambia il programma smette di funzionare, e sarebbe successo lo stesso se il codice l’avesse scritto un professionista senza usare il vibe coding.

Il quadro d’insieme

Le prime due tappe dicono la stessa cosa da due lati. Il vibe coding non è una tecnica per programmare senza saper programmare, è il modo normale di lavorare bene con un’AI ma applicato al codice. Quello che decide il risultato non è la scrittura del codice ma la capacità di dire cosa serve e di riconoscere se è stato fatto correttamente. La terza tappa non prosegue il ragionamento, lo delimita. Un’applicazione, una volta che esiste, è un programma come tutti gli altri. I guai che le capitano non hanno niente a che vedere con il modo in cui è nata.

Chi lavora già con un’AI guarda soprattutto ai momenti in cui chiede e poi ottiene. Il lavoro che decide il risultato sta prima, quando si stabilisce cosa serve davvero. Chi non programma crede che la barriera sia il codice. La barriera è un’altra, capire se il risultato è giusto, e per capirlo serve conoscere l’argomento, non il linguaggio di programmazione.

La seconda parte del percorso, con i progetti ordinati per complessità crescente, sarà una dimostrazione delle possibilità del vibe coding. Si parte da un prototipo che serviva solo a dimostrare che una cosa si poteva fare e si arriva a strumenti che sono stati condivisi. È lì che si vede fino a dove il metodo arriva.
Ecco il link alla seconda parte del percorso .