Il collo di bottiglia non è mai stato scrivere il codice.
Il software ha un problema strutturale. Ma non è quello che pensa la maggior parte delle persone.
Il problema non è che scrivere codice sia difficile o lento. Non lo è — almeno non nel senso in cui lo vivono chi commissiona un progetto. Il vero collo di bottiglia è tutto ciò che viene prima: capire cosa si vuole costruire davvero, scrivere i requisiti in modo preciso, portare a galla le feature che "si danno per scontate", mettere in luce i buchi funzionali che emergono solo quando si comincia a usare la cosa.
Un requisito non scritto non è un requisito. È un'aspettativa. E le aspettative, nel software, si pagano sempre — a progetto avviato, mai prima.
La scena è sempre la stessa. "Funziona come ci aspettavamo, ma manca X." X non era scritto da nessuna parte. X era ovvio. X era sottinteso. X era "sì ma era chiaro che lo avremmo voluto". E X costa quanto un mese di sviluppo aggiuntivo, a volte un refactoring dell'intera architettura.
Il vibe coding non cambia questo. Se non hai chiari i requisiti prima, ne avrai di meno chiari dopo — solo più velocemente.
Quando ho dovuto revisionare una codebase fatta col vibe coding.
Mi è capitato di trovarmi in questa situazione esatta. Un progetto in cui uno sviluppatore alle prime armi stava costruendo l'intera codebase con l'AI — velocemente, con entusiasmo, con un approccio che sembrava funzionare. Il mio ruolo era fare code review sul risultato.
Ho capito molto presto una cosa: revisionare una codebase generata così è più faticoso che costruirla da zero.
Non perché il codice fosse sbagliato in senso sintattico. Spesso compilava, spesso funzionava nei casi base. Il problema era la coerenza: nomi inconsistenti, pattern diversi per la stessa cosa, logica duplicata con varianti sottili, nessuna struttura che tenesse man mano che il progetto cresceva. L'AI scrive ogni risposta come se fosse la prima. Non ha memoria del sistema che sta costruendo — o meglio, la memoria è quella della finestra di contesto, non quella dell'architettura complessiva.
Il risultato era codice che andava capito pezzo per pezzo, senza potersi fidare delle convenzioni. Ogni funzione era un'incognita.
Alla fine siamo arrivati a fare così: ho iniziato a vibecodare direttamente io, con la consapevolezza del progetto che avevo accumulato durante le revisioni. Il risultato era migliore e arrivava più in fretta. La seniority non cambia il fatto che l'AI scriva — ma cambia radicalmente cosa le chiedi, come lo chiedi, e soprattutto quando fermarsi a correggere la rotta.
"Il vibe coding non risolve i requisiti che non hai scritto. Ma ti dà il controllo per scoprirli tu stesso."
Per chi non è programmatore — e vuole costruire il suo strumento.
L'aspetto più interessante del vibe coding non è quello economico. Non è "pago meno il dev". Questo è un fraintendimento che porta spesso a delusioni: il progetto non decolla, il prodotto è instabile, ci si ritrova con qualcosa che funziona per qualche mese e poi diventa ingestibile.
L'aspetto realmente nuovo è l'ownership.
Quando costruisci qualcosa tu stesso — anche con l'AI che scrive il codice al posto tuo — il progetto è tuo in un modo diverso. Capisci perché funziona. Sai dove sono i limiti. Puoi modificarlo, estenderlo, adattarlo senza aspettare che qualcun altro trovi il tempo. La distanza tra l'idea e la cosa concreta è quasi zero.
Questo non dipende dalla seniority tecnica. Dipende dal tempo che sei disposto a dedicare a raffinare i prompt, a capire cosa sta succedendo sotto, a iterare fino a quando lo strumento fa esattamente quello che ti serve — non quello che l'AI ha interpretato al primo tentativo. È un processo. Come qualsiasi altro processo di costruzione.
Non è "sono parte del processo perché ho usato l'AI". È "sono parte del processo perché ho definito il problema, iterato sulla soluzione, e capisco cosa ho costruito". Il vibe coding può essere lo strumento. La comprensione deve venire da te.
Il codice non è mai stato il problema.
L'industria del software lo sa da decenni. "Requirements engineering" è un campo intero, con la propria letteratura, i propri pattern di fallimento, le proprie pratiche consolidate. I progetti non falliscono perché il codice è difficile da scrivere. Falliscono perché quello che si voleva costruire non era abbastanza chiaro prima che si iniziasse a costruirlo.
Il vibe coding non cambia questa dinamica. Ma cambia qualcosa di reale: cambia chi può partecipare al processo. E chi partecipa — davvero, con la testa e non solo come committente — porta con sé una comprensione del problema che un developer esterno non avrà mai per default.
Questo, a suo modo, è già abbastanza per renderlo uno strumento serio. A condizione di non confonderlo con una scorciatoia.