Dal Vibe Coding al Vibe Engineering

All'inizio sembra quasi facile

Il Vibe Coding ha qualcosa di estremamente potente: descrivi ciò che vuoi ottenere, discuti con l'AI, mostri un errore, chiedi una modifica. In poco tempo compare qualcosa che funziona.

Il salto rispetto a pochi anni fa è enorme. Non hai soltanto uno strumento che completa codice, ma un interlocutore con cui ragionare su un problema, un'architettura, un'interfaccia o una scelta tecnica. È facile farsi trascinare dalla velocità. È successo anche a me.

Quando qualcosa comincia a sfuggire

Poi il progetto cresce. Una modifica piccola ne tocca altre; una decisione presa settimane prima va spiegata di nuovo; soluzioni simili convivono perché sono nate in momenti diversi. Il codice funziona, ma non è più del tutto chiaro perché abbia proprio quella forma.

Non è necessariamente colpa dell'AI. Spesso ha fatto esattamente ciò che le avevo chiesto. La domanda diventa allora: che cosa le avevo chiesto davvero? Quanto contesto aveva? Quali regole erano esplicite e quali esistevano solo nella mia testa?

Human in Command, ma davvero

Uso l'AI per analizzare software, proporre alternative, cercare errori, sviluppare funzioni, predisporre test e documentare. Provo però a mantenere una separazione netta fra ciò che l'AI può fare e ciò che sono io a decidere abbia senso fare.

Più l'AI diventa capace, più è facile lasciarle spazio. E più spazio le lasci, più è importante che il contesto rappresenti davvero l'intenzione del progetto.

VIBE APP nasce da qui

Mi sono chiesto se fosse possibile costruire uno strumento che non sviluppasse software al posto mio, ma mi aiutasse a non perdere il filo mentre lo sviluppo con l'AI. Da questa domanda nasce VIBE APP.

Non è un prodotto finito: è un esperimento. Ogni funzione formalizzata apre nuove domande; alcune sembrano indispensabili sulla carta e inutili nell'uso, altre trasformano un piccolo problema operativo in una questione più ampia.

Esplora l'esperimento VIBE APP →

Il prompt non è più solo un prompt

All'inizio un prompt era il modo per chiedere all'AI di fare qualcosa. Quando il progetto cresce, richieste come “controlla questa funzione” o “aggiungi questa possibilità” diventano fragili: chiare rispetto a cosa? Quali file può toccare? Come si giudica il risultato? Cosa accade se emerge un problema diverso?

Il Prompt Builder nasce per rendere espliciti obiettivo, contesto, perimetro, vincoli e criteri di verifica. Non per generare prompt perfetti, ma per capire quale struttura serva davvero prima che la struttura stessa diventi un costo.

Gli errori che cambiano il metodo

Molte regole che uso oggi non sono nate a tavolino: una modifica ha coinvolto più file del previsto; un agente ha “migliorato” una parte che non avevo chiesto di toccare; una conversazione è diventata difficile da ricostruire.

Per questo, prima di una modifica, chiedo più spesso:

• cosa hai capito;
• che cosa pensi di modificare;
• quali file sono coinvolti.

E soltanto dopo: procedi. Non perché sia la procedura corretta in assoluto, ma perché nel mio caso riduce parecchi problemi.

Memoria, dipendenze, interferenze

Una memoria utile non è un archivio infinito: deve conservare le cose giuste. Ho iniziato a distinguere stato attuale, decisioni importanti, regole da rispettare e storia delle scelte.

Ho anche imparato a distinguere dipendenza e interferenza: due attività possono essere indipendenti sul piano funzionale e scontrarsi comunque se intervengono sullo stesso perimetro del software. Per ora applico una regola conservativa: evitare più writer contemporanei sullo stesso perimetro.

Il problema più difficile potrebbe essere il processo

Se per governare il Vibe Coding devo aggiungere specifiche, regole, verifiche, contesto, memoria e controlli, sto ricostruendo il vecchio software engineering? Forse sì. Oppure sta emergendo un modo di lavorare in cui le discipline restano fondamentali, ma cambiano momento, costo e soggetti che le eseguono.