Orizzonti futuri

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

Con il vibe coding, chiunque sappia descrivere un prototipo funzionante può realizzarlo, e il mercato ha pagato 60 miliardi di dollari per Cursor a riprova di questa possibilità. I dati su velocità, sicurezza e manutenzione dicono però che

AI.info Team · 2026-09-02

Una parola nuova per una vecchia ambizione

Nel febbraio 2025, Andrej Karpathy, cofondatore di OpenAI ed ex responsabile dell’IA di Tesla, pubblicò una breve descrizione del modo in cui aveva iniziato a sviluppare software: «C’è un nuovo modo di programmare che chiamo ‹vibe coding›: ti lasci guidare completamente dalle sensazioni, abbracci la crescita esponenziale e ti dimentichi persino che il codice esiste». Aggiunse che ormai leggeva a malapena i diff, che quando riceveva un errore lo incollava nel modello senza capirlo e che «per lo più funziona».

L’espressione si diffuse rapidamente perché dava un nome a un fenomeno reale: un numero crescente di persone, tra cui ingegneri esperti, sviluppava software funzionante descrivendo le proprie intenzioni in linguaggio naturale e lasciando a un modello il compito di realizzarle.

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 è diminuito più e più rapidamente che in qualsiasi momento dall’arrivo dei fogli di calcolo e degli strumenti per creare siti web trascinando gli elementi sullo schermo. Ma «in parte vera» è una precisazione importante. Gli stessi dati che mostrano l’abbattimento 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 dei nuovi sviluppatori non conosce ancora l’esistenza.

Gli strumenti e i numeri dietro l’entusiasmo

L’infrastruttura alla base di questo cambiamento non è più un’ipotesi: ha ricavi e utenti. GitHub Copilot, il primo assistente di programmazione basato sull’IA a raggiungere il grande pubblico, contava circa 20 milioni di utenti a metà del 2025 ed era adottato dalla grande maggioranza delle aziende della Fortune 100; a gennaio 2026 aveva superato 4,7 milioni di abbonati paganti. Secondo i dati della stessa GitHub, nei file in cui Copilot era abilitato circa il 46% del codice veniva completato dallo strumento, 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ù sorprendente: ha superato i 100 milioni di dollari di ricavi annualizzati a gennaio 2025, i 500 milioni entro giugno e, secondo quanto dichiarato, il miliardo di dollari entro novembre 2025. Secondo quanto riportato, nessuna azienda di software aveva mai raggiunto così rapidamente ricavi ricorrenti a nove e poi a dieci cifre. E la crescita è proseguita. A maggio 2026, i servizi che ne monitorano i risultati collocavano i ricavi annualizzati di Cursor tra 3 e 4 miliardi di dollari, pur divergendo sulla cifra esatta; secondo una previsione aziendale, avrebbero superato i 6 miliardi di dollari 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, l’azienda dietro Cursor, per 60 miliardi di dollari in azioni; l’operazione si è conclusa il 14 agosto 2026 e Cursor ora opera come società interamente controllata da SpaceX, integrata nel team SpaceXAI. Un editor di codice nato tre anni prima è diventato oggetto di una delle maggiori acquisizioni mai registrate di un’azienda finanziata da venture capital: un segnale, di per sé, di quanti capitali puntino sulla tesi della democratizzazione.

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

Lovable, che secondo numerose ricostruzioni ha raggiunto i 100 milioni di dollari di ricavi annualizzati più rapidamente di quasi tutte le aziende di software della storia, ha toccato i 500 milioni di dollari a giugno 2026 e il 12 agosto 2026 ha confermato un round di finanziamento Series C da 400 milioni di dollari, con una valutazione di 13,3 miliardi di dollari, guidato da Menlo Ventures e dallo Scaleup Europe Fund. Secondo una stima della società di analisi Sacra, ad aprile 2026 Replit aveva ricavi annualizzati per 525 milioni di dollari, contro circa 300 milioni alla fine del 2025, e più di 50 milioni di utenti. Secondo quanto riportato, Bolt ha raggiunto i 40 milioni di dollari di ricavi annualizzati ricorrenti entro circa cinque mesi dal lancio. Qualunque siano le cifre precise su 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 si prevede che il numero dei «citizen developer» — dipendenti che sviluppano software senza ricoprire formalmente un ruolo nell’ingegneria del software — continuerà a crescere più rapidamente di quello degli sviluppatori professionisti. L’IA generativa non ha creato questa tendenza: l’ha accelerata, sostituendo le rigide interfacce in cui si trascinano gli elementi sullo schermo 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é basarsi su ciò che ne dicono i fornitori.

Il risultato fondamentale viene da uno studio controllato del 2023, condotto con ricercatori di Microsoft e GitHub, in cui a 95 sviluppatori professionisti è stato chiesto di realizzare un server HTTP in JavaScript. Gli sviluppatori che avevano accesso a Copilot hanno completato il compito in media il 55,8 per cento più velocemente — 1 ora e 11 minuti contro 2 ore e 41 minuti — con un effetto ampio e statisticamente significativo. Più di qualsiasi affermazione di marketing, quello studio è la base empirica dell’idea che l’assistenza dell’IA acceleri in modo sostanziale la creazione di software, almeno per compiti ben delimitati, svolti partendo da zero da 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 uno studio randomizzato controllato tra febbraio e giugno 2025 con sviluppatori open source esperti che lavoravano su codebase ampie e mature: repository con una media di circa un milione di righe di codice, il tipo di ambiente in cui si trova gran parte del software reale. Gli sviluppatori, che usavano perlopiù Cursor con Claude 3.5 e 3.7 Sonnet, prevedevano che gli strumenti li avrebbero resi circa il 24 per cento più veloci.

Le misurazioni hanno mostrato invece che erano circa il 19 per cento più lenti, un risultato che i ricercatori hanno collegato in parte al tempo perso per esaminare, testare o modificare codice generato dall’IA che gli sviluppatori spesso finivano per scartare. Lo scarto 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 accelerare e la realtà oggettiva possono andare in direzioni opposte, e che l’effetto dipende molto dal fatto che la codebase sia piccola e nuova oppure ampia e consolidata. L’obiezione più ovvia riguarda la data. Claude 3.5 e 3.7 Sonnet erano modelli del 2024 e dell’inizio del 2025, già vecchi di diverse generazioni nel 2026, e resta da capire se un modello attuale ribalti il segno del risultato.

Il sondaggio condotto da Stack Overflow tra gli sviluppatori ha rilevato un andamento analogo nelle opinioni, che da allora si è accentuato. La quota di sviluppatori che usano o prevedono di usare strumenti di IA è salita dal 76 per cento nel 2024 all’84 per cento nel sondaggio del 2025, e il 51 per cento degli sviluppatori professionisti li usa ogni giorno. Nello stesso periodo, la quota di giudizi favorevoli è scesa da oltre il 70 per cento nel 2023 e nel 2024 al 60 per cento, e il 46 per cento degli intervistati ha detto di non fidarsi dell’accuratezza di ciò che gli strumenti producono, contro il 3 per cento che vi ripone molta fiducia. L’uso cresce mentre la fiducia cala: un andamento solitamente associato a uno strumento che le persone si sentono obbligate a usare, più che a uno di cui sono certe che le aiuti a lavorare meglio.

Il problema del 70 per cento

Nessuno ha descritto il limite pratico di questi strumenti con maggiore precisione di Addy Osmani, che all’epoca si occupava dell’esperienza degli sviluppatori presso Google, in un saggio pubblicato nel dicembre 2024. La sua osservazione, nata dall’aver seguito l’adozione dell’IA all’interno di una grande organizzazione di ingegneria del software, è che i modelli di IA possono ormai produrre molto rapidamente circa il 70 per cento di una soluzione: il codice standard, la logica più ovvia, la prima versione di una funzionalità.

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

Il risultato, secondo Osmani, è che gli ingegneri riferiscono di sentirsi molto 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 distribuiti 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, anziché una contraddizione. Uno strumento che produce gratuitamente e in modo affidabile il 70 per cento più facile è esattamente quello che a chi crea qualcosa per la prima volta darà l’impressione di una democratizzazione — perché quel 70 per cento è sempre stato la parte visibile e gratificante dello sviluppo software — pur restando in gran parte irrilevante per il 30 per cento che determina se il prodotto risultante sia sicuro, corretto e duraturo.

La sicurezza e il conto da pagare più avanti

Quel 30 per cento non è altrettanto difficile da raggiungere in ogni ambito, ma la sicurezza è uno dei settori in cui le prove sono ormai specifiche e poco lusinghiere. Il 2025 GenAI Code Security Report di Veracode, che ha esaminato codice prodotto da oltre 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à inclusa 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à, il risultato è 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 compiti di programmazione rilevanti per la sicurezza.

I partecipanti che disponevano dell’assistente IA hanno scritto codice misurabilmente meno sicuro rispetto a un gruppo di controllo che lavorava senza l’assistente. 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 sommano in modo dannoso quando alla tastiera c’è chi sviluppa per la prima volta e non ha competenze di sicurezza, anziché un professionista che verifica il codice generato rispetto a specifiche che già comprende.

A chi spetta il codice dopo

L’aspetto di questo cambiamento che riceve meno attenzione è ciò che accade a un’applicazione dopo il rilascio. Un citizen developer che usa Lovable o Bolt per creare uno strumento interno, o un professionista che rilascia una funzionalità con l’aiuto di un agente di programmazione, si ritrova a gestire una base di codice che potrebbe non aver letto per intero, contenente schemi che non ha scelto e che usa dipendenze che non ha selezionato.

L’ingegneria del software tradizionale ha sviluppato decenni di pratiche — revisione del codice, convenzioni di stile, architettura documentata, norme sull’attribuzione delle responsabilità — proprio per rendere una base di codice comprensibile anche a persone diverse dal suo autore originario. Il software sviluppato con il vibe coding, quasi per definizione, salta questo passaggio in fase di creazione, sulla promessa che il modello possa rigenerare il codice o correggerlo nello stesso modo in cui lo ha generato inizialmente.

Questa promessa regge abbastanza bene per applicazioni piccole, usa e getta e destinate a un solo 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, patch 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 formula da tempo sull’adozione del low-code già anticipano questa tensione, prevedendo che nei prossimi anni una quota crescente di aziende userà piattaforme low-code aziendali per sviluppare applicazioni essenziali per le proprie attività. È proprio per questa categoria di applicazioni che il costo di una base di codice illeggibile, non sottoposta a revisione o insicura smette di essere ipotetico.

La versione onesta della tesi

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

Ciò che non si è ridotto, e a cui puntano indipendentemente la sperimentazione di METR, il rapporto di Veracode, lo studio di Stanford e lo stesso saggio di Osmani, è la distanza tra un prototipo funzionante e un software sicuro, manutenibile e affidabile su larga scala. 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 ulteriormente verso la lettura, la verifica e la messa in sicurezza di codice che un numero crescente di persone non esperte di ingegneria del software può ormai produrre autonomamente: una divisione del lavoro per la quale il settore non ha ancora sviluppato norme, strumenti o qualifiche professionali.