Condividere e pubblicare¶

Fin qui tutto ciò che si è costruito è rimasto sulla propria macchina. Il convertitore PDF del capitolo 5, il sistema di documentazione e l'arena di discussione del capitolo 6, gli script e gli strumenti nati lungo il percorso vivono in cartelle locali, accessibili solo a chi li ha creati. Per molti progetti è una condizione perfettamente adeguata: uno strumento personale che funziona bene non ha bisogno di un pubblico.

Ma ci sono situazioni in cui il passo successivo diventa naturale. Un collega chiede di provare quello strumento che gli è stato descritto. Un progetto raggiunge una maturità tale da meritare una condivisione più ampia. Oppure, più semplicemente, si vuole un backup sicuro del proprio lavoro, indipendente dal destino del disco rigido.

Questo capitolo copre quel passaggio: dalla cartella locale alla pubblicazione su GitHub, e da lì, per i progetti che lo richiedono, alla messa online accessibile a chiunque. Il capitolo si chiude con un bilancio dei costi del vibe coding e con alcune indicazioni su dove continuare.

Questo è anche un capitolo di consultazione. Il procedimento per pubblicare su GitHub è lo stesso per ogni progetto, e le istruzioni qui sono pensate per essere autosufficienti. Non è necessario rileggere i capitoli precedenti per seguirle.

Pubblicare il codice su GitHub¶

Un repository è una cartella di progetto con una memoria: oltre ai file contiene la cronologia completa di tutte le modifiche fatte nel tempo. Git è lo strumento che crea e gestisce questa cronologia sulla propria macchina. GitHub è un servizio che ospita una copia del repository in cloud, accessibile da qualsiasi dispositivo.

Pubblicare il codice su GitHub è utile anche quando il progetto è strettamente personale. Usare un repository GitHub, sia pubblico che privato, significa avere un backup remoto del proprio lavoro, protetto dalla rottura di un disco o dalla perdita di un computer. Ma i vantaggi vanno oltre la sicurezza, un repository pubblico diventa un portfolio di ciò che si sa costruire, una risorsa condivisibile con colleghi, un punto di partenza per collaborazioni future. Un repository privato è visibile solo al proprietario e può essere reso pubblico in qualsiasi momento.

Non serve che il progetto sia completo o rifinito. GitHub è pieno di lavori in corso, prototipi funzionanti, esperimenti abbandonati e ripresi. La pubblicazione non è un annuncio ufficiale, è un modo pratico di gestire il proprio lavoro.

Creare un account e un repository¶

Il primo passo è registrare un account gratuito su github.com.

Per creare un nuovo repository, dalla pagina principale di GitHub si seleziona il pulsante New. Le informazioni richieste sono il nome del repository, una breve descrizione e la visibilità (pubblico o privato). Se si sta pubblicando un progetto già esistente sulla propria macchina, è importante non inizializzare il repository con un file README, altrimenti GitHub creerà un contenuto iniziale che entrerà in conflitto con il codice locale al momento del primo caricamento.

Installare Git¶

Prima di usare i comandi descritti in questa sezione, Git deve essere installato sul proprio computer. Su Mac è spesso già presente: aprire il Terminale e digitare git --version per verificarlo. Se non è installato, il sistema proporrà automaticamente l'installazione. Su Windows, scaricare l'installer dal sito ufficiale git-scm.com, avviarlo e accettare le impostazioni predefinite. Al termine dell'installazione, aprire il Prompt dei comandi o PowerShell e digitare git --version per verificare che tutto funzioni.

I comandi Git, dall'inizio alla pubblicazione¶

Git è lo strumento che tiene traccia delle modifiche ai file e le sincronizza con GitHub. Il capitolo 7 ne ha introdotto i concetti fondamentali nel contesto del salvataggio locale. Qui gli stessi comandi vengono presentati come riferimento completo, dalla configurazione iniziale alla pubblicazione quotidiana.

Configurazione iniziale (una volta sola, sul proprio computer):

git config --global user.name "Nome Cognome"
git config --global user.email "email@esempio.com"

Il nome e l'indirizzo email vengono associati a ogni modifica registrata. Devono corrispondere a quelli usati per l'account GitHub.

Primo collegamento con GitHub (una volta per ogni progetto):

La cartella del progetto deve contenere almeno i file del progetto stesso. Se si è seguito il metodo descritto nel capitolo 4, la cartella conterrà anche il file spec.md (la specifica di progetto in formato Markdown) e il file CLAUDE.md. È buona pratica aggiungere fin da subito un file .gitignore (descritto più avanti in questo capitolo) per evitare di pubblicare file che non devono finire nel repository.

cd percorso/cartella-progetto
git init
git add .
git commit -m "Primo commit: descrizione del progetto"
git remote add origin https://github.com/utente/nome-repo.git
git branch -M main
git push -u origin main

Ogni comando ha una funzione precisa. - cd sposta il terminale nella cartella del progetto. - git init trasforma quella cartella in un repository Git locale. - git add . dice a Git di includere tutti i file presenti. - git commit -m "..." registra un'istantanea del progetto con un messaggio che descrive lo stato attuale. - git remote add origin collega il repository locale a quello appena creato su GitHub, usando l'indirizzo che GitHub mostra nella pagina del nuovo repository. - git branch -M main imposta il nome del ramo principale. - git push -u origin main carica tutto su GitHub. L'opzione -u serve solo la prima volta, per stabilire il collegamento predefinito tra locale e remoto.

Ciclo quotidiano (ogni volta che si vogliono salvare e pubblicare le modifiche):

git add .
git commit -m "Descrizione di cosa è cambiato"
git push

Tre comandi, sempre gli stessi. - git add . prepara tutte le modifiche. - git commit -m "..." le registra con un messaggio. - git push le carica su GitHub.

Il messaggio di commit è l'unica parte che cambia, ed è l'unica che richiede attenzione, una descrizione breve ma significativa di ciò che è stato modificato. "Aggiunta pagina contatti" è un buon messaggio. "Modifiche varie" non lo è, perché tra un mese non dirà nulla su cosa è cambiato.

Cosa escludere dalla pubblicazione¶

Non tutto ciò che si trova nella cartella del progetto va pubblicato su GitHub. Il file .gitignore dice a Git quali file e cartelle ignorare. Si crea nella cartella principale del progetto e contiene un elenco di nomi o pattern da escludere.

Le esclusioni più importanti riguardano le credenziali. Come discusso nel capitolo 8, file come .env che contengono chiavi API, password o token di accesso non devono mai finire in un repository, nemmeno privato. Altre esclusioni comuni sono le cartelle generate automaticamente dalle dipendenze del progetto (node_modules per JavaScript, __pycache__ per Python, venv per gli ambienti virtuali), i file temporanei del sistema operativo (.DS_Store su Mac, Thumbs.db su Windows), e le cartelle di output che si possono rigenerare.

Non è necessario conoscere tutte le esclusioni a memoria. Si può chiedere a Claude di generare un file .gitignore adatto al proprio progetto, descrivendo le tecnologie utilizzate.

Il README come presentazione¶

Il file README.md è un file di testo in formato Markdown, lo stesso formato usato per i file del manuale e per la specifica di progetto. È la prima cosa che chiunque vede aprendo un repository su GitHub, perché GitHub lo visualizza automaticamente nella pagina principale del progetto. Per un progetto personale è anche una forma di documentazione per il sé futuro: tra sei mesi, rileggendo il README, si ricorderà cosa fa il progetto e come si usa.

Un buon README ha una struttura semplice. Inizia con il nome del progetto e una frase che spiega cosa fa. Segue una sezione che descrive come installarlo, quali dipendenze richiede, come avviarlo. Infine una sezione sull'uso, con un esempio concreto di cosa succede quando lo si avvia.

Chi ha seguito il metodo descritto nel capitolo 4 ha già buona parte di queste informazioni nel file spec.md, la specifica di progetto in formato Markdown che descrive cosa fa l'applicazione, come funziona e quali scelte architetturali sono state fatte. Chiedere a Claude di generare un README a partire dalla specifica è un modo rapido per ottenere un punto di partenza da rivedere e adattare.

La licenza¶

Se il repository è pubblico, chiunque può vedere il codice. Ma "vedere" non significa "usare liberamente", senza una licenza esplicita, il codice è protetto dal diritto d'autore e nessuno ha il diritto di riutilizzarlo.

Aggiungere un file LICENSE nella cartella del progetto chiarisce le regole. Le licenze più comuni per progetti software sono la MIT, che permette a chiunque di usare, modificare e redistribuire il codice con pochissimi vincoli, e la GPL, che in più obbliga chi modifica il codice a dover condividere le modifiche con la stessa licenza. Per contenuti non software, come documentazione o materiale didattico, la famiglia Creative Commons offre opzioni più adatte, inclusa la CC BY-NC che consente l'uso non commerciale.

Non è necessario essere giuristi per scegliere. Il sito choosealicense.com guida la scelta con domande semplici. La regola pratica è partire dalla propria intenzione, chiunque può usarlo liberamente (MIT), chi lo modifica deve condividere (GPL), solo uso non commerciale (CC BY-NC).

Automatizzare la pubblicazione¶

Una volta che il repository è configurato e collegato a GitHub, il ciclo quotidiano di pubblicazione è sempre identico, preparare le modifiche, registrarle con un messaggio, caricarle. Tre comandi nella stessa sequenza, ogni volta. Per un non-sviluppatore che usa il terminale solo per questo, ricordare la sintassi esatta è un attrito inutile.

La soluzione è uno script: un file che contiene quei tre comandi e chiede soltanto il messaggio di commit. Si salva nella cartella del progetto e si avvia con un doppio clic (su Windows) o dal terminale (su Mac e Linux).

Su Windows, creare un file chiamato pubblica.bat nella cartella del progetto, con questo contenuto:

@echo off
echo.
echo === Pubblicazione su GitHub ===
echo.

cd /d "%~dp0"

set /p messaggio="Descrivi le modifiche: "

if "%messaggio%"=="" (
    echo Nessun messaggio inserito. Operazione annullata.
    pause
    exit /b
)

git add .
git commit -m "%messaggio%"
git push

echo.
echo Pubblicazione completata.
pause

Per avviarlo è sufficiente un doppio clic sul file. Lo script si posiziona automaticamente nella cartella giusta (cd /d "%~dp0" significa "spostati nella cartella dove si trova questo script"), chiede il messaggio, e se il messaggio è vuoto annulla l'operazione senza fare nulla.

Su Mac e Linux, creare un file chiamato pubblica.sh nella cartella del progetto, con questo contenuto:

#!/bin/bash
echo ""
echo "=== Pubblicazione su GitHub ==="
echo ""

cd "$(dirname "$0")"

read -p "Descrivi le modifiche: " messaggio

if [ -z "$messaggio" ]; then
    echo "Nessun messaggio inserito. Operazione annullata."
    exit 1
fi

git add .
git commit -m "$messaggio"
git push

echo ""
echo "Pubblicazione completata."

Prima di poterlo usare, è necessario renderlo eseguibile aprendo il terminale nella cartella del progetto e digitando chmod +x pubblica.sh. Da quel momento si avvia con ./pubblica.sh dal terminale.

Lo script è volutamente minimale, fa esattamente ciò che serve e nulla di più. Ma è anche un micro-esempio di vibe coding. Si può chiedere a Claude di personalizzarlo aggiungere un controllo che mostra l'elenco dei file modificati prima di procedere, includere la data nel messaggio di commit, inviare una notifica quando la pubblicazione è completata. Ogni personalizzazione è un esercizio del metodo che il manuale ha descritto fin qui.

Rendere il progetto accessibile¶

Pubblicare il codice su GitHub permette ad altri di vederlo e scaricarlo, ma non di usarlo direttamente. Per vedere una pagina web o usare un'applicazione, serve che il progetto sia online, raggiungibile con un browser da qualsiasi dispositivo. Questo passaggio si chiama deployment.

Non tutti i progetti lo richiedono. Molti strumenti costruiti con il vibe coding funzionano perfettamente come applicazioni locali, senza bisogno di essere raggiungibili dall'esterno. Il convertitore PDF del capitolo 5 è un buon esempio: gira sulla propria macchina, si apre nel browser locale, fa il suo lavoro. La domanda da porsi è se qualcuno deve poter usare questo progetto senza accedere al mio computer.

GitHub Pages per siti statici¶

Se il progetto è un sito composto da file HTML, CSS e JavaScript, senza un componente server, GitHub lo può pubblicare gratuitamente attraverso il servizio GitHub Pages. Il procedimento parte dalle impostazioni del repository, nella sezione Settings, poi Pages, si seleziona il branch da cui pubblicare (di solito main) e la cartella di origine. In pochi minuti il sito è raggiungibile a un indirizzo del tipo utente.github.io/nome-repo.

Il sistema di documentazione descritto nel capitolo 6 funziona esattamente con questo meccanismo: ogni volta che il codice viene caricato su GitHub, una procedura automatica ricostruisce il sito e lo pubblica. GitHub Pages è adatto a documentazione, portfolio, landing page, applicazioni che girano interamente nel browser. Non è adatto a progetti che richiedono un server, come quelli costruiti con Flask o Node.js.

Piattaforme di deployment per applicazioni web¶

Per progetti con un componente server, come le applicazioni Flask costruite nel capitolo 5, servono piattaforme che ospitano e mantengono attivo il server. Vercel, Render e Railway sono tra le più utilizzate, e tutte offrono un livello gratuito sufficiente per progetti personali e piccoli strumenti.

Il meccanismo di base è simile per tutte, si collega il proprio repository su GitHub (quello remoto, non la cartella sul proprio computer) alla piattaforma, si configura il modo in cui l'applicazione deve essere avviata, e da quel momento ogni caricamento su GitHub aggiorna automaticamente la versione online. L'applicazione riceve un indirizzo web pubblico e resta accessibile senza che sia necessario tenere acceso il proprio computer. In pratica, il flusso di lavoro non cambia: si lavora in locale, si pubblica su GitHub con lo script o con i tre comandi, e la piattaforma di deployment si occupa del resto.

I dettagli di configurazione variano da piattaforma a piattaforma e cambiano nel tempo, quindi non è utile descriverli qui in modo procedurale. L'approccio più efficace è chiedere a Claude quale piattaforma è adatta al proprio progetto, descrivendo le tecnologie utilizzate e il tipo di applicazione. Claude può guidare la configurazione passo per passo, adattandola alla situazione specifica.

Quando il deployment non serve¶

La maggior parte dei progetti nati dal vibe coding non ha bisogno di essere online, strumenti personali, automazioni, convertitori, analisi di dati funzionano benissimo in locale. Pubblicare il codice su GitHub è già un passo significativo, che protegge il lavoro e lo rende condivisibile. Il deployment aggiunge valore solo quando qualcun altro deve poter usare il progetto senza avere accesso alla macchina su cui è stato costruito.

Quanto costa davvero¶

Il vibe coding non è gratuito. Non è nemmeno particolarmente costoso, ma un bilancio corretto richiede di considerare tutte le voci, comprese quelle che non si pagano in denaro.

L'abbonamento¶

Claude Desktop è disponibile in diversi piani. Il piano gratuito permette di esplorare la Chat con Claude ma ha limiti significativi per il vibe coding, dal numero di messaggi ridotto alla non disponibilità di Cowork e Code, che questo manuale ha descritto come strumenti centrali per la costruzione di progetti. Il piano Pro è sufficiente per la maggior parte dei progetti descritti in questo manuale. Il piano Max è pensato per sessioni intensive o progetti molto complessi, dove il volume di messaggi del piano Pro non basta.

I prezzi cambiano nel tempo, quindi è preferibile consultare la pagina ufficiale di Anthropic per le cifre aggiornate. Ciò che resta costante è la logica, si paga un abbonamento mensile che dà accesso a un certo volume di utilizzo, non un costo per singolo progetto.

L'hosting¶

Per chi decide di mettere un progetto online, i costi dipendono dalla piattaforma e dal volume di utilizzo. GitHub Pages è gratuito per siti statici. Le piattaforme di deployment come Vercel, Render e Railway offrono livelli gratuiti che bastano per progetti personali con traffico modesto. I costi iniziano quando il progetto ha molti utenti simultanei o richiede risorse server significative, una situazione che raramente si presenta per i progetti descritti in questo manuale.

L'unico costo fisso, facoltativo, è un dominio personalizzato. Registrare un nome come mioprogetto.it costa pochi euro l'anno e non è indispensabile: le piattaforme forniscono un indirizzo funzionante incluso nel servizio.

Il tempo¶

Il costo più significativo del vibe coding non è economico ma temporale. Il metodo riduce drasticamente il tempo rispetto all'imparare a programmare da zero, ma non è istantaneo. Un progetto richiede ore, non minuti, i progetti complessi, come quelli descritti nel capitolo 6, richiedono giorni o settimane di sessioni di lavoro distribuite nel tempo.

La curva di apprendimento esiste ed è reale. I primi progetti sono più lenti perché ogni passaggio è nuovo, configurare l'ambiente, formulare le richieste in modo efficace, testare i risultati, gestire gli errori. Con l'esperienza si sviluppa un'intuizione per cosa funziona, le sessioni diventano più produttive, i problemi si riconoscono prima.

Le alternative a confronto¶

Il vibe coding non è l'unica opzione per chi ha bisogno di uno strumento su misura, e non è sempre la migliore. Un confronto onesto con le alternative aiuta a capire dove si colloca.

Commissionare il progetto a uno sviluppatore professionista è la scelta che produce, potenzialmente, il risultato di qualità più alta. Il costo è significativamente maggiore, ma il prodotto sarà più robusto, meglio strutturato e più facile da mantenere nel tempo. Lo svantaggio è la dipendenza, ogni modifica, anche piccola, richiede un nuovo intervento (e un nuovo costo). Non si impara nulla del processo, e il progetto resta una scatola chiusa.

Gli strumenti no-code come Bubble, Glide o Airtable offrono un percorso più guidato. Per casi d'uso standard, come un modulo di raccolta dati o una semplice applicazione gestionale, possono essere più rapidi del vibe coding. I limiti emergono quando le esigenze si allontanano dai template previsti. In più, il progetto vive all'interno della piattaforma, cambiare strumento significa spesso ricominciare da zero.

Imparare a programmare è l'investimento con il rendimento più alto a lungo termine, ma anche quello che richiede più tempo. Per chi ha un altro lavoro principale, dedicare centinaia di ore all'apprendimento di un linguaggio di programmazione è raramente praticabile.

Rinunciare è sempre un'opzione legittima. Non tutti i problemi meritano uno strumento dedicato, e a volte una soluzione manuale, per quanto meno elegante, è più che sufficiente.

Il vibe coding si colloca in uno spazio preciso tra queste alternative. È adatto a chi ha bisogno di strumenti su misura, ha il tempo per costruirli iterativamente, e trova valore nel processo stesso di costruzione, nel capire a fondo il problema mentre si cerca la soluzione.

Dove andare da qui¶

Questo manuale ha coperto un percorso che va dal concetto di vibe coding alla pubblicazione di un progetto, passando per la configurazione dell'ambiente, la pianificazione, la costruzione, la gestione degli errori e la sicurezza. Ma il percorso del lettore non finisce con l'ultimo capitolo.

Risorse per continuare¶

La documentazione ufficiale di Anthropic è il punto di partenza più affidabile per approfondire le funzionalità di Claude. Il sito docs.claude.com raccoglie guide, tutorial e riferimenti tecnici aggiornati. Per chi sviluppa con le API, docs.anthropic.com offre la documentazione tecnica completa.

Il sito dell'autore, ai-know.pro, pubblica regolarmente contenuti in italiano sulle AI generative, inclusi articoli sul vibe coding e guide pratiche sugli strumenti di Claude.

Per le risorse su argomenti specifici, il suggerimento più utile è anche il più semplice, chiedere direttamente a Claude. A differenza di un elenco statico in un manuale, Claude può indicare documentazione aggiornata, tutorial recenti e risorse pertinenti al problema specifico che si sta affrontando.

Un panorama in evoluzione¶

Il capitolo 1 ha descritto come il termine vibe coding sia nato da un tweet nel febbraio 2025 e sia diventato parola dell'anno in pochi mesi. Da allora la pratica si è estesa oltre la programmazione: vibe design, vibe ops, vibe deploying sono espressioni che emergono in modo indipendente in contesti diversi, a conferma che il metodo, delegare a un'AI e verificare il risultato, si applica a qualsiasi dominio.

Gli strumenti cambiano con una velocità che rende qualsiasi descrizione dettagliata obsoleta nel giro di mesi. Ciò che oggi richiede configurazione manuale domani potrebbe essere automatico. Ciò che oggi è un limite potrebbe essere risolto dal prossimo aggiornamento.

La competenza che resta stabile, indipendente dallo strumento specifico, è quella che il manuale ha cercato di sviluppare: formulare problemi con chiarezza, valutare risultati con spirito critico, iterare fino a ottenere ciò che serve. Sono capacità che non dipendono da Claude, da Git o da una piattaforma di deployment. Sono il nucleo del metodo.

Il vibe coding non è un'identità da acquisire e non è un punto di arrivo. È uno strumento, tra i molti disponibili, per risolvere problemi che prima richiedevano competenze specialistiche. Il valore non sta nella tecnologia che si usa, ma nei problemi che si riesce a risolvere. Continuare a costruire ciò che serve, con gli strumenti che si hanno, è il modo migliore per andare avanti.