Per decenni il menu dei file ha fatto la domanda sbagliata.
Fai clic destro su un file e il sistema operativo ti dà un elenco di app. Anteprima. Pages. QuickTime. Word. Il file diventa un timbro sul passaporto di qualunque applicazione lo rivendichi. Secondo noi è un approccio capovolto.
Scegli la destinazione, non l’app
Alla maggior parte delle persone non interessa quale app apra un file, ma cosa ottenerne.
Un PDF dovrebbe diventare testo. Una registrazione dovrebbe diventare una trascrizione. Una cartella di ricevute dovrebbe diventare righe in un foglio di calcolo. Uno screenshot dovrebbe diventare una descrizione. L’intento è ovvio. Il percorso software è la parte fastidiosa.
Così in MachineFabric abbiamo cambiato la domanda. Non chiediamo «Quale app apre questo file?», ma «Cosa vuoi che questo file diventi?». Tutto il cambiamento sta qui. Piccolo in superficie, profondo nella sostanza. Il menu del Finder smette di essere un selettore di app e diventa un menu di trasmutazione.
Il vecchio modello ti costringe a pensare per passi
Prendi un PDF scansionato. Nel vecchio modello devi ragionare così:
- Probabilmente è un problema di OCR.
- Quale app usiamo per l’OCR?
- Apri il file lì.
- Esporta.
- Salva il risultato da qualche altra parte.
È il software che costringe l’utente a fare il lavoro di routing.
Non vogliamo che le persone pianifichino catene di strumenti a mente per normali operazioni sui file. Vogliamo che nominino il risultato.
Estrai il testo.
Dovrebbe bastare.
Il percorso dovrebbe essere automatico e ispezionabile
Nel momento in cui lasci scegliere alle persone destinazioni invece che app, ti serve sotto un vero sistema di routing. Niente corrispondenze per parole chiave. Niente pile di if scritti a mano. Niente LLM che tira a indovinare quale strumento chiamare.
Ti serve qualcosa di formale. Ed è questo CapDAG.
Ogni cartuccia dichiara cosa accetta e cosa produce. L’host fa il dispatch con una sola regola:
- Gli input sono controvarianti.
- Gli output sono covarianti.
Suona accademico. Non lo è. È semplicemente il classico subtyping di funzioni applicato alle trasformazioni di file.
Se una cartuccia accetta Document, può gestire un PDF. Se una cartuccia produce SearchablePDF, può soddisfare una richiesta di PDF.
Quell’unica regola basta a rendere preciso il dispatch. Nessuna ambiguità. Nessuna tabella di percorsi mantenuta a mano. Nessuna euristica di corrispondenza che «funziona quasi sempre». Il grafo si risolve a partire dalle firme di tipo.
Questo conta perché, una volta che la regola è formale, il concatenamento diventa affidabile:
pdf -> page text -> summary
video -> audio -> transcript
image -> description -> generated text
È l’idea delle pipe Unix, ma per media tipizzati invece che per flussi grezzi di byte.
Pensa a pdf | ocr | summarize, solo che il sistema conosce la forma di ogni passo prima di eseguire qualsiasi cosa.
Le cartucce fanno un solo lavoro ciascuna
Non abbiamo costruito tutto questo come un’unica, gigantesca applicazione con ogni funzione per i file incollata dentro. Abbiamo costruito cartucce.
Una cartuccia è un piccolo programma con un contratto rigoroso. Prende un input specifico. Produce un output specifico. Espone capacità. Tutto qui.
Questa separazione conta. Rende il sistema più facile da comprendere. Più facile da testare. Più facile da verificare. Più facile da estendere.
Mantiene anche circoscritta la responsabilità. Una cartuccia non ottiene privilegi impliciti solo perché esiste. Ottiene le capacità e i permessi che il suo compito richiede. La sicurezza non è un’aggiunta a posteriori: è l’architettura.
La privacy nasce dal design
Molto software parla di privacy a posteriori. Noi volevamo che la privacy fosse l’impostazione predefinita, quella noiosa.
Il dispatch è locale. La pianificazione è locale. L’esecuzione è locale. I modelli girano sul tuo computer attraverso runtime locali come MLX e llama.cpp. Quindi il file non deve mai lasciare il tuo Mac perché il sistema funzioni.
È questo il tipo di eleganza che ci interessa.
Un buon design non aggiunge tre pagine di impostazioni per gestire un problema. Elimina alla radice l’intera classe di problemi. Nessuna pipeline di upload. Nessun account obbligatorio. Nessun passaggio dal cloud solo per trasformare un file in un altro.
Un altro livello dell’informatica
Non stiamo cercando di fare un menu «Apri con» migliore.
Stiamo cercando di sostituire l’interazione con i file centrata sulle applicazioni con un’informatica centrata sulle trasformazioni. È questo il vero cambio di paradigma.
I file smettono di essere oggetti da consegnare alle app. Diventano punti di partenza in un grafo di trasformazioni tipizzato.
Tu nomini la destinazione. Il sistema trova il percorso. Il percorso è ispezionabile. L’esecuzione è locale. I componenti restano piccoli e componibili.
Per questo MachineFabric è diverso. Non è un menu contestuale a cui è stata appiccicata l’IA. È una nuova risposta a una vecchissima domanda dei sistemi operativi.