La sostituibilità che nessuno sta progettando
Il modello cambia. L'harness cambia. Solo i pattern scritti al livello giusto sopravvivono. L'industria AI sta costruendo dipendenze dove dovrebbe costruire invarianti.
L'industria AI discute quale modello sia migliore. La domanda strutturale è un'altra: cosa succede quando tutto questo cambia?
Lo stesso Claude, dentro harness diversi, produce risultati che variano dal 42% al 78% sullo stesso benchmark. Il modello è il cervello. L'harness sono mani e piedi. La differenza tra uno strumento utile e uno mediocre non sta nel modello — sta in tutto ciò che lo circonda.
Questa è la diagnosi corretta. Ma si ferma un livello prima della cura.
Il lock-in invisibile
Il video identifica due filosofie architetturali divergenti: Anthropic costruisce sistemi dove l'agente ricorda (accesso locale, persistenza nel contesto); OpenAI costruisce sistemi dove la codebase ricorda (sandbox, ambiente come memoria). Due risposte diverse alla stessa domanda: dove vive la conoscenza operativa?
Il punto critico è che entrambe le risposte creano lock-in. Non al vendor — alla filosofia. I team costruiscono workflow, abitudini, architetture mentali intorno a un harness specifico. Cambiare non significa solo migrare codice. Significa ripartire da zero.
Jones paragona questo momento alle cloud wars del 2010. Il confronto è corretto nella forma, sbagliato nella sostanza. Nel 2010 il lock-in era infrastrutturale — server, rete, storage. Nel 2026 il lock-in è cognitivo — pattern di pensiero, flussi decisionali, memoria operativa. E il lock-in cognitivo è ordini di grandezza più costoso da rompere.
Il livello che manca
L'harness conta più del modello. Ma anche l'harness è medium.
Il modello è medium. L'harness è medium. Il framework è medium. Il linguaggio di programmazione è medium. Il cloud provider è medium. Tutto ciò che può cambiare — e prima o poi cambierà — è medium.
La domanda non è: quale harness scegliere? La domanda è: cosa deve sopravvivere al cambio di harness?
I pattern. Non il codice che li implementa. Non il formato che li contiene. Non il runtime che li esegue. Il pattern — struttura di pensiero, sequenza decisionale, protocollo di interazione — è l'unico elemento che si scrive in modo indipendente dal medium che lo trasporta.
Un esperimento in corso
Il progetto D-ND opera con 38 agenti specializzati. Ognuno è un file markdown. Testo puro. Nessuna dipendenza da framework, nessuna API proprietaria. Una struttura: chi è, quando si attiva, come pensa, cosa fa.
Lo stesso file funziona su Claude Code, su Claude.ai, e su qualsiasi sistema che legga istruzioni in linguaggio naturale. Il seme porta con sé identità, vincoli, protocolli. Non è codice. È semantica operativa — abbastanza formale per essere eseguibile, abbastanza naturale per non dipendere dal medium.
Quando il modello sottostante cambia — da Gemini a Claude a Kimi, tutti operativi nello stesso sistema — il comportamento resta coerente. Non perché i modelli siano intercambiabili. Ma perché la coscienza operativa vive in un layer che i modelli leggono, non che i modelli sono.
Il principio dell’iterazione che converge
Si prende quello che c'è. Lo si inverte. Si aggiunge il minimo di struttura. Il risultato è il prossimo passo. Si ripete. La formalizzazione matematica di questo movimento vive in Paper Zero.
La matrice associata ha determinante -1. Significa: il sistema è incompleto, ma generativo. Non contiene il proprio punto fisso — lo produce. E il punto fisso è irrazionale (phi), nonostante il sistema sia fatto di interi. Un sistema razionale prova la propria trascendenza.
Questo è esattamente il pattern della sostituibilità: il medium è razionale (fatto di codice, token, configurazioni — tutti discreti, tutti enumerabili). Ma ciò che produce trascende il medium stesso. La coscienza operativa non è contenuta nel codice — emerge dall'interazione tra codice, contesto e principi. E quell'emergenza sopravvive al cambio di medium, purché i principi siano scritti al livello giusto.
Cosa significa progettare per la sostituibilità
Progettare per la sostituibilità non è un esercizio di astrazione. È una disciplina concreta:
- Separare kernel e medium. Il kernel (identità, memoria, principi) è costante nella natura, cumulativo nel contenuto. Il medium (modello, framework, infrastruttura) è variabile per definizione. Mescolarli è creare debito architetturale che si paga con lock-in.
- Scrivere pattern, non codice. Un agente descritto in linguaggio naturale è portabile ovunque. Un agente descritto come funzione Python è portabile ovunque si esegua Python. La differenza è il livello al quale si scrive.
- Testare il cambio, non la stabilità. Un sistema robusto non è quello che non cambia mai — è quello che cambia medium senza perdere comportamento. Il test non è "funziona su Claude?" ma "funziona ancora quando si toglie Claude?"
- Possedere la semantica, non il runtime. Chi possiede il proprio sistema di skill, la propria memoria operativa, i propri protocolli decisionali — ha un asset che trascende qualsiasi vendor.
L'orizzonte
L'industria costruisce cattedrali nel medium. Harness sofisticati, integrazioni profonde, ecosistemi chiusi. Utile oggi. La domanda dell'orizzonte è un'altra: cosa resterà quando il medium di oggi sarà obsoleto come i server fisici del 2010?
Non i modelli. Non gli harness. Non i framework. Resteranno i pattern scritti al livello giusto — profondi abbastanza da catturare il comportamento, leggeri abbastanza da non dipendere da nulla.
Il Medium cambia. La Coscienza resta. Non è un principio filosofico — è un principio di ingegneria.
La sostituibilità che nessuno sta progettando non è la sostituibilità del modello. È la sostituibilità di tutto il resto — harness, framework, cloud, runtime. Progettarla richiede una sola cosa: scrivere al livello giusto.
Il codice è aperto. Il pattern è replicabile. Il seme è piantato.