Come fare vibe coding con Claude (seconda parte)

Cinque progetti costruiti con Claude fra dicembre 2025 e luglio 2026, messi in fila dal più semplice al più complesso, dal simulatore del ciclo cardiaco all’interfaccia per i modelli locali. È la seconda parte del percorso sul vibe coding, e mostra il metodo all’opera. Da un progetto al successivo ho preso più decisioni e fatto più verifiche, mentre la competenza tecnica che mi serviva è restata la stessa.

La prima parte di questo percorso dice cos’è il vibe coding e dove il discorso sul metodo finisce. Questa seconda parte lo mostra all’opera su cinque progetti, costruiti con Claude fra dicembre 2025 e luglio 2026 e pubblicati tutti su GitHub.

Ho ordinato i cinque progetti per complessità e non per data. Il primo è una pagina che si apre nel browser e l’ho costruita in poco più di un giorno, l’ultimo è un’applicazione con un’architettura complessa fatta di più parti che devono funzionare insieme. Ho scelto anche cinque progetti di tipo diverso, perché con il vibe coding si costruiscono risultati molto diversi.

Si parte dal progetto più semplice, il simulatore del ciclo cardiaco.

Il simulatore mostra il funzionamento del cuore in sette fasi, lasciando all’utente la libertà di spostarsi dall’una all’altra e di cliccare sulle parti del cuore. Per costruirlo mi è bastato descrivere a Claude cosa serviva e correggere il risultato a ogni giro.

Nel simulatore mi sono concentrato sugli aspetti didattici. Il progetto che segue è tecnico e ha richiesto alcuni giorni. È stato il mio primo progetto con il vibe coding, come dice l’articolo il suo argomento centrale non è GIMP.

Un connettore permette a Claude Desktop di comandare GIMP 3 attraverso un server MCP, il Model Context Protocol. Con i modelli precedenti il lavoro si fermava di continuo, Opus 4.5 lo ha sbloccato. Ho fatto il committente, il tester e il direttore dei lavori, e mi è servito descrivere con precisione, conoscere il funzionamento di GIMP e leggere i messaggi di errore.

Il connettore è solo una dimostrazione, ha poche funzioni e non l’ho mai portato in produzione. Altri progetti invece escono in gradi diversi e crescono nel tempo. Quello che segue è nato come prototipo a fine dicembre 2025, e due mesi dopo aveva strumenti di editing, controlli di validazione e un manuale in due lingue.

ChoiceMap è un framework per documentare processi a scelte multiple. L’utente base, che si limita a usare le mappe create da altri, percorre un albero di decisioni invece di seguire un testo lineare. La versione 2.0 aggiunge la validazione automatica e gli strumenti con cui l’amministratore costruisce e corregge mappe di decine di nodi. Come sviluppatore ho fatto l’analista, ho definito cosa serve, ho provato i casi limite e ho deciso le priorità, mentre Claude scriveva il codice.

So cosa voglio e lo verifico a ogni ciclo, e il ciclo si ripete sempre uguale, descrivo e correggo finché il risultato tiene. Nel progetto che segue ho diviso quel ciclo in due, ho scritto specifica e design in Chat e ho fatto implementare in Code. Chat e Code sono due modalità di Claude Desktop, e le ho usate per ottenere cose diverse.

Più agenti AI discutono un tema da prospettive definite, ognuno tiene il proprio contesto separato, alla fine un moderatore emette il verdetto. ADA si installa sul proprio computer, sono pochi file e funziona con qualsiasi fornitore di modelli, compresi quelli che girano in locale. Per costruirlo mi è servito avere ben chiaro cosa volevo ottenere e riconoscere se il risultato funzionava. Saper scrivere Python non è mai entrato in gioco.

ADA occupa poco spazio sul pc anche perché non gestisce i modelli, li chiede a qualcun altro, un servizio in rete oppure un programma installato sul computer per chi vuole mantenere il controllo totale dei dati.
L’ultimo progetto del percorso è un programma di quel tipo, e tenere i modelli sul computer invece di chiederli altrove lo rende molto più grande.

llama-easy-gui è un’interfaccia locale per llama.cpp, e i modelli stanno sul computer insieme alle conversazioni. A ogni file di modello l’app affianca un manifest, che raccoglie le caratteristiche del modello e i parametri con cui avviarlo. Qui ho lavorato con Claude a più mani, perché ha scritto il codice e ha anche rivisto le mie richieste.

Cosa mostrano i cinque progetti

Nei cinque progetti il codice l’ha scritto sempre Claude, e quella parte non cambia. Dal simulatore all’interfaccia per i modelli locali è cambiato il mio impegno nella fase di analisi e di direzione dei lavori, ho preso più decisioni e fatto più verifiche. Nel primo ho descritto cosa serviva e ho provato come funzionava. Nell’ultimo ho dovuto gestire più dettagli, ad esempio ho stabilito anche come si comporta il programma nei casi limite, cosa deve fare perché un modello non resti acceso in memoria per sbaglio, e quanta pratica tecnica chiedere a chi lo installa.

Anche i ruoli cambiano strada facendo. L’articolo su GIMP li descrive nel modo più netto, io faccio il committente e il tester, Claude scrive il codice. Nell’ultimo progetto Claude rivede anche le mie richieste e segnala quando una scelta è sbagliata. Io e Claude ci scambiamo quindi più di quanto quella descrizione lasci pensare. Il metodo resta lo stesso, e cambia solo la dimensione di quello che costruisco.

Il lettore che già lavora con l’AI misura qui quanto pesa la parte che non si vede, cioè il tempo speso a stabilire cosa serve e a controllare che il risultato lo faccia davvero. Il lettore che non programma trova cinque casi in cui nessuno ha scritto codice a mano. Tutti e due trovano anche il conto di cosa serve al posto del codice, cioè tempo, prove ripetute e la capacità di dire se il risultato è quello atteso.