Orizzonti futuri

La democratizzazione del software: quando chiunque può creare un’app

Il vibe coding ha messo un prototipo funzionante alla portata di chiunque sappia descriverlo, e il mercato ha pagato 60 miliardi di dollari per Cursor come prova. I dati su velocità, sicurezza e manutenzione indicano che il 30 per cento più

Gabriele Masetti · 2026-09-02

Un nome nuovo per una vecchia ambizione

Nel febbraio 2025, Andrej Karpathy, cofondatore di OpenAI ed ex responsabile dell’IA di Tesla, ha pubblicato una breve descrizione del modo in cui aveva cominciato a sviluppare software: «C’è un nuovo modo di programmare che chiamo ‹vibe coding›: ci si lascia guidare completamente dalle sensazioni, si accoglie la crescita esponenziale e ci si dimentica persino che il codice esiste». Ha aggiunto che ormai legge a malapena le differenze tra le versioni del codice, che quando compare un errore lo incolla nel modello senza capirlo e che il codice funziona «molto più spesso di quanto non funzioni».

L’espressione si è diffusa rapidamente perché dava un nome a un fenomeno reale: un numero crescente di persone, compresi ingegneri esperti, creava software funzionante descrivendo ciò che voleva ottenere in linguaggio naturale e lasciando a un modello il compito di realizzarlo.

La tesi della democratizzazione che ne deriva è semplice e, alla luce dei dati, in parte vera: negli ultimi tre anni, il costo di trasformare un’idea in un software funzionante è sceso più rapidamente e più nettamente che in qualsiasi altro periodo dall’arrivo dei fogli di calcolo e degli strumenti per creare siti web con il drag-and-drop. Ma quell’«in parte vera» conta molto. Gli stessi dati che mostrano l’abbassamento delle barriere mostrano anche, con un rigore insolito, dove la barriera non si è affatto abbassata: si è soltanto spostata in una parte del lavoro di cui la maggior parte di chi ha appena iniziato a sviluppare software non conosce ancora l’esistenza.

Gli strumenti e i numeri dietro l’entusiasmo

L’infrastruttura di questo cambiamento non è più un’ipotesi: ha utenti e ricavi. GitHub Copilot, il primo assistente di programmazione basato sull’IA a raggiungere il grande pubblico, aveva circa 20 milioni di utenti a metà del 2025, più di 4,7 milioni di abbonati paganti ed era adottato dalla grande maggioranza delle aziende Fortune 100. Secondo i dati della stessa GitHub, il codice accettato dai suggerimenti di Copilot rappresenta in media circa il 46 per cento del codice che un utente inserisce nei propri commit, con percentuali ancora più alte in alcuni linguaggi.

La crescita di Cursor, l’editor di codice nativo per l’IA costruito attorno a modelli come Claude, è ancora più impressionante: ha superato i 100 milioni di dollari di ricavi annualizzati nel gennaio 2025, i 500 milioni entro giugno e, secondo quanto comunicato, più di 1 miliardo di dollari entro novembre 2025. Sarebbe stata la corsa più rapida mai registrata da un’azienda di software verso ricavi ricorrenti a nove e dieci cifre. E la crescita è proseguita. A maggio 2026, le stime collocavano i ricavi annualizzati di Cursor tra 3 e 4 miliardi di dollari, pur divergendo sulla cifra esatta, mentre una previsione aziendale indicava oltre 6 miliardi entro la fine dell’anno.

Poi ha smesso di essere una startup. Il 16 giugno 2026 SpaceX ha firmato un accordo definitivo per acquistare Anysphere, la società che sviluppa Cursor, per 60 miliardi di dollari in azioni; l’operazione si è conclusa il 14 agosto 2026 e Cursor opera ora come controllata interamente da SpaceX, integrata nel team SpaceXAI. Un editor di codice nato tre anni prima è diventato l’oggetto di una delle maggiori acquisizioni mai registrate per una società finanziata da venture capital: un dato che, di per sé, dice quanto denaro scommetta sulla tesi della democratizzazione.

Una seconda categoria, distinta, di prodotti va oltre l’assistenza al programmatore: punta a eliminare il programmatore dal processo per un’ampia gamma di applicazioni semplici. Replit’s Agent, Lovable, Bolt.new e Vercel’s v0 permettono tutti di descrivere un’app in una finestra di chat e ottenere un prodotto funzionante e già pubblicato, completo di database, autenticazione e hosting, spesso nel giro di pochi minuti.

Lovable, che secondo notizie ampiamente riportate ha raggiunto i 100 milioni di dollari di ricavi annualizzati più rapidamente di quasi ogni altra azienda di software nella storia, è arrivata a 500 milioni nel giugno 2026 e il 12 agosto 2026 ha confermato un round Series C da 400 milioni di dollari, guidato da Menlo Ventures e dallo Scaleup Europe Fund, con una valutazione di 13,3 miliardi di dollari. La società di analisi Sacra stima per Replit ricavi annualizzati di 525 milioni di dollari nell’aprile 2026, rispetto ai circa 300 milioni di fine 2025, e più di 50 milioni di utenti. Secondo quanto riportato, Bolt ha raggiunto i 40 milioni di dollari di ricavi annualizzati entro circa cinque mesi dal lancio. Qualunque siano le cifre precise a cui si assesteranno queste aziende giovani e in rapida evoluzione, la direzione è inequivocabile: si è formato un mercato attorno alla promessa che, per creare un’app, non sia più necessario saper programmare.

Tutto questo si inserisce in una tendenza di più lungo corso, precedente all’IA generativa. Gartner segue da anni il mercato delle piattaforme low-code e no-code e ha previsto che la maggioranza delle nuove applicazioni aziendali sarà realizzata con strumenti low-code, mentre il numero dei «citizen developer» — dipendenti che sviluppano software senza ricoprire formalmente un ruolo ingegneristico — dovrebbe continuare a crescere più rapidamente di quello degli sviluppatori professionisti. L’IA generativa non ha creato questa tendenza: l’ha accelerata, sostituendo le rigide interfacce drag-and-drop con qualcosa di più simile a una conversazione.

Che cosa dicono davvero i dati sulla produttività

La storia più interessante, e più onesta, emerge dagli studi che hanno misurato l’effetto di questi strumenti sul lavoro reale, anziché dalle dichiarazioni dei loro fornitori.

Il punto di partenza è uno studio controllato del 2023, condotto con ricercatori di Microsoft e GitHub, nel quale a 95 sviluppatori professionisti è stato chiesto di realizzare un server HTTP in JavaScript. Chi aveva accesso a Copilot ha completato il compito in media il 55,8% più velocemente: 1 ora e 11 minuti contro 2 ore e 41 minuti. È un effetto ampio e statisticamente significativo. Più di qualsiasi affermazione di marketing, quello studio costituisce la base empirica dell’idea che l’assistenza dell’IA acceleri in modo sostanziale la creazione di software, almeno per compiti ben delimitati, da svolgere partendo da zero, da parte di persone che sanno già programmare.

Uno studio molto diverso complica notevolmente il quadro. METR, un gruppo di ricerca che si occupa di valutazioni dell’IA, ha condotto tra febbraio e giugno 2025 uno studio controllato randomizzato con sviluppatori open source esperti al lavoro su codebase grandi e consolidate: repository con una media di circa un milione di righe di codice, il tipo di ambiente in cui vive gran parte del software reale. Gli sviluppatori, che usavano Cursor con Claude 3.5 Sonnet, prevedevano che gli strumenti li avrebbero resi più veloci di circa il 24%.

Le misurazioni hanno mostrato invece che erano più lenti di circa il 19%. I ricercatori hanno attribuito il risultato al carico cognitivo aggiuntivo richiesto per esaminare e correggere i suggerimenti generati dall’IA e per passare da un contesto all’altro lavorando su codice sconosciuto o complesso. La distanza tra la velocità a cui gli sviluppatori credevano di lavorare e quella effettiva è forse il dato più importante dell’intero dibattito: mostra che la sensazione soggettiva di accelerazione e la realtà misurabile possono andare in direzioni opposte, e che l’effetto dipende molto dal fatto che la codebase sia piccola e nuova oppure grande e consolidata. L’obiezione più ovvia riguarda la data. Claude 3.5 Sonnet era un modello del 2025 e nel 2026 era già indietro di diverse generazioni; resta da capire se un modello attuale invertirebbe il segno del risultato.

Il sondaggio tra gli sviluppatori condotto da Stack Overflow ha rilevato un atteggiamento coerente con questi risultati, che nel frattempo si è accentuato. La quota di sviluppatori che usano o prevedono di usare strumenti di IA è salita dal 76% nel 2024 all’84% nel sondaggio del 2025; il 51% degli sviluppatori professionisti li usa ogni giorno. Nello stesso periodo, la quota di giudizi favorevoli è scesa da oltre il 70% nel 2023 e nel 2024 al 60%, e il 46% degli intervistati ha dichiarato di non fidarsi dell’accuratezza di ciò che producono gli strumenti, contro il 3% che vi ripone molta fiducia. L’uso cresce mentre la fiducia diminuisce: un andamento che di solito si associa a uno strumento che ci si sente obbligati a usare, più che a uno di cui si è certi che migliori il proprio lavoro.

Il problema del 70%

Nessuno ha descritto il limite pratico di questi strumenti con più precisione di Addy Osmani, che si occupa dell’esperienza degli sviluppatori in Google, in un saggio pubblicato nel dicembre 2024. La sua osservazione, basata sull’adozione dell’IA all’interno di una grande organizzazione di ingegneria, è che i modelli di IA possono ormai produrre molto rapidamente circa il 70% di una soluzione: il codice standard, la logica più ovvia, la prima versione di una funzionalità.

Il restante 30% comprende, in misura sproporzionata, le parti difficili: i casi limite, l’integrazione con i sistemi già in produzione e la verifica che la sicurezza e le credenziali API siano gestite correttamente. Quest’ultimo 30%, sosteneva, richiede lo stesso tempo di sempre, perché il problema non è mai stato davvero la velocità di digitazione.

Il risultato, secondo Osmani, è che gli ingegneri dichiarano di sentirsi enormemente più produttivi, mentre il software che le persone usano davvero non migliora in modo altrettanto evidente: guadagni di produttività reali nella singola sessione di programmazione, ma molto meno visibili nei prodotti rilasciati e mantenuti nel tempo.

È così che «chiunque può creare un’app» e «la qualità del software non sta migliorando in modo evidente» risultano essere due fatti compatibili, non una contraddizione. Uno strumento che produce in modo affidabile e senza sforzo il 70% più facile è proprio quello che a chi crea qualcosa per la prima volta sembrerà una democratizzazione, perché quel 70% è sempre stato la parte visibile e gratificante dello sviluppo software. Resta però in gran parte irrilevante per il 30% che determina se il prodotto finale sarà sicuro, corretto e durevole.

La sicurezza e il conto che arriva più tardi

Quel 30 per cento non presenta lo stesso grado di difficoltà in tutti gli ambiti, ma la sicurezza è uno di quelli in cui le prove sono ormai precise e poco lusinghiere. Il 2025 GenAI Code Security Report di Veracode, che ha esaminato il codice prodotto da più di 100 modelli linguistici di grandi dimensioni su una serie standardizzata di 80 compiti di programmazione, ha rilevato che il 45 per cento dei campioni di codice risultanti introduceva almeno una vulnerabilità compresa nella lista OWASP Top 10, il catalogo di riferimento del settore per le falle più comuni e pericolose delle applicazioni web, tra cui la SQL injection e i controlli di accesso difettosi. Il tasso di errore non è migliorato in modo significativo nelle versioni più recenti dei modelli esaminate nei cicli successivi del rapporto, nonostante le dichiarazioni dei fornitori su un miglioramento costante.

Più che una novità, è una conferma. Uno studio di Stanford del 2023, pubblicato alla ACM Conference on Computer and Communications Security, ha dato ai partecipanti accesso a un assistente di programmazione basato sul modello Codex di OpenAI e ha chiesto loro di completare una serie di attività di programmazione rilevanti per la sicurezza.

I partecipanti che disponevano dell’assistente di IA hanno scritto codice misurabilmente meno sicuro rispetto a un gruppo di controllo che lavorava senza assistenza. E, nel risultato più sorprendente dello studio, quegli stessi partecipanti erano più convinti che il proprio codice fosse sicuro rispetto agli sviluppatori che non avevano ricevuto alcun aiuto dall’IA.

La direzione di questa valutazione errata racchiude l’intero rischio in una frase: lo strumento che rende le persone più veloci è lo stesso che le rende più sicure di sé, e i due effetti si combinano in modo pericoloso quando alla tastiera c’è qualcuno che sviluppa per la prima volta, senza competenze di sicurezza, anziché un professionista che verifica il codice generato rispetto a specifiche che già conosce.

A chi spetta il codice dopo

L’aspetto di questo cambiamento a cui si presta meno attenzione è ciò che accade a un’applicazione dopo il rilascio. Uno sviluppatore non professionista che usa Lovable o Bolt per creare uno strumento interno, oppure un professionista che rilascia una funzionalità con l’aiuto di un agente di programmazione, si ritrova a gestire un codebase che potrebbe non aver letto per intero, con soluzioni che non ha scelto e dipendenze che non ha selezionato.

L’ingegneria del software tradizionale ha costruito in decenni un insieme di pratiche — revisione del codice, convenzioni di stile, architettura documentata, regole sulla responsabilità del codice — proprio per rendere un codebase comprensibile anche a chi non l’ha scritto. Il software sviluppato con il vibe coding, quasi per definizione, salta questo passaggio al momento della creazione, sulla promessa che il modello possa rigenerarlo o correggerlo nello stesso modo in cui lo ha generato inizialmente.

Questa promessa regge abbastanza bene per le applicazioni piccole, usa e getta e con un unico scopo: una dashboard interna, un prototipo, un progetto del fine settimana senza utenti reali. Regge molto meno quando aumentano la scala, gli utenti e la dipendenza dell’attività dal software, perché bug, correzioni di sicurezza e richieste di nuove funzionalità finiscono per richiedere che qualcuno capisca perché il codice fa ciò che fa, non soltanto che cosa fa.

Le previsioni che Gartner pubblica da tempo sull’adozione del low-code anticipano già questa tensione, prospettando che nei prossimi anni una quota crescente di applicazioni critiche per l’attività, e non soltanto di strumenti interni usa e getta, si baserà su queste fondamenta che richiedono meno codice. Le applicazioni critiche sono proprio la categoria in cui il costo di un codebase illeggibile, non sottoposto a revisione o insicuro smette di essere ipotetico.

La versione onesta della tesi

La democratizzazione del software è reale, ma riguarda una fase precisa: per un’enorme varietà di applicazioni semplici, la distanza tra avere un’idea e vedere un prototipo funzionante si è ridotta drasticamente, e in modo verificabile. I ricavi di Cursor, Replit, Lovable, Bolt e v0 — coronati da un’exit da 60 miliardi di dollari per Cursor nell’agosto 2026 — sono la prova più chiara offerta dal mercato che questa riduzione ha un peso commerciale.

Non si è invece ridotta la distanza tra un prototipo funzionante e un software sicuro, manutenibile e affidabile su larga scala. È ciò che indicano, ciascuno per conto proprio, la sperimentazione di METR, il rapporto di Veracode, lo studio di Stanford e il saggio dello stesso Osmani. Quella distanza si misura ancora in capacità di giudizio ingegneristico, non in token, e nessun modello l’ha ancora colmata.

L’esito realistico non è un mondo in cui l’ingegneria del software professionale scompare, ma uno in cui il baricentro della professione si sposta sempre più verso la lettura, la verifica e la messa in sicurezza del codice che un numero crescente di persone senza formazione ingegneristica può ormai produrre da sé: una divisione del lavoro per la quale il settore non ha ancora sviluppato regole, strumenti o qualifiche professionali.