Design e codice sincronizzati con Paper MCP e Claude Code: cosa insegna il caso Paper Shaders

Il 19 ottobre 2026 Codrops ha pubblicato un articolo di Jesper Landberg, sviluppatore creativo, in cui gli shader di Paper vengono portati fuori dallo sfondo e applicati agli elementi della pagina. La parte più riutilizzabile è il metodo con cui design e codice restano allineati: token condivisi e un agente che legge e scrive il file di design. Va letto per ciò che è, il racconto di un autore su un sito dimostrativo.

Il progetto e il suo flusso di lavoro

PaperDrops è uno studio fittizio, con una pagina color crema e una grande scritta nera che si increspa intorno al cursore. L'autore ha iniziato disegnando liberamente in Paper, a occhio. Le larghezze però non coincidevano tra un'immagine a larghezza fissa e un frame che riempiva il contenitore. Lo ha risolto con due cose: token di design e frame con logica flexbox.

Prima di scrivere codice ha tenuto un file design-system.md con griglia, scalini di spaziatura, scala tipografica e colori per ruolo, unendo i valori quasi identici. Poi il server MCP di Paper ha permesso a Claude Code di leggere il file, con struttura, valori CSS e token, così la costruzione è partita dal design reale. Secondo la documentazione di Paper, il server permette agli agenti sia di leggere sia di scrivere i file di design, ed è presentato come più accurato perché Paper è costruito su HTML e CSS.

Il flusso ha funzionato anche al contrario. L'autore ha costruito prima il mobile in codice e poi ha fatto riscrivere il risultato in Paper dall'agente, una artboard per sezione, riusando token e foto del desktop. Le modifiche fatte in Paper sono tornate nel codice: centrare la scritta nel mobile è diventata una modifica a una classe.

Token con nomi per ruolo

I token seguono la convenzione @theme di Tailwind v4, con nomi legati al ruolo, e Paper li esporta come blocco @theme. L'autore ne usa circa 55, tra colori, raggi e spaziature. Un esempio dal testo:

@theme {
  --color-ground: var(--color-white);
  --color-ink: var(--color-black);
  --font-sans: "Host Grotesk";
  --text-display: 80px;
  --tracking-display: -0.04em;
}

Cambiare il font sans da PP Neue Montreal a Host Grotesk ha richiesto di modificare un solo token. È il vantaggio concreto del metodo: una decisione di design si cambia in un punto solo.

Shader sugli elementi, non su un canvas di sfondo

Gli shader di Paper sono GLSL per WebGL. L'autore li ha portati a mano in WGSL per WebGPU, riportando che la matematica si è trasferita quasi riga per riga. Per applicarli usa domgl, una libreria WebGPU sua che rispecchia gli elementi DOM come piani su un unico canvas. La GPU disegna immagini, testo e riquadri, mentre gli elementi originali restano nella pagina per layout, accessibilità e selezione del testo. Un materiale si assegna con un elemento dedicato, per esempio <gl-media src="project-01" material="lens" />.

Gli effetti sono tre: distorsione a lente sulle miniature dei progetti, un effetto warp sui divisori di sezione che sembrano strappati, e una texture di carta applicata come passaggio di post-processing a tutto il frame, quindi le pieghe agiscono anche su testo e immagini. Sulle miniature piccole l'autore ha ridotto i parametri, soprattutto lo swirl, perché una distorsione forte sembrava un filtro fotografico.

Dove il racconto si ferma

L'articolo non riporta prestazioni, frame rate o test di accessibilità, e non descrive fallback per i browser senza WebGPU. Dichiara solo che tenere gli elementi nel DOM aiuta accessibilità e selezione del testo. domgl è una libreria dell'autore: non se ne descrivono API completa, maturità e licenza. Un problema concreto emerso: le immagini copiate dal desktop mantenevano l'impostazione fill e collassavano a altezza zero nel layout mobile impilato.

Sul supporto del browser, web.dev scriveva il 25 novembre 2025 che WebGPU è supportato in Chrome e Edge su Windows, macOS e ChromeOS, in Firefox 141 su Windows, e in Safari 26 su macOS Tahoe 26, iOS 26, iPadOS 26 e visionOS 26, con limiti su Linux, Android e Mac Intel per alcuni browser. È una fotografia di quella data e le versioni precise di Chrome non le riporto perché la pagina non mi è risultata univoca. Prima di proporre un effetto simile in produzione servono quindi un fallback e una verifica dei dispositivi di destinazione.

I limiti del flusso con Paper MCP

La documentazione di Paper dice che Paper Desktop deve essere aperto con un file attivo per leggere e scrivere. Segnala inoltre che design molto grandi o molto annidati possono dare errori nelle chiamate, e che spezzarli aiuta, e che le sessioni lunghe dell'agente sono la causa più comune di problemi. Nella parte sulla sincronizzazione con Figma elenca casi che non convertono bene, tra cui riempimenti SVG e sovrascritture di colore dei componenti.

Cosa portarsi via

Questa è una mia lettura. Il metodo vale anche senza shader: un file di regole del design system scritto prima, token con nomi per ruolo e un agente collegato al file di design riducono le divergenze tra mockup e codice. La parte WebGPU è invece un esperimento ancora da verificare su prestazioni e accessibilità, e da considerare come miglioramento progressivo con una versione statica di base.

Fonti

1. Codrops, Jesper Landberg, “Designing in Paper as a Developer: Taking Paper Shaders off the Background”, 19 ottobre 2026
2. Paper, “Documentazione MCP”
3. web.dev, “WebGPU is now supported in major browsers”, 25 novembre 2025