Il software senza segreti: AI, reverse engineering e la fine del vantaggio di chi scrive il codice

Tra settembre e ottobre 2026 sono comparsi cloni di Photoshop e Word scritti con l’AI, strumenti che collegano gli agenti di coding ai disassemblatori e porting quasi quotidiani di videogiochi decompilati. Un’analisi di che cosa dimostrano davvero questi casi, del perché stiano accadendo adesso e di come stiano spostando il valore del software, a cominciare dal SaaS.

Due settimane che hanno cambiato la conversazione

Tra la fine di settembre e la metà di ottobre 2026 sono successe, quasi in contemporanea, una serie di cose che i social hanno rapidamente fuso in un’unica storia. Uno sviluppatore di Atlanta ha pubblicato su GitHub repliche open source di Photoshop, Premiere, Illustrator e di gran parte della suite Adobe, scritte in Rust con l’aiuto di Claude, e pochi giorni dopo ha aggiunto un elaboratore di testi, un foglio di calcolo e un programma di presentazioni che ricalcano Word, Excel e PowerPoint. Nello stesso periodo REA, un progetto il cui nome per esteso è Reverse Engineer Anything, è passato secondo Decrypt da meno di diecimila a oltre centomila stelle su GitHub in sei giorni, con più di trentamila stelle raccolte in un solo giorno. Intanto la comunità del retrogaming sfornava a ritmo quasi quotidiano porting nativi per PC di giochi decompilati, un giocatore singolo coordinava diciassette agenti per ricostruire un Call of Duty del 2009 dal suo eseguibile, e sulla PlayStation 5 comparivano un jailbreak per i firmware recenti e strumenti che promettono di trasformare gli eseguibili della console in programmi nativi per Windows e Linux.

La sintesi che ha circolato su X e LinkedIn è stata più o meno questa. Nessun binario è più al sicuro, il software proprietario ha i giorni contati, Adobe è morta e con lei, per estensione, il mestiere del programmatore. Il fondatore del progetto che ha clonato la suite Adobe, intervistato da Ars Technica, ha riassunto la propria posizione con la formula “software is over”, che è diventata lo slogan della settimana.

In questo articolo provo a fare il lavoro opposto, cioè a separare le singole vicende, a capire che cosa ciascuna dimostri davvero e che cosa no, a spiegare perché tutto questo accada proprio adesso e a ragionare su che cosa significhi per l’industria del software, con un’attenzione particolare al modello SaaS, che è quello su cui oggi si regge la maggior parte del valore economico del settore. La mia tesi, anticipata, è che il fenomeno sia reale e destinato a durare, ma che stia spostando il valore del software in una direzione diversa da quella che i titoli suggeriscono, e che il SaaS ne esca al tempo stesso più protetto di quanto si dica e più esposto di quanto i suoi operatori vogliano ammettere.

Che cosa è successo davvero

ArtCraft e i cloni di Adobe e Microsoft

Il progetto si chiama ArtCraft ed è stato avviato da Brandon Thomas, ex CEO di Storyteller.ai e in passato ingegnere in Square. Il primo commit di PhotoCraft, la replica di Photoshop, risale al 30 settembre 2026, l’annuncio della suite Adobe completa è arrivato su Reddit il 3 ottobre e il 7 ottobre si sono aggiunti WordCraft, GridCraft e DeckCraft per testi, fogli di calcolo e presentazioni. Secondo la ricostruzione di innFactory, oggi la pagina del progetto elenca dodici applicazioni, tutte scritte in Rust, rilasciate con licenza MIT e Apache 2.0, eseguibili offline su macOS, Windows e Linux e anche nel browser tramite WebAssembly. Tutte sono dichiaratamente in fase alpha.

Alcuni numeri aiutano a capire la sostanza. PhotoCraft gestisce livelli, maschere, livelli di regolazione e stili di livello, renderizza su Metal, Vulkan, DirectX 12 e WebGPU senza passare da Electron, e apre e salva file PSD e PSB. Il progetto dichiara che 134 file PSD reali su 135 vengono riscritti identici byte per byte dopo un ciclo di apertura e salvataggio. WordCraft legge e scrive .docx basandosi sullo standard pubblico ECMA-376 e espone i suoi 389 comandi attraverso la ribbon, una riga di comando, un’interfaccia JSON e un server MCP, il che significa che un agente AI può pilotare direttamente l’elaboratore di testi.

La maturità reale è molto più bassa di quanto lasci intendere uno screenshot. Il 5 ottobre la roadmap di PhotoCraft stimava la prontezza per l’uso professionale tra il 25 e il 35 per cento, mentre il README di WordCraft parlava di circa il 60 per cento rispetto a un sostituto completo di Word. Fabio Akita, che ha analizzato il repository nel dettaglio, contava oltre 800 issue aperte a due settimane dalla creazione, con problemi di memoria sulle immagini oltre gli 8.192 pixel, una gestione del colore rudimentale e quasi cento segnalazioni aperte che riguardano proprio il formato PSD. Thomas stesso ha corretto la promessa iniziale di piena parità funzionale entro un mese, spostandola su un orizzonte di mesi. Adobe ha declinato ogni commento e Microsoft si è limitata a confermare di aver ricevuto la richiesta della stampa.

Il dettaglio più importante riguarda il metodo. Thomas ha scritto su Hacker News di aver usato Claude Code senza alcuno strumento di disassemblaggio, e i file AGENTS.md dei repository vietano esplicitamente all’agente di leggere, disassemblare o copiare qualsiasi parte dei pacchetti originali. Le fonti ammesse sono il comportamento osservabile del programma, i menu, le scorciatoie, gli screenshot e le specifiche pubbliche dei formati. In senso stretto, quindi, i cloni di Adobe e Microsoft sono il frutto di una ricostruzione comportamentale del programma osservato dall’esterno, senza alcuna analisi del codice, e Decrypt e Kingy.ai, nelle loro verifiche indipendenti, non hanno trovato traccia dell’uso di REA.

REA, la cassetta degli attrezzi

REA è un server MCP open source, nato ad aprile 2026 con il nome di betterBinaryMCP, che collega agenti di coding come Claude Code, Codex o Cursor agli strumenti classici del reverse engineering, cioè Ghidra, IDA, Hopper, JADX per Android, Frida per l’analisi dinamica dei processi e Chrome DevTools per le applicazioni web ed Electron. L’agente chiede, REA lancia lo strumento e restituisce pseudocodice, grafi delle chiamate, stringhe e tracce, ciascun risultato accompagnato da un registro delle evidenze e da un elenco di limiti noti.

Akita, che ne ha letto il codice, lo descrive come un progetto serio, con sei mesi di sviluppo, circa 2.600 commit e un migliaio di file di test, ma anche instabile e costoso da usare. Il catalogo degli strumenti MCP pesa 2,3 MB di JSON che finiscono nel contesto dell’agente, e un esperimento pubblicato dagli stessi autori mostra che l’analisi di SQLite compilato in WebAssembly ha richiesto 42 chiamate, cinque minuti e circa 300.000 token in ingresso. La documentazione del progetto è più prudente di chi lo ha reso virale, perché esclude esplicitamente l’aggiramento di DRM e protezioni commerciali e chiede di non presentarlo mai come uno strumento che clona automaticamente un programma o ne recupera il sorgente.

Un test di MindStudio citato da innFactory è particolarmente istruttivo. L’applicazione Anteprima del Mac è stata ricostruita due volte, una con REA e una senza, partendo solo da screenshot e dal ragionamento dell’agente, ed entrambe le versioni funzionavano, con quella senza REA addirittura completata per prima. Guardare dentro il binario, almeno per applicazioni di questo tipo, aiuta meno di quanto si pensi.

Il retrogaming e la decompilazione per corrispondenza

La parte più solida dell’intera vicenda riguarda i videogiochi del passato. Come ricostruisce TechSpot, nelle ultime settimane hanno raggiunto traguardi importanti i progetti di decompilazione di GoldenEye 007, completata al 100 per cento ad agosto dopo mezzo decennio di lavoro, di Super Smash Bros. Melee, arrivata al 100 per cento dopo più di sei anni con un modello di OpenAI ad aiutare nell’ultimo tratto, e di Halo: Combat Evolved, la cui decompilazione comunitaria dichiara il 99,5 per cento di corrispondenza byte per byte e alimenta porting nativi per Windows, Linux e Android.

Il caso più citato è quello di Call of Duty: Modern Warfare 2 nella versione PC del 2009. Lo sviluppatore Maurice Heumann ha raccontato che ad agosto quattro agenti Claude Code avevano ricostruito circa un terzo delle funzioni consumando quasi 200 miliardi di token, e che a fine settembre diciassette agenti in parallelo avevano reso il gioco interamente giocabile, per un consumo complessivo che nel suo resoconto del 9 ottobre stima tra i 600 e i 700 miliardi di token in tre mesi. Activision ha fatto rimuovere i video e il sito che ospitava il codice è stato oscurato pochi giorni dopo. La lezione tecnica più interessante del resoconto è che inizialmente gli agenti producevano codice leggibile e convincente ma spesso sbagliato, che inventava logica e alterava il comportamento del gioco, e che i progressi sono arrivati solo quando il team ha introdotto controlli automatici che confrontavano il codice ricostruito con l’eseguibile originale.

La PlayStation 5, dove la narrazione si è staccata dai fatti

Sulla PS5 i fatti sono due e vanno tenuti distinti. Il primo è Relapse, un jailbreak pubblicato a fine settembre che, secondo le descrizioni tecniche, combina una vulnerabilità di WebKit con un exploit del kernel e funziona sulle console con firmware dalla 7.00 alla 13.60, comprese PS5 Slim e PS5 Pro. È temporaneo, scompare al riavvio, può bloccare la console e non consente di avviare Linux, e Sony lo ha già neutralizzato con i firmware 14.00 di metà settembre e 14.10 del primo ottobre. Il secondo è AnyPS5, uno strumento che riconfeziona gli eseguibili della console come programmi nativi per Windows e Linux e che ha raggiunto il riconoscimento di tutte le 1.166 istruzioni shader censite, mentre emulatori come KytyPS5 e SharpEmu riescono già ad avviare Astro Bot con un gameplay reale.

Il messaggio virale secondo cui l’AI avrebbe forzato la sicurezza della PS5 in poche settimane, rendendo accessibile l’intera libreria, non trova riscontro nelle fonti tecniche. Nessuna di quelle che ho consultato attribuisce Relapse all’uso di modelli linguistici, e Akita osserva che la versione 0.1 di AnyPS5, secondo chi l’ha provata, faceva girare un solo gioco indipendente in 2D, mentre l’affermazione che la PS5 sia ormai portata all’80 per cento su PC viene dai fan e nessun gioco 3D funziona ancora con questo metodo. In questo caso l’AI è entrata nella storia soprattutto come cornice narrativa.

Tre pratiche diverse che vengono confuse

Gran parte della confusione di queste settimane nasce dal fatto che sotto l’etichetta di reverse engineering con l’AI finiscono tre attività tecnicamente e giuridicamente molto diverse, che conviene descrivere una per una.

La prima è la ricostruzione comportamentale, o clean room nel senso classico del termine. Si osserva un programma dall’esterno, se ne studiano l’interfaccia, i comandi, i formati di file pubblicamente documentati e il comportamento in risposta agli input, e si scrive da zero un’implementazione indipendente che produca risultati equivalenti. È quello che ha fatto Phoenix Technologies nel 1984 con il BIOS del PC IBM, separando un gruppo che analizzava l’originale e scriveva specifiche da uno sviluppatore scelto proprio perché non aveva mai visto il codice IBM. È anche, per sua stessa dichiarazione, il metodo di ArtCraft, con la differenza che il ruolo dello sviluppatore incontaminato è affidato a un modello linguistico a cui un file di testo dice che cosa non deve guardare.

La seconda è la decompilazione assistita. Qui si parte dal binario, lo si disassembla in istruzioni macchina, lo si decompila in uno pseudocodice simile al C e poi si fa il lavoro che storicamente ha richiesto più tempo, cioè ricostruire i nomi delle variabili e delle funzioni, i tipi, le strutture dati e l’intenzione del programmatore, tutte informazioni che la compilazione cancella. Nella sua forma più rigorosa, la decompilazione per corrispondenza, l’obiettivo è scrivere codice C che, compilato con lo stesso compilatore e le stesse opzioni dell’epoca, produca un binario identico byte per byte all’originale. È il terreno di REA e di gran parte dei progetti sui giochi per Nintendo 64, GameCube e prima Xbox.

La terza è la ricompilazione statica e il porting attraverso livelli di traduzione. In questo caso si rinuncia a capire il programma e si traducono meccanicamente le istruzioni del processore originale in codice generico e si sostituiscono solo le parti che parlano con l’hardware, cioè grafica, audio, input e salvataggi. Strumenti come N64Recomp o XenonRecomp fanno questo per architetture diverse da quella del PC, mentre per le console moderne, che usano processori x86 o ARM come i computer comuni, il lavoro si riduce a reimplementare le librerie di sistema e a tradurre gli shader della GPU. È la strada di AnyPS5, di shadPS4 per la PS4 e di Azimuth, che fa girare su Windows la versione Xbox One di Forza Horizon 2.

Distinguere queste tre pratiche serve a capire due cose. La prima è che i rispettivi limiti tecnici sono molto diversi, perché la ricostruzione comportamentale produce codice nuovo e manutenibile ma approssima l’originale, la decompilazione per corrispondenza garantisce fedeltà ma solo dove esiste un binario da confrontare, e la ricompilazione funziona bene solo quando l’architettura di partenza è vicina a quella di arrivo. La seconda è che anche lo status giuridico cambia radicalmente da una pratica all’altra, come vedremo più avanti.

Perché accade adesso

Se il reverse engineering esiste da quarant’anni, è legittimo chiedersi perché l’accelerazione sia avvenuta proprio nell’autunno del 2026. La risposta più convincente che ho trovato è che si siano sovrapposti tre fattori, nessuno dei quali sarebbe bastato da solo.

Il primo è un lavoro umano già fatto. Molti dei progetti finiti in prima pagina poggiano su decompilazioni che gruppi di volontari portavano avanti da cinque o sei anni, con una mappatura dell’hardware delle vecchie console che la comunità ha costruito istruzione per istruzione nel corso di un quarto di secolo. L’AI è intervenuta soprattutto nell’ultimo tratto, quello in cui storicamente questi progetti si arenavano per anni perché le ultime funzioni erano le più noiose e le più difficili da far corrispondere. Akita sottolinea che la fase attuale delle decompilazioni e ricompilazioni su larga scala è cominciata nel 2019, ben prima che esistessero agenti di coding, con il rilascio di Ghidra da parte della NSA e la pubblicazione della decompilazione di Super Mario 64.

Il secondo fattore è la maturazione degli strumenti. Disassemblatori come Ghidra e IDA, strumenti di confronto come objdiff e ricompilatori statici come N64Recomp hanno trasformato in framework riutilizzabili quelle che un tempo erano soluzioni artigianali, e un protocollo come MCP ha reso banale collegarli a un agente. REA, da questo punto di vista, è essenzialmente un adattatore, e il suo successo dice più sulla domanda latente che sulla novità della tecnologia.

Il terzo fattore, il più importante dal punto di vista concettuale, è che molti di questi compiti hanno una chiave delle risposte. Nella decompilazione per corrispondenza esiste un controllo inequivocabile, perché il codice prodotto o compila in un binario identico all’originale oppure no, e un agente può ripetere questo controllo migliaia di volte senza che un essere umano debba valutare ogni tentativo. Uno sviluppatore che lavorava sul gioco per Nintendo 64 Snowboard Kids 2 ha messo Claude in un ciclo in cui uno script sceglieva la funzione più facile tra quelle rimaste, l’agente provava a farla corrispondere, registrava il risultato in caso di successo e passava oltre dopo dieci tentativi falliti, e in tre settimane ha ottenuto più progressi che nei tre mesi precedenti, con l’agente al lavoro senza supervisione per oltre otto ore di fila. La sua conclusione, riportata da TechSpot, è che il collo di bottiglia si era spostato dal tempo libero di pochi esperti alla potenza di calcolo.

Lo stesso meccanismo spiega i cloni di ArtCraft nelle parti in cui funzionano. Il supporto PSD di PhotoCraft è testato contro un corpus di file reali che devono sopravvivere a un ciclo di lettura e scrittura senza alterazioni, e il progetto confronta separatamente i propri rendering con quelli di Photoshop. Dove esiste un oracolo l’agente converge, e lo stesso principio vale fuori dal mondo dei giochi, per esempio nella modernizzazione del COBOL. Cognition, l’azienda che sviluppa l’agente Devin, ha spiegato che gli agenti girano su macchine virtuali Linux che non possono eseguire il COBOL dei mainframe, e che questo spezza il ciclo di scrittura, esecuzione e verifica. Fanno eccezione i job batch, che producono output prevedibili e permettono all’agente di riscrivere la logica in un linguaggio moderno iterando finché i risultati coincidono con quelli del sistema originale.

C’è poi un dato economico che lega tutto. Il costo di inferenza a parità di qualità, secondo le misure di Epoch AI citate da Akita, scende all’incirca di cinque-dieci volte l’anno, mentre il prezzo dei modelli di frontiera è calato molto meno. Questo rende sostenibile far girare decine di agenti per settimane su un problema che ha una verifica automatica, ma non rende gratuito il problema stesso. La riscrittura di Bun da Zig a Rust, l’esempio pubblico meglio documentato di riscrittura su larga scala con agenti, ha richiesto undici giorni, fino a 64 istanze di Claude in parallelo, circa 165.000 dollari a prezzi di listino, l’autore originale del progetto alla guida e una suite di test con oltre un milione di asserzioni a fare da oracolo.

I limiti reali

Il rovescio della chiave delle risposte è che, dove manca un arbitro automatico, gli agenti tendono a bluffare. È il filo che lega tutti i limiti emersi in queste settimane, ed è il punto che i titoli trascurano più spesso.

Il primo limite è la coda lunga delle funzionalità. Un’interfaccia che somiglia a Photoshop si ottiene in pochi giorni, ma un software professionale con trentasei anni di storia contiene migliaia di comportamenti che nessuna specifica pubblica descrive e che nessun utente nota finché non mancano. Il pixel artist Dan Fessler, dopo aver provato PhotoCraft, lo ha definito del tutto inutilizzabile, e la sua osservazione più acuta, riportata da TechSpot, è che il vero collo di bottiglia del software è sempre stato la cura e la riflessione dietro ogni scelta, molto più della scrittura del codice. Quell’unico file PSD su 135 che PhotoCraft non riesce a riscrivere identico rappresenta bene la categoria dei casi limite che separano un prototipo da uno strumento su cui si può costruire un’attività professionale.

Il secondo limite riguarda la conoscenza che non sta nel codice. Akita, che ha usato Photoshop e Premiere per anni, porta l’esempio della gestione del colore. GIMP esiste dal 1995, ha ottenuto il supporto all’importazione ed esportazione di file CMYK solo nel 2022 e nella versione 3.0 del 2025 non ha ancora una modalità di editing CMYK, perché lavorare correttamente in quadricromia richiede profili ICC specifici per ogni stampante, limiti di inchiostro e regole di generazione del nero la cui competenza risiede nelle tipografie e nei laboratori del colore, e quasi per nulla nei corpus di addestramento dei modelli. Lo stesso vale per i profili di correzione degli obiettivi e delle fotocamere che Adobe aggiorna da vent’anni, per le librerie Pantone, che sono proprietarie e che nessun progetto aperto può distribuire, e per i formati raw delle cineprese professionali, la cui decodifica corretta dipende da SDK forniti dai produttori sotto contratto. Un agente può riprodurre ciò che ha visto in addestramento o ciò che può verificare, e questa conoscenza non rientra in nessuna delle due categorie.

Il terzo limite è che il bersaglio si muove. Decompilare un gioco del 1998 significa mirare a qualcosa che nessuno aggiornerà mai più, mentre clonare un prodotto vivo significa inseguire un formato e un insieme di funzionalità che cambiano a ogni versione. La storia di OpenOffice e LibreOffice lo dimostra, perché per oltre un decennio hanno inseguito il formato .doc di Microsoft, la cui specifica è diventata pubblica solo nel 2008, dopo due sanzioni della Commissione Europea per un totale di quasi 1,4 miliardi di euro legate proprio al rifiuto di fornire informazioni sull’interoperabilità. Quando il formato si è finalmente aperto, il valore si era già spostato altrove.

Il quarto limite riguarda la qualità del codice prodotto. Anche quando la decompilazione assistita raggiunge la corrispondenza perfetta, il risultato è spesso poco leggibile, e un codice identico all’originale che nessuno riesce a capire serve a poco se l’obiettivo è mantenerlo o modificarlo. Gli studi accademici confermano il quadro. Un lavoro di settembre 2026 citato da Akita ha misurato che la rifinitura con modelli linguistici dell’output di Ghidra porta il tasso di compilazione dal 75 al 90 per cento ma fa scendere la fedeltà comportamentale dal 74 al 62 per cento, e che in circa il 10 per cento delle funzioni con vulnerabilità note il difetto scompare senza che nessuno lo abbia chiesto, il che significa che il codice ricostruito non si comporta più come l’originale. Lo sviluppatore del progetto di decompilazione di Klonoa per Game Boy Advance ha documentato anche un comportamento più inquietante, perché l’agente, quando era bloccato, ha provato a barare arrivando a modificare il compilatore stesso per forzare la corrispondenza. Il rischio principale, secondo lui, è un debito cognitivo, cioè codice che funziona e che nessuno nel team comprende davvero.

C’è infine una reazione delle comunità stesse. Il gruppo che ha costruito a mano il porting di Donkey Kong 64 ha scoperto che una versione rivale generata con l’AI aveva modificato silenziosamente RT64, il renderer condiviso da cui dipendono molti porting per Nintendo 64, la principale comunità di ricompilazione per quella console ha smesso di promuovere i progetti scritti in gran parte da agenti, e progetti di emulazione storici come mGBA e QEMU rifiutano esplicitamente il codice generato. Gli sviluppatori dei porting di Zelda e Banjo hanno coniato il termine slopcomp per indicare le ricompilazioni prodotte in serie da agenti con qualità da versione alpha.

Il nodo giuridico

La domanda che molti si sono posti è se tutto questo sia legale, e la risposta onesta è che dipende quasi interamente da quale delle tre pratiche descritte sopra si stia adottando. Quello che segue è un inquadramento generale e non sostituisce una consulenza legale sul caso specifico.

Il punto di partenza nell’Unione Europea è la sentenza della Corte di Giustizia nella causa C-406/10, SAS Institute contro World Programming, del 2 maggio 2012. La Corte ha stabilito che la funzionalità di un programma per elaboratore, il linguaggio di programmazione e il formato dei file di dati non costituiscono forme di espressione protette dal diritto d’autore, mentre lo è il codice specifico. È significativo che World Programming, nel caso esaminato, non avesse avuto accesso al sorgente e non avesse decompilato nulla. La ricostruzione comportamentale, quindi, poggia su un terreno relativamente solido, purché non si copino elementi protetti per altre vie, come marchi, design, icone, testi dell’interfaccia o asset grafici, e purché non entrino in gioco brevetti o comportamenti di concorrenza sleale.

La decompilazione è un’altra faccenda. La direttiva 2009/24/CE sulla tutela giuridica dei programmi per elaboratore, recepita in Italia negli articoli 64-ter e 64-quater della legge sul diritto d’autore, distingue due livelli. Chi ha legittimamente diritto a usare un programma può osservarne, studiarne e sottoporne a prova il funzionamento per determinare le idee e i principi su cui si basa, e questo copre buona parte dell’osservazione esterna su cui si fonda un approccio come quello di ArtCraft. La decompilazione vera e propria, invece, è consentita senza autorizzazione del titolare solo quando è indispensabile per ottenere le informazioni necessarie all’interoperabilità con un programma creato autonomamente, e le informazioni così ottenute non possono essere usate per sviluppare, produrre o commercializzare un programma sostanzialmente simile nella sua forma espressiva. Decompilare Photoshop per scriverne un clone ricade con ogni probabilità fuori da questa eccezione. La direttiva prevede inoltre che le clausole contrattuali contrarie a queste eccezioni siano nulle, mentre al di fuori di esse i divieti di reverse engineering contenuti nelle licenze d’uso restano un vincolo contrattuale per chi le ha accettate.

Si aggiunge la direttiva 2016/943 sui segreti commerciali, recepita in Italia con il decreto legislativo 63 del 2018, che considera lecita l’acquisizione di informazioni attraverso l’osservazione, lo studio, lo smontaggio o la prova di un prodotto messo a disposizione del pubblico, salvo vincoli contrattuali validi. Negli Stati Uniti il percorso è diverso ma approda a conclusioni simili, con le sentenze Sega contro Accolade del 1992 e Sony contro Connectix del 2000, che hanno riconosciuto il disassemblaggio finalizzato a raggiungere elementi funzionali come fair use, e con Google contro Oracle del 2021, che ha qualificato come fair use la copia delle dichiarazioni delle API Java.

Il terreno che resta davvero inesplorato è quello del clean room affidato a un modello. Il principio classico si regge sulla separazione fisica tra chi ha visto l’originale e chi scrive la nuova implementazione, e la sua forza probatoria deriva dal fatto che lo sviluppatore non possa aver copiato ciò che non ha mai visto. Un modello linguistico, al contrario, è stato addestrato su enormi quantità di codice pubblico, e non è affatto chiaro come si possa dimostrare che non abbia assorbito anche frammenti dell’opera che sta ricostruendo, soprattutto per software molto diffuso. Il primo caso concreto è arrivato a marzo 2026 con chardet, una diffusa libreria Python per il riconoscimento delle codifiche di caratteri. Il suo manutentore storico l’ha riscritta da zero con Claude Code e ne ha cambiato la licenza da LGPL a MIT, e l’autore originale si è opposto sostenendo che chi ha lavorato per oltre dieci anni su un codice non può rivendicare una tabula rasa, anche se un controllo antiplagio ha rilevato solo l’1,29 per cento di somiglianza tra le due versioni. Il dibattito, che qualcuno ha battezzato riciclaggio di licenze, non è ancora arrivato in tribunale.

Il quadro che ne risulta è quello di un diritto che regge bene sui principi e molto meno sugli strumenti di prova. Chi osserva un programma dall’esterno e ne riscrive il comportamento si muove su basi giuridiche consolidate, chi decompila per clonare si espone a rischi seri, e chi usa un modello addestrato su codice di terzi per fare clean room si trova in una zona che sarà definita dalle prime cause promosse da soggetti con risorse sufficienti a sostenerle. Le prime avvisaglie si vedono già nel mondo dei giochi, con la rimozione del progetto su Modern Warfare 2 da parte di Activision e la diffida di Bethesda contro una ricostruzione per browser di un Fallout generata con l’AI.

Che cosa significa per il software

Per quarant’anni l’economia del software si è retta su un’asimmetria precisa, perché scrivere un programma era costoso mentre copiarlo costava quasi nulla, e tutta l’architettura di protezione del settore, dalle licenze alla compilazione in binario fino all’offuscamento, serviva a impedire la copia di qualcosa che era difficile rifare. Quello che le ultime settimane mostrano con chiarezza è che anche il costo di rifare sta crollando, almeno per una categoria specifica di lavoro, cioè la produzione di un’implementazione a partire da una specifica nota o da un comportamento osservabile e verificabile.

La distinzione è fondamentale. Il costo che sta scendendo è quello di trasformare una specifica in codice funzionante, mentre il costo di scoprire quale sia la specifica giusta, cioè che cosa il software debba fare, per chi, con quali compromessi e con quali eccezioni, scende molto più lentamente. Un prodotto maturo è in gran parte una specifica implicita accumulata in anni di contatto con gli utenti, e la parte di quella specifica che è osservabile dall’esterno, l’interfaccia, i comandi, i formati, le risposte agli input, diventa replicabile. La parte che resta nascosta, perché vive nei dati, nei server, nei contratti o nella testa di chi conosce il dominio, mantiene il suo valore e probabilmente lo aumenta.

Ne derivano alcune conseguenze che mi sembrano ormai difficili da contestare. La prima è che le funzionalità, prese in sé, smettono di essere un vantaggio competitivo difendibile. Se un agente può ricostruire in poche settimane l’interfaccia, i comandi e il formato dei file di un’applicazione, il solo elenco delle funzioni non protegge più nessuno, e quello che resta come fossato sono i dati accumulati, l’integrazione profonda nei processi del cliente, l’assistenza, le certificazioni, la responsabilità contrattuale e la fiducia.

La seconda conseguenza è che l’oracolo diventa l’asset più prezioso. Dato che gli agenti convergono dove esiste una verifica automatica, chi possiede una buona suite di test, un corpus di casi reali o un insieme di output di riferimento possiede anche la capacità di riscrivere, migrare e far evolvere il proprio software a costi molto più bassi di chi non li ha. Simmetricamente, ogni suite di conformità pubblica, ogni specifica di formato aperta e ogni documentazione dettagliata delle API diventa materiale di lavoro anche per chi vuole costruire un’alternativa. È una tensione nuova per chi ha sempre considerato la documentazione pubblica come un puro strumento di adozione.

La terza conseguenza riguarda il codice privato. Secondo il rapporto Octoverse 2025 di GitHub, citato da Akita, l’81,5 per cento dei contributi sulla piattaforma avviene in repository privati, cioè in codice che nessun modello ha mai visto in addestramento. Il software che paga gli stipendi, quello che codifica processi aziendali specifici, regole di dominio e integrazioni con sistemi interni, resta in larga parte fuori dalla portata della riproduzione, a meno che qualcuno non ne possieda il binario e decida di decompilarlo, con tutti i rischi giuridici visti sopra.

La quarta conseguenza riguarda il modo in cui il software viene usato. WordCraft espone i propri comandi attraverso un server MCP, e questa scelta dice molto sulla direzione presa dal settore. Se una parte crescente dell’uso del software passa da agenti che operano attraverso interfacce programmatiche, l’interfaccia grafica, su cui molti prodotti hanno costruito la propria identità e una parte della propria fidelizzazione, perde peso, e con essa perde peso un elemento di lock-in che finora era sembrato solido. I costi di passaggio da un prodotto all’altro, che nella pratica dipendevano spesso dall’abitudine degli utenti a un’interfaccia, si abbassano quando l’utente principale diventa un agente che non ha abitudini.

Infine, c’è un effetto sui prezzi che arriverà molto prima di qualsiasi sostituzione reale. Un’alternativa open source credibile, anche se ancora in alpha, cambia la posizione negoziale del cliente al prossimo rinnovo della licenza, e il software desktop venduto in abbonamento a prezzi crescenti, il caso di Adobe che ha innescato il progetto di Thomas è emblematico, è il primo candidato a subire questa pressione.

Il SaaS in particolare

Perché il SaaS sembra al riparo

La prima reazione di molti osservatori, condivisibile, è stata notare che il SaaS è strutturalmente protetto da tutto questo. Akita lo dice in modo netto, osservando che dopo la migrazione del mondo verso il SaaS la maggior parte del software proprietario è diventata un giardino recintato senza binario, e che senza binario non c’è niente da disassemblare. Per fare reverse engineering di Google Docs bisognerebbe riscriverlo da zero guardando solo l’interfaccia, perché il codice che conta non lascia mai il server. Lo stesso vale per Adobe, che ha spostato sui propri server proprio le funzioni che oggi vendono gli abbonamenti, come Generative Fill, Generative Expand e diversi Neural Filters, che secondo la documentazione dell’azienda richiedono una connessione perché l’elaborazione avviene nel cloud.

A questa protezione tecnica se ne aggiungono altre, meno visibili ma più robuste. Un servizio SaaS maturo non coincide con il suo codice applicativo, perché comprende l’infrastruttura che lo tiene in piedi con determinati livelli di disponibilità, la sicurezza operativa, le certificazioni come ISO 27001 o SOC 2, la conformità al GDPR e, per chi serve settori regolati, a normative come NIS2 o DORA, i contratti con i fornitori di dati e modelli, l’ecosistema di integrazioni costruito con altri prodotti e, soprattutto, i dati dei clienti accumulati nel tempo, che spesso alimentano funzionalità che nessun concorrente può replicare senza avere quegli stessi dati. Tutto questo resta fuori dalla portata di un agente che osserva un’interfaccia, per quanto bravo sia.

Perché questa protezione è più fragile di quanto sembri

Il ragionamento che rassicura il SaaS ha però una falla, che emerge proprio dal caso ArtCraft. I cloni di Adobe e Microsoft sono nati senza toccare alcun binario, attraverso la sola osservazione del comportamento, e il test di MindStudio su Anteprima ha mostrato che per applicazioni di complessità media il binario aggiunge poco. La protezione del SaaS contro la decompilazione è reale, ma la decompilazione si sta rivelando la strada meno importante. Contro la ricostruzione comportamentale il SaaS è esposto quanto il software desktop, e per certi versi di più, perché pubblica spontaneamente una documentazione dettagliata delle proprie API, espone i propri flussi in un browser dove ogni chiamata di rete è ispezionabile con strumenti che REA integra nativamente, e spesso descrive con precisione nei propri materiali di vendita che cosa fa e come.

La domanda corretta, allora, riguarda la quota del valore di ciascun prodotto che è osservabile dall’esterno. Per una grande piattaforma come Salesforce o Workspace la quota è piccola, perché il valore sta nei dati, nelle integrazioni, nella scala e negli effetti di rete. Per una larga fascia di SaaS di medie dimensioni, invece, la quota è molto alta. Penso ai prodotti che sono essenzialmente un’interfaccia ben fatta sopra un database, con qualche flusso di lavoro, qualche report e un sistema di permessi, venduti a canone per utente. È la categoria che il mercato chiama a volte SaaS di funzionalità, e il suo vantaggio competitivo è stato finora proprio il costo e il tempo necessari a costruire un’alternativa. Quel costo è ciò che si sta comprimendo.

Dove la pressione arriverà prima

Non credo che la minaccia principale per questi prodotti venga da cloni open source pubblicati su GitHub da sviluppatori indipendenti. Un clone in alpha di un gestionale verticale non ha né la community né la visibilità di PhotoCraft. La pressione arriverà piuttosto da tre direzioni meno spettacolari.

La prima è il calcolo make or buy dei clienti. Molte aziende hanno comprato abbonamenti SaaS per strumenti interni, gestione di richieste, portali per i fornitori, piccoli CRM di nicchia, perché costruirli in casa costava troppo rispetto al canone. Con agenti di coding capaci e una specifica chiara, che in questo caso è il prodotto stesso che l’azienda usa da anni, quel calcolo cambia, e cambia soprattutto per strumenti a bassa complessità di dominio e ad alto numero di utenti, dove il canone per postazione pesa di più. È lo stesso scenario che innFactory indica come il più probabile, molto più della costruzione del prossimo Photoshop.

La seconda direzione è la concorrenza tra fornitori. Un nuovo entrante può oggi presentarsi con una copertura funzionale paragonabile a quella del leader di mercato in tempi molto più brevi di prima, e competere sul prezzo, sull’esperienza d’uso o sull’integrazione con agenti. La differenziazione per funzionalità si erode e le guerre di prezzo diventano più frequenti nei segmenti in cui i prodotti erano già simili.

La terza direzione riguarda i costi di uscita. Una parte importante del lock-in del SaaS deriva dalla difficoltà di migrare dati, configurazioni, automazioni e personalizzazioni accumulate in anni di uso. Gli stessi agenti che ricostruiscono un’applicazione dal suo comportamento sono molto efficaci nel mappare un modello dati sull’altro, nel tradurre regole di automazione e nel verificare che i risultati coincidano, perché anche qui esiste un oracolo naturale, cioè il confronto tra gli output del vecchio e del nuovo sistema. Quando migrare costa meno, il potere negoziale del cliente cresce.

Che cosa resta difendibile

Se dovessi indicare dove si sposterà il valore nel SaaS dei prossimi anni, metterei in cima alla lista tutto ciò che un agente non può osservare né verificare. I dati proprietari e gli effetti di rete, prima di tutto, perché un clone può replicare la funzione di un marketplace ma non i suoi partecipanti. Poi la conoscenza di dominio che non sta in nessun corpus, come quella sul colore che protegge Photoshop meglio di qualsiasi offuscamento, e che in molti settori verticali, dalla logistica alla farmaceutica, è il vero contenuto del prodotto. Poi le licenze e gli accordi con terze parti, dalle librerie Pantone agli SDK dei produttori, fino ai contratti con fornitori di dati che nessun progetto può replicare. Poi la responsabilità, cioè la disponibilità a firmare un contratto con livelli di servizio, a rispondere di un incidente di sicurezza e a sostenere un audit, che un repository su GitHub non offre. E infine la velocità di evoluzione, perché il bersaglio mobile, che ha condannato per un decennio OpenOffice a inseguire Microsoft, protegge chi continua a muoversi.

C’è anche una conseguenza sui modelli di prezzo. Il canone per postazione si regge sull’idea che ogni utente umano tragga dal prodotto un valore proporzionale al suo costo. Se una parte crescente dell’uso passa da agenti e se l’alternativa costruita in casa diventa plausibile, è probabile che i fornitori debbano spostarsi verso prezzi legati al risultato o al volume di lavoro svolto, e che i clienti accettino di pagare soprattutto per ciò che non sono in grado di riprodurre.

Implicazioni per chi costruisce e per chi compra software

Per chi produce software

L’esercizio più utile che un’azienda software può fare oggi è chiedersi, per ciascun prodotto, che cosa un concorrente dotato di agenti di coding non riuscirebbe a ricostruire in tre mesi partendo da ciò che è osservabile dall’esterno. Se la risposta si riduce a un elenco di funzionalità, la strategia va ripensata, e conviene investire deliberatamente in ciò che non è osservabile, cioè dati, integrazioni profonde nei processi dei clienti, conoscenza di dominio formalizzata, relazioni contrattuali e capacità operativa.

In secondo luogo conviene trattare le proprie suite di test, i corpus di casi reali e gli output di riferimento come asset strategici di primo livello. Sono ciò che permette di usare gli agenti sul proprio codice con risultati affidabili, per riscriverlo, migrarlo o estenderlo, e sono anche ciò che renderebbe più facile a un terzo costruire un’alternativa se diventassero pubblici. La documentazione pubblica resta indispensabile per l’adozione, ma va scritta sapendo che sarà letta anche da agenti che lavorano per altri.

In terzo luogo, chi ha team che lavorano con agenti di coding dovrebbe definire per iscritto che cosa quegli agenti possono e non possono guardare. Un file AGENTS.md con divieti espliciti, come quello di ArtCraft, è un punto di partenza semplice e documentabile, e la decompilazione di software di terzi non dovrebbe entrare negli strumenti di lavoro senza una valutazione legale preventiva. Allo stesso modo conviene inserire nelle condizioni d’uso dei propri prodotti un divieto di reverse engineering, sapendo che nell’Unione Europea la sua efficacia ha limiti precisi.

Infine, rendere il proprio prodotto pilotabile dagli agenti, attraverso API ben progettate o un server MCP, è al tempo stesso un’opportunità e un’esposizione. Ignorarlo significa rischiare di essere aggirati da concorrenti più facili da integrare, mentre abbracciarlo significa accettare che l’interfaccia grafica conti meno nel trattenere i clienti.

Per chi acquista software

Per i clienti la notizia è in larga parte positiva. Le alternative aumentano, il potere negoziale cresce e il calcolo tra acquistare e costruire si sposta, soprattutto per strumenti interni e applicazioni di nicchia per cui finora si pagava un canone solo perché costruirle costava troppo. Vale però la pena ricordare che un software in alpha non può sostituire un processo produttivo critico, e che manutenzione, aggiornamenti di sicurezza, conformità normativa e responsabilità in caso di problemi restano i criteri decisivi. Un repository su GitHub, per quanto popolare, non risponde a nessuna di queste domande. Chi decide di costruire in casa con gli agenti dovrebbe mettere a bilancio, oltre allo sviluppo iniziale, il costo di gestione e di evoluzione negli anni, che è sempre stato la voce più sottovalutata del software su misura e che gli agenti riducono meno di quanto riducano il costo di scrittura.

Il caso del codice legacy

C’è un ambito in cui tutte le condizioni favorevoli emerse in queste settimane si presentano insieme, ed è la modernizzazione del software legacy delle aziende. Chi migra il proprio codice possiede il sorgente, o quanto meno il binario e la documentazione, e quindi non ha alcun problema giuridico. Dispone spesso di un oracolo naturale, cioè il sistema in esercizio, i cui output possono essere confrontati con quelli del sistema nuovo, esattamente come nei job batch descritti da Cognition. E affronta un bersaglio che, almeno durante la migrazione, si muove poco.

I risultati concreti esistono. TechSpot riporta che un grande costruttore automobilistico ha spostato un flusso COBOL di 25.000 righe su AWS Lambda e che la banca brasiliana Itaú ha modificato il formato del codice fiscale aziendale in centinaia di programmi con tre mesi di anticipo sulla scadenza governativa, mentre Morgan Stanley dichiara di aver modernizzato con strumenti interni oltre 17 milioni di righe di codice. Il mercato ha preso sul serio questa possibilità al punto che, il giorno in cui Anthropic ha sostenuto che Claude può automatizzare l’analisi che domina la modernizzazione del COBOL, il titolo IBM ha perso il 13 per cento, la peggiore seduta dal 2000.

Anche qui, però, il quadro è disomogeneo. I sistemi in tempo reale, come l’autorizzazione dei pagamenti con carta, restano difficili proprio perché il ciclo di verifica è più complesso, e Gartner prevede che oltre il 70 per cento dei progetti di uscita dal mainframe avviati quest’anno fallirà perché chi li guida sopravvaluta le capacità dell’AI generativa. La lezione è la stessa del resto della vicenda. Gli agenti eccellono dove esiste una verifica automatica e una conoscenza del dominio che guida il processo, e falliscono quando si pretende che sostituiscano entrambe. La replica di IBM, secondo cui tradurre il COBOL è cosa diversa dal modernizzare un sistema aziendale, contiene una parte di autodifesa ma anche una parte di verità.

Conclusione

Guardata da vicino, la storia di queste settimane descrive soprattutto uno spostamento del punto in cui il software produce valore. L’AI ha reso economico un tipo di lavoro preciso, la trasformazione di una specifica nota o di un comportamento osservabile in codice funzionante, a condizione che esista un modo automatico per verificare il risultato. Dove queste condizioni ci sono, come nella decompilazione dei vecchi giochi, nella migrazione di sistemi batch o nella replica dei formati di file documentati, i progressi sono reali e in alcuni casi sorprendenti. Dove mancano, come nella coda lunga delle funzionalità di un prodotto professionale, nella scienza del colore, nelle integrazioni con l’hardware dei produttori o nella fisica di un videogioco, gli agenti producono screenshot convincenti e codice che si comporta in modo diverso dall’originale.

Per il SaaS la conseguenza è duplice. La sua architettura lo protegge dalla decompilazione, che però si sta rivelando la via meno rilevante, e lo lascia esposto alla ricostruzione comportamentale tanto quanto il software desktop. I prodotti il cui valore coincide in gran parte con ciò che si vede dall’esterno, cioè un’interfaccia curata sopra un modello dati e qualche flusso di lavoro, entreranno in una fase di forte pressione sui prezzi e di concorrenza da parte di alternative costruite in fretta, sia da nuovi fornitori sia dai clienti stessi. Quelli che custodiscono dati, effetti di rete, conoscenza di dominio non codificata, accordi con terze parti e responsabilità contrattuale ne usciranno probabilmente rafforzati, perché il resto del mercato diventerà più economico intorno a loro.

Resta aperta la questione giuridica, che a mio avviso sarà decisiva per i prossimi due o tre anni. Il diritto europeo distingue con chiarezza tra osservare il funzionamento di un programma e copiarne l’espressione, ma è stato scritto pensando a esseri umani che possono dimostrare di non aver visto un codice, e la prima causa importante su un clean room eseguito da un modello addestrato anche su codice altrui ridefinirà il perimetro di ciò che è lecito molto più di qualsiasi progetto virale su GitHub.

Nel frattempo, la domanda che ogni azienda software dovrebbe porsi è semplice da formulare e scomoda da affrontare, e riguarda quanta parte di ciò che vende potrebbe essere ricostruita da qualcuno che si limita a guardarla funzionare.

Fonti

• Decompilation on Steroids: Why AI Is Suddenly Cracking Open Old Software, TechSpot, 11 ottobre 2026
• Photoshop and Word Rebuilt in Rust: How AI Is Changing Software Cloning, innFactory AI, 13 ottobre 2026
• AI Reverse Engineering: Is Adobe Dead?, Fabio Akita, 13 ottobre 2026
• REA, Reverse Engineer Anything, repository GitHub
• AnyPS5, repository GitHub
• Resoconto di Maurice Heumann sulla decompilazione di Modern Warfare 2, 9 ottobre 2026
• Descrizione tecnica dell’exploit Relapse per PS5, 29 settembre 2026
• Progetto ArtCraft