Il vibe coding può accelerare un prototipo, ma il risultato va compreso e verificato prima di affidargli un lavoro reale. Nel video parto dalle mie prove con assistenti di intelligenza artificiale per distinguere l'aiuto alla programmazione dalla delega completa dello sviluppo.
La mia posizione non è rifiutare questi strumenti. Li uso e li considero utili, soprattutto quando mi aiutano a esplorare una soluzione senza rinunciare al controllo tecnico.
Che cosa intendo per vibe coding
Nella puntata uso l'espressione per descrivere un processo in cui si racconta a un assistente ciò che l'applicazione dovrebbe fare e si lascia generare il codice, intervenendo soprattutto attraverso nuove richieste.
Il problema emerge quando la persona che guida il processo non sa valutare il risultato. Una schermata convincente può nascondere errori che diventano visibili soltanto con dati o condizioni differenti.
Non significa che ogni esperimento senza competenze sia inutile. Significa che la responsabilità aumenta quando si passa dall'esplorazione a un servizio utilizzato da altri.
Una pagina dimostrativa e un'applicazione completa
Racconto di aver ottenuto risultati interessanti con una semplice pagina vetrina: testo, stile e qualche comportamento dell'interfaccia. Per un compito delimitato è più facile capire a colpo d'occhio se il risultato corrisponda alla richiesta.
Quando entrano in gioco stato, dati, regole e casi limite, la verifica diventa più impegnativa. Anche una pagina statica richiede controlli, ma un'applicazione con più responsabilità amplia il numero di cose che possono andare storte.
Il limite osservato nelle mie prove non va trasformato in una misura universale di tutti i modelli: versioni, istruzioni e strumenti cambiano.
L'esempio del gioco della scopa
Nel video propongo di farsi aiutare a impostare un gioco della scopa. L'assistente può suggerire una struttura o un primo scheletro; chi sviluppa deve poi controllare le regole e completare il lavoro.
Che cosa succede con una presa particolare? Come si calcola il punteggio? Che cosa accade alla fine della partita? Sono domande che mostrano perché un'interfaccia funzionante non basti a dimostrare la correttezza del gioco.
L'aiuto diventa più produttivo quando il problema viene scomposto e ogni parte ha un risultato verificabile.
La manutenzione comincia prima della pubblicazione
Un difetto non riguarda soltanto la reputazione del progetto. Può influire su dati, continuità del servizio e tempo necessario per correggerlo.
Pubblicare il codice come software libero può favorire contributi, ma non garantisce che qualcuno arrivi a sistemarlo. La comunità non sostituisce automaticamente il lavoro di chi rilascia il prodotto.
Per questo il percorso deve includere lettura del codice, prove pertinenti e comprensione delle dipendenze. Chiedere all'assistente un'altra correzione non basta se non si sa che cosa controllare dopo.
Usare l'IA per imparare un passaggio
Uno degli usi che apprezzo è chiedere una spiegazione circoscritta: come funziona una funzione, quale struttura può servire o come affrontare un errore.
Una risposta sintetica può aiutarmi a orientarmi, ma va confrontata con la documentazione quando contano dettagli e compatibilità. Capire il meccanismo permette di adattarlo; copiare senza comprenderlo lascia il problema per il momento in cui qualcosa cambia.
Nella registrazione esprimo anche preferenze tra assistenti. Sono impressioni delle prove del periodo, prive di un benchmark riproducibile: non le considero una graduatoria attuale dei prodotti.
Il criterio con cui valutare il risultato
Prima di usare il codice chiediti se sai descriverne il comportamento, provarne i casi importanti e intervenire quando fallisce. Il livello di verifica deve essere proporzionato all'uso previsto.
Il valore che cerco nell'IA è ridurre il tempo necessario a capire e costruire. Quando la velocità cancella la comprensione, il lavoro risparmiato all'inizio rischia di tornare sotto forma di manutenzione più difficile.
