Se tutti possono programmare, quanto vale saperlo fare?
Senza filtri #25
Qualche settimana fa un mio cliente mi scrive un messaggio che potrei riassumere cosi:
“Abbiamo speso 40.000 dollari per un top developer americano. Quattro mesi di lavoro su un MVP. Centinaia di interviste fatte. Il prodotto dovrebbe essere perfetto. Eppure stiamo girando a vuoto.”
Il problema non era il developer, lui era bravo, forse anche troppo. La piattaforma invece era diventata troppo complessa per una fase early stage; troppe automazioni, troppi percorsi di sviluppo, troppa distanza tra chi parla con gli utenti e chi scrive il codice.
Una cosa che vedo succedere spesso è questa: i developer forti in fase super early tendono a portarti fuori strada perché costruiscono l’architettura perfetta per un prodotto che tu non hai ancora validato. Così gli ho suggerito una cosa che fino a poco tempo fa non avrei mai detto a un cliente.
“Ricostruisci tutto con Lovable, da zero. Fallo tu, ma senza developer”.
Michele, product manager, ha ricostruito in quattro giorni quello che era stato sviluppato in quattro mesi.
Quattro giorni. Da solo. Senza scrivere una riga di codice.
Non sarà l’infrastruttura che li porterà a un milione di utenti, ma per la fase in cui sono è perfetto: velocità, controllo, e soprattutto chi parla con gli utenti è la stessa persona che modifica il prodotto. Zero intermediari.
Mentre guardavo il loro nuovo setup funzionare, mi sono fermato a pensare.
Io sono un Fractional CTO: il mio mestiere ruota attorno alla tecnologia, al codice, alle decisioni tecniche. E ho appena consigliato a un cliente di eliminare il developer e fare da solo.
Se tutti possono programmare, quanto vale saperlo fare?
Benvenuti nell’era del vibe coding
Forse hai già sentito questo termine, forse no. Te lo spiego in trenta secondi.
“Vibe coding” è un’espressione coniata da Andrej Karpathy, cofondatore di OpenAI, a febbraio 2025. Significa costruire software “seguendo il vibe”, a sensazione: descrivi quello che vuoi in linguaggio naturale, un’AI lo costruisce per te. Niente sintassi, niente debug manuale, niente anni di studio per capire la differenza tra un framework e l’altro.
Collins Dictionary l’ha eletta parola dell’anno 2025 e non è un caso.
I numeri danno la dimensione del fenomeno. Lovable, uno degli strumenti più popolari in questo spazio, è passato da zero a 200 milioni di dollari di ricavi annuali in 12 mesi con soli 100 dipendenti.
Bolt.new, Cursor, v0, Replit: il mercato degli strumenti per costruire software senza saper programmare è esploso. Le stime parlano di un settore da quasi 3 miliardi di dollari oggi, 325 miliardi entro il 2040.
Ma il punto non sono i numeri. Il punto è cosa significano.
Fino a ieri, solo l’1% della popolazione mondiale sapeva programmare. Il software, che governa praticamente ogni aspetto della nostra vita, era costruito da una casta ristretta di persone con competenze specifiche e anni di formazione.
Oggi quella barriera si sta sgretolando. Un founder può costruire il suo MVP in un weekend. Un marketing manager può crearsi il tool interno che gli serviva senza aprire un ticket al team tech. Uno studente di economia può tirare su un’app con database, autenticazione e pagamenti in un pomeriggio.
Il 99% della popolazione che non sapeva programmare sta entrando nel gioco.
E per chi come me ha costruito la propria carriera su competenze tecniche, questa non è una notizia che si può ignorare.
Cosa perde valore
Devo essere onesto adesso, perché questa parte sarà scomoda.
Se costruire software diventa accessibile a tutti, il valore di “saper costruire software” scende. Si tratta di matematica, non è opinione. Quando una competenza si diffonde, il suo prezzo di mercato cala.
Non sto dicendo che i developer spariranno domani. Sto dicendo che un certo tipo di developer è a rischio.
Il developer che “posa mattoni”. Quello che riceve le specifiche, le implementa e consegna. Quello che è fortissimo nell’esecuzione, ma non si chiede (quasi) mai se quello che sta costruendo ha senso.
Il mio cliente aveva esattamente questo problema. Un developer eccellente dal punto di vista tecnico. Ma nessuno nel team stava rispondendo alla domanda fondamentale: stiamo costruendo la cosa giusta?
Quattro mesi di architettura impeccabile su un prodotto che non aveva ancora trovato il suo mercato. Il come era perfetto. Il cosa e il perché erano completamente fuori fuoco.
E non è un caso isolato, lo vedo continuamente nel mio lavoro. Startup che bruciano mesi e budget su feature che nessuno ha chiesto. Team tecnici che costruiscono soluzioni eleganti a problemi che non esistono. Developer che ottimizzano performance su prodotti che non hanno ancora un utente pagante.
Quando l’esecuzione tecnica era il collo di bottiglia, aveva senso investire tutto lì. Ma se un founder può ricostruire il tuo lavoro di quattro mesi in quattro giorni con un AI builder, il collo di bottiglia si è spostato.
E si è spostato dal “chi sa costruire” a “chi sa cosa costruire” secondo me.
Cosa guadagna valore
Se il codice diventa una commodity, cosa resta?
Resta tutto quello che l’AI non sa fare. E la lista è più lunga di quanto pensi.
Capire il problema vero.
Come ho scritto nella newsletter su WinMX: il vero problema non è mai quello ovvio.
Il cliente che vuole “un sito più veloce” in realtà vuole meno ansia nel processo di checkout.
La startup che cerca “più features” in realtà ha bisogno di capire chi sia il suo utente.
Il founder che chiede “più investimenti” in realtà deve sistemare il product-market-fit.
Lovable può costruirti un’app in un pomeriggio. Ma non può dirti se quell’app risolve un problema reale. Non puo sedersi davanti a un utente e capire che il vero blocco non è tecnologico, ma emotivo.
Non può leggere tra le righe di un feedback e intuire dove sta la vera opportunità.
Sapere cosa NON costruire.
Questa è la skill più sottovalutata in assoluto. Ogni feature che non aggiungi è una feature che non può rompersi, che non va mantenuta, che non complica l’esperienza. Ogni progetto che non inizi è tempo risparmiato per quello che conta davvero.
Il mio cliente ha dovuto buttare via quattro mesi di lavoro perché nessuno aveva avuto il coraggio di dire “fermiamoci, stiamo costruendo troppo”. Avevano automatizzato cose che non serviva automatizzare. Avevano generalizzato quando dovevano specializzare. Avevano costruito per scalare quando dovevano costruire per validare.
La decisione più importante che hanno preso? Smettere di automatizzare.
Mettere una facciata che parla di AI, ma dietro fare il lavoro a mano. Validare prima, automatizzare dopo e concentrarsi su un’unica industry invece di inseguire tutti.
Sembra un passo indietro. È il passo avanti più intelligente che potessero fare.
Tradurre tra due mondi.
Ne ho parlato nella newsletter su come comunico ai non-techy del business: la comunicazione è LA competenza. Puoi avere la soluzione tecnica migliore del mondo, ma se non sai spiegare perché conta al CEO, al commerciale, all’investitore, il tuo impatto resta confinato alla tua tastiera.
Con il vibe coding, questa competenza diventa ancora più critica. Perché ora hai più persone non tecniche che costruiscono cose tecniche, e qualcuno deve fare da ponte. Qualcuno deve dire “questa soluzione funziona oggi ma non scalera tra sei mesi”.
Qualcuno deve tradurre “abbiamo un problema di performance” in “stiamo perdendo il 20% dei clienti al checkout”.
Il gusto di prodotto.
Saper guardare qualcosa e sentire se funziona o no. Non con una metrica, non con un A/B test, ma con quell’intuizione che viene da anni di esperienza nel costruire cose e osservare come le persone le usano.
L’AI può generare dieci versioni di un’interfaccia, ma non sa quale delle dieci farà sentire l’utente a casa.
La riflessione che dovresti fare
Per costruire Lovable, che promette di rendere inutile saper programmare, servono i migliori ingegneri al mondo.
Cento persone che generano 2 milioni di dollari in ricavi ciascuna. Non stiamo parlando di persone qualsiasi, ma tra i migliori cervelli nel mondo dell’AI e dell’ingegneria del software sul pianeta.
Per rendere “inutile” programmare serve concentrare più talento di programmazione in un unico posto di quanto la maggior parte delle aziende tech abbia mai fatto.
Il valore non scompare: si sposta.
Si sposta da “saper scrivere codice” a “saper pensare a cosa il codice deve fare”. Da “eseguire” a “decidere”. Da “costruire” a “orchestrare”.
Il programmatore del futuro non è un muratore che posa mattoni, è un direttore d’orchestra. Sa benissimo quali strumenti usare, quando farli entrare e come farli suonare assieme. Ma, soprattutto, sa riconoscere quando la musica non funziona anche se ogni singolo strumento sta suonando le note giuste.
Il cerchio si chiude
Torniamo al mio cliente e al suo MVP ricostruito in quattro giorni.
Non ha eliminato il bisogno di competenza tecnica, ha eliminato il collo di bottiglia.
Prima: un developer da 40.000 dollari che costruiva l’architettura perfetta per un prodotto non validato.
Dopo: il founder che parla con gli utenti, torna alla scrivania, e modifica il prodotto in tempo reale. Nessun intermediario. Nessun ticket. Nessuna call di allineamento.
Non è che il developer servisse di meno, ma serviva dopo. Prima ci voleva qualcuno che capisse cosa costruire e cosa no, applicando quella competenza che nessun AI builder può replicare.
Guardando la mia carriera, mi rendo conto che il mio valore non è mai stato nel codice che sapevo scrivere, ma è stato nelle domande che sapevo fare. “Ma il vero problema qui qual è?” “Siamo sicuri che questa feature serva?” “Cosa succede se non costruiamo niente e testiamo prima a mano?”
Il codice sta diventando una commodity. La visione no.
E forse, paradossalmente, proprio nel momento in cui tutti possono programmare, chi sa davvero cosa vale la pena costruire diventa più prezioso che mai.
Ci vediamo alla prossima newsletter.
Senza filtri,
Chri