Dalle alternative open source ad Adobe e Microsoft fino alle applicazioni sviluppate in poche ore con l’intelligenza artificiale: il software sta entrando in una nuova fase. Ma mentre il codice diventa accessibile a tutti, chi garantisce qualità, sicurezza e responsabilità? E il Cyber Resilience Act sarà sufficiente a contenere i rischi?
La nuova frontiera del software: non serve più un grande team per iniziare
Per decenni, sviluppare un’applicazione complessa ha richiesto competenze specialistiche, tempo, risorse economiche e un’organizzazione strutturata. Realizzare un editor fotografico, un programma di videoscrittura o uno strumento CAD significava affrontare un percorso di sviluppo lungo, fatto di progettazione, programmazione, test, correzione dei difetti e manutenzione.
L’intelligenza artificiale sta cambiando profondamente questo scenario.
Oggi un singolo sviluppatore può utilizzare un assistente AI per generare codice, creare interfacce, implementare funzionalità e accelerare attività che in passato richiedevano molto più lavoro manuale. In alcuni casi, anche chi non possiede una formazione informatica tradizionale riesce a costruire applicazioni funzionanti semplicemente descrivendo ciò che desidera ottenere.
È il fenomeno conosciuto come vibe coding: un approccio allo sviluppo in cui il linguaggio naturale e gli strumenti generativi assumono un ruolo centrale nella produzione del software.
Il fenomeno non riguarda più soltanto piccoli siti web, prototipi o videogiochi indipendenti. Sta cominciando a interessare anche applicazioni che ambiscono a sostituire strumenti professionali consolidati.
Un esempio emblematico è ArtCraft, un progetto open source che propone una suite di applicazioni native scritte in Rust, con l’obiettivo di coprire ambiti che spaziano dal fotoritocco alla produttività personale, fino al disegno tecnico.
La questione, tuttavia, va ben oltre un singolo progetto. ArtCraft è il sintomo di una trasformazione più ampia: il costo della produzione del codice sta diminuendo, ma quello di verificarlo, proteggerlo e mantenerlo non necessariamente segue la stessa curva.
È proprio in questo divario che si concentra una delle sfide più importanti per il futuro del software.
ArtCraft: da Adobe a Office, fino al CAD
Il progetto ArtCraft è interessante perché mostra quanto si stia allargando il campo d’azione degli strumenti di sviluppo assistiti dall’AI.
Nel catalogo ufficiale sono elencate dodici applicazioni, tra cui:
- PhotoCraft, dedicato al fotoritocco;
- VectorCraft, per la grafica vettoriale;
- FilmCraft, per il montaggio video;
- LightCraft, per la gestione e lo sviluppo delle fotografie;
- EffectCraft, per gli effetti visivi;
- DesignCraft, per l’impaginazione;
- PdfCraft, per la gestione dei PDF;
- WordCraft, per la videoscrittura;
- GridCraft, per fogli di calcolo e analisi dei dati;
- DeckCraft, per le presentazioni;
- SoundCraft, per la produzione audio;
- CADCraft, per il disegno tecnico.
Il progetto dichiara la disponibilità per Windows, macOS e Linux, oltre a versioni WebAssembly nel browser per numerose applicazioni. La scelta di Rust punta a realizzare programmi nativi, senza basare l’intera esperienza su un contenitore web come Electron.
La documentazione di CADCraft, per esempio, descrive il supporto a formati come DXF e alla lettura di determinate versioni di DWG, oltre a strumenti per livelli, quote, blocchi e disegno tecnico.
Sono caratteristiche che rendono il progetto interessante, ma non devono essere interpretate come prova di equivalenza con AutoCAD o con le altre applicazioni professionali di riferimento.
Al 12 ottobre 2026, il catalogo ufficiale segnala infatti che diversi strumenti sono ancora in fase di sviluppo o in alpha iniziale. La disponibilità di una funzione, il supporto dichiarato a un formato e la maturità necessaria per lavorare in produzione sono tre cose differenti.
Un editor che apre un’immagine non è necessariamente in grado di gestire correttamente tutti i profili colore, i livelli, i metadati e i formati professionali. Un foglio di calcolo non è equivalente a Excel se non garantisce la compatibilità con formule complesse, macro e modelli aziendali. E un CAD non diventa un sostituto completo di AutoCAD soltanto perché legge alcuni file DWG o DXF.
Anche il sito ufficiale precisa che le applicazioni sono progettate per funzionare localmente sui file dell’utente e per essere controllabili attraverso strumenti di automazione.
Il significato del progetto, quindi, non è che i prodotti storici siano già stati superati. È che una piccola realtà può oggi tentare di costruire un’intera famiglia di applicazioni, su più sistemi operativi, con una velocità che sarebbe stata molto più difficile da raggiungere senza l’AI.
Per Adobe, Microsoft, Autodesk e gli altri produttori, questo potrebbe diventare un nuovo fattore competitivo. Per gli utenti, potrebbe tradursi in più scelta, meno dipendenza dagli abbonamenti e maggiore libertà tecnologica.
Ma la velocità con cui nasce un prodotto non è una misura della sua affidabilità.
Dal gaming alle applicazioni professionali: l’AI accelera lo sviluppo
Il fenomeno non nasce con ArtCraft.
Nel settore dei videogiochi, gli strumenti generativi vengono già utilizzati per accelerare la produzione di codice, la prototipazione, la creazione di contenuti e lo sviluppo di funzionalità. Il risultato è un abbassamento delle barriere d’ingresso: team ridotti e sviluppatori indipendenti possono tentare progetti che in passato avrebbero richiesto investimenti più consistenti.
Questa trasformazione si sta estendendo a gestionali, applicazioni web, strumenti aziendali, plugin, automazioni e software desktop.
Il punto di svolta è che l’AI non viene più utilizzata soltanto per suggerire una funzione a un programmatore. Può partecipare alla realizzazione di interi moduli, intervenire su più file, correggere errori e utilizzare strumenti esterni per verificare il proprio lavoro.
In altre parole, lo sviluppo tende a spostarsi dalla scrittura manuale del codice alla supervisione di un processo sempre più automatizzato.
Questo può produrre vantaggi enormi. Le imprese possono sperimentare più rapidamente, i professionisti possono automatizzare attività ripetitive e le piccole realtà possono accedere a strumenti che prima non avrebbero potuto permettersi.
Esiste però un problema strutturale: generare codice è sempre più semplice, mentre dimostrarne la correttezza richiede ancora metodo, competenze e tempo.
Un programma può funzionare in una dimostrazione e fallire in condizioni reali. Può gestire correttamente il caso più comune e comportarsi in modo imprevedibile quando riceve input anomali. Può offrire un’interfaccia convincente pur contenendo errori di autorizzazione, dipendenze vulnerabili o una gestione inadeguata dei dati.
È la differenza tra un prototipo e un prodotto software professionale.
Vibe coding: il problema non è l’AI, ma l’assenza di controllo
Il vibe coding non è necessariamente un approccio sbagliato. Utilizzare l’intelligenza artificiale per programmare può aumentare significativamente la produttività anche di sviluppatori esperti.
Il rischio nasce quando la facilità di ottenere un risultato viene confusa con la capacità di comprenderlo e governarlo.
Un’applicazione aziendale non è soltanto un insieme di schermate e funzioni. Deve gestire autenticazione, autorizzazioni, sessioni, errori, dati, backup, aggiornamenti, dipendenze e condizioni impreviste. Deve inoltre poter essere mantenuta nel tempo e corretta quando vengono scoperti problemi.
Un risultato particolarmente significativo arriva dalla ricerca accademica.
Lo studio “Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks”, pubblicato negli atti della conferenza ICML 2026, ha valutato dodici configurazioni di agenti di programmazione su un benchmark di 186 attività di sviluppo provenienti da progetti open source reali.
Gli autori hanno riscontrato risultati preoccupanti sul fronte della sicurezza: in una delle configurazioni esaminate, SWE-Agent con Claude 4 Sonnet, il 57% delle soluzioni era funzionalmente corretto, ma soltanto l’11,8% risultava sicuro secondo i criteri del benchmark.
Questi numeri non significano che il codice generato dall’AI sia sempre vulnerabile, né che la stessa percentuale si applichi a qualsiasi progetto. Dimostrano però che un codice capace di svolgere la funzione richiesta può comunque essere insicuro.
Il rischio aumenta quando chi utilizza l’AI non ha le competenze per individuare gli errori, non sottopone il risultato a test adeguati o mette online il prodotto senza un processo di verifica.
Il problema, dunque, non è consentire a tutti di programmare. È confondere la possibilità di produrre un’applicazione con la capacità di assumersi la responsabilità di ciò che quell’applicazione farà.
Quando il software diventa un rischio per gli utenti
Un’applicazione vulnerabile non è soltanto un prodotto mediocre. Può diventare un punto d’accesso per sottrarre dati, compromettere sistemi, interrompere servizi o esporre informazioni riservate.
Il problema è particolarmente rilevante quando il software gestisce dati finanziari, documenti aziendali, credenziali, informazioni personali o processi critici.
In un ecosistema in cui è possibile generare rapidamente migliaia di applicazioni, plugin e componenti, diventa difficile sapere quali siano stati progettati correttamente, quali siano mantenuti e quali siano stati abbandonati dopo la prima versione.
C’è inoltre un aspetto spesso sottovalutato: un’applicazione non è composta soltanto dal codice scritto dal suo autore. Dipende da librerie, framework, pacchetti, API, strumenti di compilazione e sistemi di distribuzione.
Anche un progetto sviluppato con attenzione può essere compromesso da una dipendenza vulnerabile o da un aggiornamento malevolo.
La sicurezza deve quindi essere considerata lungo l’intera catena di fornitura del software, dalla progettazione alla distribuzione.
Il caso Ledger: la sicurezza non finisce nel codice
Le notizie dell’ottobre 2026 sui dispositivi hardware wallet Ledger mostrano quanto sia importante questa prospettiva.
Secondo The Verge, dispositivi venduti attraverso un rivenditore sarebbero stati manomessi con componenti hardware non autorizzati, in grado di intercettare informazioni sensibili durante la configurazione. Le perdite riportate superano gli 86 milioni di dollari in criptovalute. La stessa ricostruzione riferisce che Ledger considera compromessa la filiera del rivenditore coinvolto, senza evidenze che i propri sistemi o i dispositivi acquistati direttamente dalla società siano stati compromessi.
È importante precisare che questo episodio non dimostra un coinvolgimento dell’AI. È però un esempio concreto di un principio generale: la fiducia in un prodotto può essere compromessa in un punto diverso da quello in cui è stato progettato.
Nel software generato con l’AI, il problema può presentarsi in forme differenti: una libreria contraffatta, un pacchetto malevolo, un installer alterato, un aggiornamento compromesso o un agente autorizzato a compiere operazioni eccessive.
Se aumentano la quantità di software prodotto e il numero di componenti utilizzati, devono crescere anche la capacità di verificare la provenienza, l’integrità e il comportamento del prodotto.
Non basta chiedersi se il programma funzioni. Occorre chiedersi chi lo ha costruito, con quali componenti, come viene aggiornato e chi interviene quando qualcosa va storto.
SaaS e software locale: il server-side è davvero più sicuro?
Una convinzione diffusa è che le applicazioni SaaS siano intrinsecamente più sicure perché il codice viene eseguito sui server del fornitore e non è distribuito direttamente agli utenti.
La questione merita una distinzione.
In un’applicazione desktop, parte della logica viene distribuita sul dispositivo dell’utente. Questo rende possibile analizzare i binari, osservare il comportamento del programma e, in determinate condizioni, ricostruire parte delle sue funzionalità. Il reverse engineering può quindi essere più accessibile.
In un SaaS, il codice che rimane esclusivamente sul server non viene normalmente consegnato al cliente. Questo può proteggere meglio la proprietà intellettuale e rendere più difficile replicare l’implementazione interna.
Ma l’opacità del codice non è una garanzia di sicurezza.
Un servizio cloud può presentare vulnerabilità nelle API, errori di autenticazione, configurazioni errate, problemi di isolamento tra clienti, credenziali compromesse o difetti nella gestione dei dati. Il fatto che l’utente non possa leggere il codice non significa che non possa sfruttarne le vulnerabilità.
Il software locale, dal canto suo, può essere progettato con architetture robuste, permessi limitati, aggiornamenti verificabili e controlli di sicurezza rigorosi.
Il modello SaaS può offrire vantaggi concreti nella gestione centralizzata delle patch e nel controllo dell’infrastruttura. Introduce però anche una maggiore dipendenza dal fornitore, dai suoi sistemi e dalla continuità del servizio.
La sicurezza dipende dal modello di minaccia, dall’architettura e dai processi di gestione, non soltanto dal luogo in cui viene eseguito il codice.
Per le applicazioni locali, la disponibilità del codice sorgente può inoltre favorire la revisione indipendente, ma soltanto se qualcuno dispone delle competenze e delle risorse necessarie per esaminarlo.
Il nodo giuridico: ricreare Photoshop o Office è legale?
La possibilità di sviluppare alternative a prodotti commerciali apre anche questioni di proprietà intellettuale.
La risposta non può essere ridotta a un semplice sì o no.
La Direttiva europea 2009/24/CE sulla tutela giuridica dei programmi per elaboratore protegge il software attraverso il diritto d’autore, ma distingue l’espressione del programma dalle idee e dai principi alla base dei suoi elementi.
Questo significa che ricreare in modo indipendente una funzionalità non equivale automaticamente a copiare il codice originale. La valutazione cambia, però, se vengono riprodotti codice protetto, risorse grafiche, documentazione o altri elementi tutelati.
La Corte di giustizia dell’Unione europea ha affrontato questi temi nella causa C-406/10, SAS Institute contro World Programming, distinguendo la funzionalità di un programma dalla sua espressione protetta.
Restano inoltre da considerare i marchi, le licenze dei componenti utilizzati e le modalità di presentazione commerciale del prodotto.
Nel caso ArtCraft, il fatto che un’applicazione si proponga come alternativa a Photoshop, Word o AutoCAD non dimostra, da solo, una violazione. Allo stesso modo, dichiarare che il codice è stato scritto da zero non basta a risolvere automaticamente ogni questione legale.
Servirebbero elementi specifici sul codice, sui materiali utilizzati, sulle licenze e sulle modalità di sviluppo per formulare una conclusione giuridica.
Il punto più interessante è che l’AI può rendere più economico sviluppare implementazioni indipendenti di software esistente. La possibilità tecnica di farlo, tuttavia, non elimina gli obblighi previsti dalla normativa.
Cyber Resilience Act: la risposta europea alla proliferazione del software?
È qui che il discorso si collega direttamente al Cyber Resilience Act, il regolamento europeo sulla resilienza informatica dei prodotti digitali.
Il CRA rappresenta uno dei tentativi più importanti dell’Unione europea di affrontare il problema della sicurezza dei prodotti digitali lungo il loro ciclo di vita.
Il regolamento (UE) 2024/2847 è entrato in vigore il 10 dicembre 2024. Gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi sono applicabili dall’11 settembre 2026, mentre la maggior parte dei requisiti si applicherà dall’11 dicembre 2027.
La Commissione europea specifica che, quando ricorrono le condizioni previste, i fabbricanti devono inviare una segnalazione iniziale entro 24 ore dalla conoscenza dell’evento e una notifica completa entro 72 ore, seguite dai rapporti conclusivi previsti dal regolamento.
Il principio è chiaro: la sicurezza non può essere trattata esclusivamente come una correzione successiva alla distribuzione del prodotto. Deve essere considerata nella progettazione, nello sviluppo, nella gestione delle vulnerabilità e nella manutenzione.
Per i prodotti interessati, il fabbricante deve anche determinare e comunicare un periodo di supporto durante il quale le vulnerabilità vengono gestite efficacemente. In linea generale, il periodo è di almeno cinque anni, salvo che la vita utile prevista del prodotto sia inferiore.
È un cambiamento significativo per un mercato abituato a distribuire software che, in alcuni casi, viene consegnato senza un piano credibile di manutenzione.
Il CRA non vieta il vibe coding
È fondamentale non attribuire al regolamento obiettivi che non ha.
Il Cyber Resilience Act non vieta l’utilizzo dell’intelligenza artificiale nello sviluppo e non introduce un patentino generale per chi scrive software.
Interviene invece sui prodotti che rientrano nel suo ambito e sugli operatori economici responsabili, imponendo requisiti di sicurezza e gestione delle vulnerabilità.
Il codice generato da un modello AI non beneficia di un’esenzione speciale: se fa parte di un prodotto soggetto al regolamento, il suo processo di generazione non elimina gli obblighi applicabili al prodotto.
Allo stesso tempo, non tutto il software è automaticamente soggetto al CRA. Il campo di applicazione dipende dalla definizione normativa di prodotto con elementi digitali, dalle modalità con cui viene messo a disposizione sul mercato e dalle eventuali esclusioni. La valutazione deve quindi essere fatta caso per caso, senza sostenere che ogni sito web, ogni script interno o ogni applicazione personalizzata debba necessariamente seguire lo stesso percorso di conformità.
Il collegamento con il vibe coding è comunque evidente: quando la produzione del software diventa più veloce, la capacità di documentare, verificare e mantenere il prodotto diventa ancora più importante.
Per questo il CRA potrebbe contribuire a modificare il mercato, rendendo più rilevanti le competenze di sicurezza e la qualità dei processi, anziché la sola velocità di sviluppo.
Per approfondire il quadro normativo, è possibile consultare il testo ufficiale del regolamento su EUR-Lex.
Come arginare il rischio senza frenare l’innovazione?
Non sarebbe realistico pensare di fermare l’AI nello sviluppo software. Né sarebbe auspicabile rinunciare ai vantaggi che può offrire.
La risposta dovrebbe essere un insieme di controlli tecnici, organizzativi e normativi che rendano più difficile distribuire prodotti vulnerabili senza penalizzare chi utilizza correttamente questi strumenti.
1. Test e revisione indipendente. Il codice generato dall’AI dovrebbe essere sottoposto a test automatici, analisi statica e dinamica, controlli sulle dipendenze e, quando il rischio lo giustifica, verifiche di sicurezza indipendenti.
2. Gestione della supply chain. È necessario sapere quali componenti vengono utilizzati, da dove provengono e come vengono aggiornati. Inventari delle dipendenze, firme digitali e procedure di rilascio verificabili possono ridurre il rischio di manomissioni.
3. Permessi limitati per gli agenti. Gli agenti AI che leggono file, eseguono comandi o modificano progetti dovrebbero disporre soltanto delle autorizzazioni necessarie. Le azioni potenzialmente distruttive o sensibili dovrebbero richiedere controlli adeguati.
4. Manutenzione reale. Un prodotto non dovrebbe essere considerato concluso al momento del rilascio. Servono procedure per ricevere segnalazioni, correggere vulnerabilità, distribuire aggiornamenti e comunicare la fine del supporto.
5. Trasparenza per chi acquista. Gli utenti dovrebbero poter valutare il livello di manutenzione, la politica di sicurezza, le modalità di aggiornamento e le responsabilità del fornitore.
Questi principi sono coerenti con l’approccio del CRA e con le indicazioni della ricerca sulla sicurezza del codice generato dagli agenti AI. L’obiettivo non è rallentare ogni progetto con procedure sproporzionate, ma commisurare i controlli al rischio del prodotto.
Un prototipo personale e un’applicazione che gestisce dati sanitari o transazioni finanziarie non dovrebbero essere sottoposti necessariamente allo stesso livello di verifica. Ma neppure un prodotto apparentemente semplice dovrebbe essere distribuito senza considerare i rischi che può introdurre.
Il futuro: il codice diventerà una commodity, la fiducia no
ArtCraft potrebbe non diventare il nuovo standard del settore. Alcune applicazioni potrebbero maturare, altre fermarsi, altre ancora essere superate da progetti concorrenti.
Il suo significato, tuttavia, non dipende dal successo commerciale della singola suite.
Se strumenti AI sempre più potenti consentiranno di realizzare applicazioni complesse con team ridotti, il mercato potrebbe assistere a una crescita esplosiva di software verticali, alternative open source, automazioni e prodotti costruiti per esigenze molto specifiche.
Questo potrebbe mettere sotto pressione i modelli di abbonamento tradizionali e ridurre la dipendenza da pochi grandi fornitori.
Ma potrebbe anche aumentare il numero di prodotti abbandonati, duplicati o privi di manutenzione. La disponibilità del codice sorgente non garantisce che qualcuno lo controlli, così come la possibilità di generare un’applicazione non garantisce che esista un’organizzazione in grado di sostenerla.
Il valore professionale potrebbe quindi spostarsi ulteriormente dalla semplice produzione del codice verso architettura, integrazione, verifica, sicurezza, gestione del rischio e manutenzione.
Il Cyber Resilience Act si inserisce in questo scenario come un tentativo di rendere la sicurezza parte integrante della responsabilità del prodotto. Non risolverà da solo tutti i problemi del vibe coding, ma introduce un principio destinato a pesare sempre di più nelle scelte di chi sviluppa e acquista software.
La sfida sarà evitare due estremi: da una parte, frenare l’innovazione con requisiti sproporzionati; dall’altra, accettare che la facilità di produrre software diventi una giustificazione per distribuire prodotti non verificati.
E domani cosa ci aspetta?
L’intelligenza artificiale potrebbe arrivare a costruire applicazioni sempre più complete, correggere autonomamente una parte dei propri errori e gestire interi processi di sviluppo. Potrebbe anche consentire a singole persone di realizzare prodotti che oggi richiedono organizzazioni strutturate.
Ma sarà davvero possibile affidare alla stessa AI anche la verifica indipendente della sicurezza del codice che ha generato?
E chi controllerà il controllore?
Una possibile direzione è l’integrazione sistematica di agenti di verifica, test automatici, analisi delle dipendenze, controlli di provenienza e audit indipendenti. Questi strumenti possono ridurre il rischio, ma non eliminano la necessità di definire responsabilità chiare e criteri di accettazione verificabili.
La questione non è impedire a chiunque di creare software. È fare in modo che chiunque possa sperimentare, mentre chi distribuisce un prodotto destinato ad altri sia in grado di dimostrarne la qualità e di rispondere dei problemi che emergono.
ArtCraft ci mostra quanto si stia abbassando la barriera della produzione. La ricerca sul vibe coding ci ricorda che funzionalità e sicurezza non coincidono. Il Cyber Resilience Act prova a trasformare questa consapevolezza in requisiti concreti per i prodotti che rientrano nel suo ambito.
La domanda, quindi, non è più soltanto chi sarà in grado di scrivere il prossimo programma.
Quando chiunque potrà creare software, chi sarà in grado di garantirne la sicurezza, la qualità e la sostenibilità nel tempo?
È probabilmente da questa risposta che dipenderà una parte importante del futuro del software.
