Il vibe coding e la favola che chiunque possa fare software

C'è una narrazione che gira da un paio d'anni e che vende benissimo: scrivi due frasi in italiano a un modello, e quello ti tira fuori un'applicazione. Niente sintassi, niente architettura, niente di niente. L'idea di fondo è che la barriera tecnica sia crollata e che adesso chiunque, con un'idea in testa e un abbonamento, possa costruire prodotti software.

È una bugia. O meglio: è una mezza verità raccontata nel modo più ingannevole possibile, e la differenza tra la metà vera e la metà falsa è esattamente ciò che separa chi produce roba che funziona da chi produce macerie che sembrano software.

Lo dico da chi il vibe coding lo fa davvero, tutti i giorni, su sistemi che vanno in produzione e che hanno utenti veri dall'altra parte. Non scrivo quasi più codice a mano. Orchestro. Definisco l'architettura, fisso i vincoli, scrivo le specifiche, e lascio che il modello implementi. Funziona. Ma funziona perché so cosa sto facendo, non al posto del fatto che dovrei saperlo.

Cosa è realmente il vibe coding quando funziona

Quando il vibe coding funziona, non stai "non programmando". Stai programmando a un livello di astrazione più alto. Il lavoro non sparisce: si sposta. Invece di scrivere il for ciclo, scrivi la specifica del comportamento. Invece di battere la query, decidi il modello dei dati e poi verifichi che la query generata non sia una schifezza non-sargable che ti manda la CPU del database al 100%.

Il prompt non è una chiacchierata. Il prompt è una specifica tecnica. E scrivere una specifica tecnica decente richiede esattamente le stesse competenze che servivano prima: sapere cosa vuoi, sapere come si struttura, sapere riconoscere quando la risposta è sbagliata. Il modello è una leva. Una leva amplifica la forza che ci metti tu. Se la competenza che ci metti è zero, la leva amplifica lo zero.

Perché senza basi produci macerie e non te ne accorgi

Qui sta il punto che la narrazione da venditori si guarda bene dal dire.

Il problema non è solo che senza basi scrivi codice cattivo. È che non sei in grado di accorgertene. Il modello ti restituisce qualcosa che sembra un'applicazione: si avvia, fa quello che gli hai chiesto nel caso felice, le schermate ci sono. Per chi non ha le basi, lì finisce la storia: "funziona". Per chi le basi le ha, lì comincia il lavoro vero: ma questa cosa regge il carico? Cosa succede con dieci richieste in parallelo? La gestione degli errori esiste o è una finzione? Questa autenticazione è sicura o ho appena messo online una porta aperta? Questi dati sono al sicuro o basta una query malformata per buttare giù tutto?

Chi non sa leggere il codice generato non può rispondere a nessuna di queste domande. E un sistema che non regge il carico, che non gestisce gli errori, che ha una sicurezza fittizia, non è software. È una demo che esplode al primo contatto con la realtà.

Il modello ti dà la media, e la media è mediocre

Due cose che ho imparato sul campo e che da sole demoliscono l'idea del "chiunque ce la fa".

La prima riguarda da dove vengono le risposte del modello. Un modello ha imparato da una massa enorme di codice scritto da altri, e la gran parte del codice che esiste là fuori è nella migliore delle ipotesi nella media, spesso sotto. Quando gli chiedi qualcosa senza dargli niente di specifico, lui ti restituisce la soluzione più probabile, cioè quella che la maggioranza delle persone scriverebbe. La soluzione mediana. Il guaio è che la mediana del codice in circolazione è roba mediocre, e nessuno ha mai costruito un prodotto che regge partendo dalla mediana.

Il modello non conosce i tuoi vincoli, il tuo carico, i tuoi casi limite, il contesto reale in cui quella cosa girerà. Ti dà la risposta da manuale, buona per il caso generico, che non è mai il tuo caso. Per portarlo sopra la media devi spingerlo via dal suo default: dirgli che lì la regola generale non vale, che serve quest'altra strada perché il tuo contesto è diverso. E per dirglielo devi sapere esattamente in cosa il tuo caso si discosta dalla norma. Chi non lo sa accetta la mediana e la manda in produzione, convinto di aver fatto centro.

La seconda: il modello è compiacente. Se gli dici che la tua idea sbagliata è giusta, tende a darti ragione e a costruirci sopra. Va in loop su strade sbagliate con grande entusiasmo, e non ha nessun freno interno che lo fermi. L'unico freno sei tu. Se non hai il giudizio tecnico per dirgli basta, lui non si ferma da solo: ti accompagna a sbattere, e lo fa col sorriso.

Cosa serve davvero per fare vibe coding sul serio

Riassumendo, senza addolcire niente. Per fare vibe coding in modo che produca qualcosa di sensato servono:

• Saper leggere il codice. Non scriverlo da zero, ma leggerlo sì. Devi poter verificare cosa ti è stato consegnato. Senza questo sei cieco.
• Architettura del software. Sapere cosa chiedere, sapere come si struttura un sistema, e riconoscere quando la soluzione che ti viene proposta è quella mediana da manuale invece di quella giusta per il tuo caso.
• Conoscenza di IT e infrastruttura. Deploy, database, sicurezza, performance. Il codice è la parte facile. Metterlo online in modo che non crolli e che non venga bucato è dove muoiono i dilettanti.
• Saper scomporre e specificare. Tradurre un problema vago in una sequenza di richieste precise. È la competenza che il prompting nasconde sotto la maschera della "conversazione".
• Giudizio per dire di no. Al modello e a te stesso. È l'unica cosa che impedisce a uno strumento compiacente di portarti a fondo.

Notate una cosa: nessuna di queste competenze è sparita con l'arrivo dell'AI. Sono tutte ancora lì. Alcune contano di più di prima, non di meno, perché ora le applichi su volumi di codice che prima non avresti mai potuto produrre da solo nello stesso tempo. La leva è più lunga, quindi gli errori di direzione si pagano più cari.

La barriera non è crollata, si è spostata

La verità onesta è questa: la barriera all'ingresso non è scomparsa. Si è spostata. Prima dovevi saper scrivere il codice. Oggi devi saper dirigere la scrittura del codice. E chi dirige senza sapere cosa dovrebbe uscire non si accorge mai di quando esce sbagliato.

Aggiungo l'unica concessione che mi sento di fare, ed è il motivo del "almeno per ora": gli strumenti migliorano in fretta, e una parte di queste competenze prima o poi verrà assorbita dai modelli. Forse fra qualche anno la frase "chiunque può fare software" sarà meno falsa di adesso. Ma oggi, nel mondo reale, in produzione, con utenti veri, non lo è. Oggi il vibe coding è un moltiplicatore di competenza, non un suo sostituto. Dai a un esperto e ottieni un esperto dieci volte più veloce. Dai a chi non sa nulla e ottieni macerie consegnate dieci volte più in fretta, più l'illusione, pericolosa, di aver costruito qualcosa.