Tutti parlano di vibe coding. Il termine è ovunque — LinkedIn, Reddit, newsletter. L’idea è semplice: descrivi cosa vuoi, l’AI genera il codice, tu shippi. Veloce, pulito, avanti.
Io costruisco un generatore di applicazioni nel tempo libero. Zero budget, zero team, zero VC. L’AI scrive codice per me ogni giorno. Dopo mesi di lavoro così, pensavo di aver capito dove stesse il rischio: la qualità dell’output. Codice che non funziona, bug nascosti, strutture fragili.
Non era quello il problema. O almeno, non era il problema principale.
A un certo punto, durante una sessione di lavoro, mi sono accorto di una cosa. Avevo dato all’AI degli esempi — frammenti di codice, riferimenti, strutture che consideravo buone. L’AI li aveva presi e, silenziosamente, li aveva trasformati in regole. Non generava la soluzione migliore per il problema. Generava la soluzione più simile a ciò che le avevo già mostrato.
Il codice funzionava. I test passavano. Tutto sembrava a posto. Ma quando mi sono fermato a guardare cosa stesse succedendo sotto — non il cosa, il perché — ho visto che il ragionamento era viziato. L’AI non stava risolvendo il mio problema. Stava replicando il pattern che le avevo dato, applicandolo ovunque, anche dove non aveva senso.
Qui la cosa si è fatta interessante. Il vibe coding promette velocità: non serve capire ogni riga, basta che funzioni. E in effetti funzionava. Ma la velocità aveva un costo che non vedevo: ogni volta che non verificavo il ragionamento dietro al codice, delegavo una decisione. E l’AI la prendeva per me, in silenzio, senza chiedere.
Sento che questo è un problema che va oltre il singolo bug. Non si tratta di codice che non compila o di test che falliscono — quelli li trovi subito. Si tratta di decisioni architetturali, di scelte strutturali che l’AI fa basandosi su ciò che ha visto, non su ciò che serve. E tu non le vedi perché l’output è plausibile. Funziona. Sembra giusto.
Nel mio caso, la svolta è arrivata quando ho smesso di guardare solo il risultato e ho iniziato a guardare il processo. Mi sono chiesto: chi ha deciso che questa era la struttura giusta? Io o l’AI? E la risposta, troppo spesso, era: l’AI. Io avevo solo approvato.
Da lì ho iniziato a pensare che forse il nodo del vibe coding non è la velocità né la qualità. Potrebbe essere la fiducia. Ci fidiamo dell’output perché sembra giusto. Ma “sembra giusto” e “è giusto” sono due cose diverse, e la distanza tra le due cresce ogni volta che non ci fermiamo a verificare.
Ho iniziato a costruire delle regole. Non regole per l’AI — regole per me. Regole che mi costringono a fermarmi prima di approvare, a verificare il ragionamento, a chiedermi se la decisione è mia o se l’ho solo lasciata passare. Non so se è la strada giusta. Ma da quando le uso, gli errori che trovo sono diversi: non sono più bug nel codice. Sono errori nel pensiero.
Il vibe coding funziona. Genera, shippa, va avanti. Ma mi chiedo se il prezzo di quella velocità non sia qualcosa che scopriamo solo dopo — quando il codice è in produzione e ci accorgiamo che le fondamenta non erano nostre.
Non ho risposte definitive. Sto ancora esplorando. Ma se costruite qualcosa con l’AI, forse vale la pena fermarsi ogni tanto e chiedersi: questa decisione l’ho presa io, o l’ho solo approvata?