Andy Matuschak sostiene che app chiuse e programmazione specialistica stanno frenando l’invenzione, mentre gli agenti di codice potrebbero rendere i software più malleabili e prototipabili.
Per anni il software ha promesso libertà, ma ha consegnato silos. Matuschak parte da qui, sostenendo che due scelte nate quasi per inerzia, il modello delle app e la cultura della programmazione, hanno ristretto ciò che gli utenti possono immaginare e modificare. La sua tesi è che gli agenti di codice cambiano di nuovo il rapporto tra idee e implementazione, soprattutto nelle interfacce complesse. Il punto, dice, non è solo far costruire software ai non programmatori, ma rimettere in circolo l’invenzione stessa.
Matuschak apre con una tesi semplice e scomoda: il software personale aveva promesso strumenti su misura, ma si è trasformato in un paesaggio di monoliti e recinti. Il modello delle app, sostiene, ha spinto i produttori a costruire pacchetti adatti al mercato più ampio possibile, e gli utenti si sono ritrovati a poter toccare solo le manopole previste dal produttore. Il risultato, dice, è che i flussi di lavoro si piegano male a ciò che serve davvero.
Abbiamo camminato nel sonno dentro due teorie accidentali. La prima è il modello delle applicazioni, e questo ha portato a pacchetti validi per tutti.
1:02
Viviamo in un paesaggio di giardini recintati, e il risultato è che spesso i nostri flussi di lavoro non funzionano come vorremmo.
1:41
Il bersaglio successivo è la programmazione stessa, che Matuschak non descrive come una lingua universale ma come una specializzazione che ha occupato troppo spazio. Invece di diventare alfabetizzazione di massa, dice, è rimasta in mano a un piccolo ceto tecnico, e questo ha finito per rallentare l’invenzione anche dentro l’industria e la ricerca HCI*. Non è soltanto una lamentela contro gli utenti passivi; è un’accusa alla cultura che decide chi può immaginare strumenti nuovi.
Non abbiamo creato una nuova alfabetizzazione universale, abbiamo creato un sacerdozio specializzato.
1:41
La versione familiare di quel reclamo è che gli utenti finali vengono relegati al ruolo di consumatori passivi del medium dinamico.
2:01
Matuschak dice che gli agenti di codice stanno finalmente rendendo praticabile una vecchia ambizione dell’HCI: permettere agli utenti di estendere il software che usano davvero, senza riscriverlo da zero. Il bersaglio non sono le funzioni marginali, ma le superfici centrali di lavoro, quelle che oggi restano chiuse dentro app enormi e rigide. Nel suo racconto, il cambiamento non passa ancora per una rivoluzione di massa, bensì per i primi varchi che gli agenti aprono dentro la vita quotidiana di chi non programma.
Voglio vedere realizzato il sogno dei media dinamici personali per le parti più importanti della loro pratica.
3:49
Quelle parti spesso avvengono in app enormi, estremamente complesse.
3:49
La sua misura della svolta è prudente. Dice di vedere dashboard personali, automazioni, script che collegano sistemi incompatibili, ma ammette che per ora gli agenti producono soprattutto glue code ai margini del lavoro reale, non ancora estensioni profonde delle interfacce principali. È un passaggio importante: la tecnologia che promette di democratizzare la programmazione, per ora, sembra più brava a cucire che a reinventare.
Per Matuschak, il problema è strutturale: i plugin tradizionali vivono in pannelli separati, mentre la parte davvero utile del software resta intoccabile. In app come Photoshop o Premiere, osserva, un’estensione che tocchi la superficie principale dovrebbe ricreare quasi tutta la complessità dell’applicazione, e questo scoraggia sia gli sviluppatori sia gli strumenti automatici. Le applicazioni restano monoliti chiusi, dice in sostanza, perché l’alternativa sarebbe un caos difficile da governare.
Se vogliamo liberarci dei monoliti in silos, ci servirà un substrato più malleabile degli agenti di codice zero-to-one di oggi.
4:22
Se i plugin potessero entrare e cambiare le cose, il caos arriverebbe in fretta.
5:00
Nel demo, il punto non è l’ennesima funzione brillante ma il fatto che due estensioni diverse riescono a convivere nello stesso editor senza rifare da capo il resto. Matuschak mostra prima un plugin che ancora le citazioni all’EPUB e poi un altro che sincronizza audio e trascrizione, per arrivare a una tesi semplice: la novità conta poco se resta intrappolata in un prototipo, mentre la composizione la rende usabile davvero.
Ora è ancora solo un documento Markdown. Ma da questo punto in poi è solo testo semplice, così posso estendere i miei commenti, spostare tutto nel documento, copiarlo, incollarlo, trattarlo come una materia.
9:47
Qui però ho un’idea nuova, un diverso tipo di direttiva Markdown che ho chiamato direttiva di trascrizione. Posso premere play e ottengo la riproduzione audio sincronizzata con la trascrizione testuale.
10:22
La sequenza serve a una dimostrazione precisa. Se un comportamento nuovo può essere inserito, spezzato, copiato e persino combinato con un altro comportamento senza perdere il resto dell’editor, allora il plugin non è una decorazione, ma un pezzo di infrastruttura. È lì che l’argomento si sposta dai singoli trucchi all’architettura che li rende possibili.
Quello che è eccitante in questa demo non è il design di interazione di quei plugin. Quello che è eccitante è che non è un sistema di ricerca: l’ho portato dentro Obsidian, un word processor di produzione che uso davvero.
14:06
Qui Matuschak insiste sul confine tra laboratorio e uso quotidiano. Un’interfaccia interessante, dice in sostanza, resta povera se vive solo in un paper, perché l’utente deve comunque abbandonare il proprio ambiente e pagare il costo di un software separato. Obsidian diventa così la prova che l’invenzione utile non è solo quella che funziona, ma quella che entra nel flusso normale del lavoro.
A 21:16 un certo punto Matuschak sposta il discorso dalle app alle letture. Se i sistemi di scrittura possono essere estesi da plugin che agiscono sullo stesso testo e sugli stessi stati, dice, allora la domanda vera è perché il leggere resti ancora confinato a PDF e pagine statiche, come se il supporto cognitivo dovesse finire con il margine. La sua mossa è generalizzare la logica di CodeMirror a un reader che non si limiti a mostrare contenuto, ma lo renda combinabile, annotabile, vivo.
La questione, in realtà, è peggiore del bisogno di strumenti estensibili per professionisti. I lettori seri non hanno proprio gli strumenti professionali in primo luogo.
21:11
I nostri ambienti di lettura si sono evoluti molto poco. Eppure c’è così tanto spazio perché evolvano.
21:50
Qui il suo argomento cambia scala. Matuschak insiste che il medium della lettura dovrebbe fare per la comprensione quello che Figma fa per il layout o un mixer per il suono: assorbire parte del carico mentale e rendere visibili gli effetti delle scelte in tempo quasi reale. Oggi, sostiene, si lavora ancora su immagini di carta su schermo, mentre il testo resta inerme e il lettore si prende tutto il peso.
Quando faccio iterazione su un sistema di design in Figma, vedo in tempo reale come le mie scelte influenzano layout e peso su ogni schermata dell’app che sto progettando. Quando mixo un brano, i visualizzatori di spettro mi aiutano a individuare e correggere rapidamente i segmenti impastati.
21:50
Per dimostrare che non sta parlando in astratto, Matuschak elenca una piccola genealogia di reader aumentati già esistenti: Skim, SiteSee, Papio, Liquid Text, Space Ink, Quantum Country*. Il punto però non è celebrare quei progetti uno per uno. È che restano tutti segregati nel loro sistema, costringendo chi li vuole usare a cambiare lettore ogni volta, proprio come le prime demo di plugin restavano intrappolate in un prototipo da laboratorio.
Se vuoi usare lo schema colorato di SiteSee, devi usare il suo prototipo come lettore PDF. E poi, se vuoi funzioni da ciascuno degli altri sistemi che ho appena citato, dovresti cambiare completamente lettore per ciascuno di loro.
Per Matuschak, il problema non è più solo scrivere codice più in fretta. Il vero collo di bottiglia è che la programmazione ha occupato uno spazio culturale troppo grande dentro l’invenzione delle interfacce, lasciando in secondo piano design e conoscenza del dominio. Così, sostiene, anche quando il settore celebra la creatività, finisce spesso per produrre variazioni prudenti di forme già note.
Penso che il problema centrale sia che inventare nel medium dinamico richiede troppa programmazione.
29:18
Se nuove interfacce sono bloccate soprattutto dal lavoro di design immaginativo e da una profonda conoscenza del dominio, allora questa asimmetria mette pressione selettiva sulle competenze sbagliate.
31:32
Matuschak richiama Alan Cooper e il suo *The Inmates Are Running the Asylum*, il libro che negli anni Novanta accusava i programmatori di imporre interfacce brutte e ostili. Dice che quella critica ha già prodotto una correzione utile, perché la specializzazione ha dato spazio all’interaction design e i modelli di interfaccia si sono diffusi. Ma per lui il vecchio problema era solo il primo strato.
Cooper era preoccupato per una tirannia accidentale dei programmatori che sottoponevano le persone a interfacce utente comicamente pessime. Io sono preoccupato per una tirannia accidentale dei programmatori che trattiene l’immaginazione nelle interfacce utente.
29:52
Il passaggio decisivo, nella sua lettura, è culturale: quasi tutti gli ambienti che oggi discutono di interfacce finiscono per essere popolati da programmatori, formati più nell’analisi che nella progettazione o nel dominio. Matuschak insiste che questo produce una selezione distorta, perché chi non programma resta dipendente dagli altri proprio nella fase in cui servirebbe iterare, fallire, usare davvero il prototipo. A quel punto, dice, il lavoro si sposta verso ciò che è più facile fare da soli, spesso il visual design, mentre la parte davvero dinamica resta incompiuta.
La programmazione senza design o senza conoscenza del dominio può produrre interfacce funzionanti, anche se spesso noiose o difettose, mentre il design o la conoscenza del dominio senza programmazione restano bloccati sul tavolo da disegno.
Matuschak chiude spostando il peso dal codice al costo mentale di lavorarci sopra per ore, ma senza ritirare la scommessa. Gli agenti, dice, possono frammentare l’attenzione e rendere facile una forma di agitazione produttiva che assomiglia troppo a una fuga dal pensiero lento; eppure restano, per lui, il modo migliore per far entrare più idee nel circuito iniziale del prodotto.
I costi sono reali, ma li sopportiamo per ora perché gli agenti di codice sono una buona notizia per l’invenzione.
42:37
Voglio aumentare il flusso immaginativo nella parte alta del funnel. Quella fase iniziale mette meno pressione sulla qualità del software.
39:55
La sua distinzione è netta: un prototipo deve essere soltanto abbastanza reale da far sentire a designer e colleghi come un’idea si comporta in contesto. È qui che cita il valore di prototipi ad alta fedeltà per media dinamici, contrapposti alle statiche artboard e ai demo cliccabili che raccontano poco del comportamento vero dell’interfaccia.
Un prototipo deve essere abbastanza reale da permettere al designer di capire come la sua idea si sviluppa in un contesto autentico e da comunicarla chiaramente agli altri.
40:03
Un prototipo ad alta fedeltà può specificare chiaramente un comportamento dinamico nuovo.
40:19
Qual è la tesi centrale di Matuschak?
La sua tesi è che il software moderno abbia creato due blocchi: app troppo chiuse e programmazione troppo specialistica. Gli agenti di codice, secondo lui, possono abbassare la soglia per inventare e personalizzare interfacce.
Perché cita Obsidian e CodeMirror?
Li cita come prova che una UI può essere costruita in modo composabile, così i plugin non restano confinati ai margini. Per lui è il tipo di architettura che permette agli agenti di fare davvero la differenza.
Perché parla di lettura e non solo di editing?
Perché vuole mostrare che il problema non riguarda solo scrivere, ma anche leggere e annotare in ambienti più dinamici. La sua idea è che anche la lettura possa diventare un medium estensibile come un editor.
Secondo lui, qual è il vero collo di bottiglia?
Non è soltanto la qualità tecnica dei prototipi, ma il fatto che per inventare servano insieme design, dominio e programmazione. Dice che oggi il sistema seleziona troppo spesso il talento tecnico e troppo poco l’immaginazione.
Qual è la critica ai team di prodotto tradizionali?
Matuschak sostiene che spesso i non programmatori dipendano troppo dai programmatori per iterare su un’idea. Questo rallenta la scoperta, perché impedisce di lavorare abbastanza presto e abbastanza spesso con un prototipo vivo.
The Inmates Are Running the Asylum (1999)
Matuschak cita il libro per contrapporre la sua tesi a quella di Cooper: non teme solo interfacce brutte, teme che la programmazione stia frenando l’invenzione.
Sintesi assistita dall'AI del podcast di Andy Matuschak, verificata sulla trascrizione originale.