Grafica procedurale per siti web: generare le decorazioni invece di disegnarle

Stavo guardando YouTube la sera, senza cercare niente di preciso, e nel feed è comparso il video di un’agenzia di design che raccontava uno strumento costruito da loro. L’ho aperto per curiosità, che è il modo in cui iniziano di solito le cose che poi mi cambiano il lavoro.

Da qualche settimana lo uso su tutto quello che riguarda la parte grafica: le copertine di questo blog, i pattern dei siti dei clienti. E mi ha rimesso in discussione un paio di idee che avevo sul software in generale, non solo sulla grafica.

Lo strumento che ti costruisci in un pomeriggio

Il video era di Pixel Point, un’agenzia di design, e presentava Toolcraft: uno starter kit per costruire piccole applicazioni creative con un agente AI.

L’idea è semplice. Chiedere a un modello “fammi un tool che genera questo effetto” produce quasi sempre un giocattolo che si rompe appena tocchi uno slider. Non perché il modello non sappia scrivere l’effetto, ma perché un’app creativa è fatta soprattutto di contorno: come si comporta il canvas, come sono raggruppati i controlli, come funziona l’export, cosa succede alle performance quando trascini un valore. Toolcraft mette quel contorno nella scatola, insieme alle istruzioni per l’agente, ai controlli già pronti e ai passaggi di verifica. Tu descrivi solo l’effetto che vuoi. Lanci npx @pixel-point/toolcraft create, apri la cartella con l’agente, scrivi il prompt, e dopo qualche decina di minuti hai un’applicazione tua.

Io la grafica procedurale l’avevo già frequentata anni fa, per curiosità. Vedere quanto fosse diventato corto il tragitto tra “mi piacerebbe uno strumento che fa X” e lo strumento che fa X mi ha fatto cambiare idea su una parte del mestiere.

Da tre tentativi a trecento

Ho iniziato dalle cose mie. Le copertine degli articoli di questo blog non le disegno più una per una: ho un generatore che le sforna dentro il sistema visivo del sito, e il mio lavoro è scegliere.

Poi è arrivato il caso vero, con un cliente.

Stiamo costruendo da zero il sito di Donati Capsolution, un’azienda che produce tappi e componenti di packaging per profumeria e cosmetica. In fase di progettazione grafica abbiamo trovato un pattern che raccontava bene il prodotto. Buono, ma uno solo, e nessun modo di sapere se fosse il migliore possibile o solo il primo capitato.

Abbiamo costruito lo strumento. Pochi parametri, quelli che contavano davvero per quel pattern, e un pulsante per generare. Ne abbiamo prodotti a quantità industriale, il che per un’azienda manifatturiera è anche una battuta accettabile, e li abbiamo guardati tutti insieme. La variante che abbiamo scelto non era tra le prime tre che avrei disegnato a mano. Non ci sarei arrivato ragionando, ci sono arrivato vedendo.

Questa è la parte che mi interessa di più: la quantità non è un vezzo, è un metodo di selezione. Quando generare la centesima variante costa zero, smetti di difendere la prima.

Un programma fatto per essere riprogrammato

C’è però una cosa che mi ha colpito più dei pattern, e riguarda il software in sé.

Toolcraft non è un prodotto nel senso classico. Non ha una schermata da imparare, non ha funzionalità da confrontare in una tabella. È un ambiente con dentro dei vincoli, delle istruzioni e dei pezzi già montati, e il suo scopo dichiarato è essere riprogrammato da un agente. Un metaprogramma, se vuoi: il valore non sta in quello che fa, sta in quello che rende facile far fare a qualcun altro.

Se questa cosa si generalizza, cambia il rapporto tra chi scrive software e chi lo usa. Oggi l’utente sceglie tra le opzioni che il prodotto gli ha lasciato aperte. Nel modello che intravedo qui, l’utente riceve una base coerente e si costruisce la sua versione: non configura, riscrive. E chi produce il software smette di progettare funzionalità e inizia a progettare vincoli, cioè a decidere cosa deve restare vero in tutte le versioni custom che nasceranno.

Ed è anche il motivo per cui non credo alla lettura per cui l’AI toglie il lavoro a chi progetta. Lo strumento genera trecento varianti, ma la variante buona qualcuno deve saperla vedere. Il criterio resta il collo di bottiglia, e il criterio non si genera.

Cosa c’entra con Brixter

Sto sviluppando Brixter, un toolkit per siti dove i contenuti vivono nel repository come file versionati invece che dentro un database o un CMS di terze parti.

Quando l’ho iniziato, la domanda che mi facevo era: quali funzioni deve avere l’editor. Dopo questa storia la domanda è diventata un’altra: quanto è facile, per un agente, costruire il pezzo che manca.

Non è una riscrittura della roadmap, è uno spostamento di baricentro. Le pagine sono file dichiarativi, le sezioni sono blocchi di markup annotato, il pacchetto distribuisce le guide per gli agenti e le installa nella forma che serve al team che le usa (skill per Claude Code, regole per Cursor, AGENTS.md). Tutta roba che esisteva già per ragioni pratiche, e che adesso leggo come la parte più importante del progetto: Brixter è più utile come substrato ben vincolato che come applicazione con tante funzioni.

Gli elementi decorativi non sono più immagini

L’altra conseguenza è più terra terra e riguarda tutti i siti che facciamo.

Finora un elemento decorativo era un asset: qualcuno lo disegnava, veniva esportato, finiva in una cartella. Da lì in poi era congelato. Cambiare la palette del brand voleva dire riaprire il file sorgente, sperare che esistesse ancora, ri-esportare venti immagini.

Se invece l’elemento decorativo nasce da un generatore, resta parametrico. Sta nel repository come codice, non come PNG. Ha gli stessi controlli del design system, quindi cambiare un colore lo propaga ovunque. Puoi produrne una variante per ogni pagina senza che il sito sembri assemblato da fonti diverse, perché la grammatica è la stessa. E puoi decidere se renderizzarlo a build time, se ti serve un’immagine leggera, o lasciarlo vivo nel browser dove ha senso.

Il costo di questo approccio è concentrato all’inizio, nella costruzione dello strumento. Il beneficio è distribuito su tutta la vita del sito, che è esattamente il tipo di scambio che mi interessa.

Dove non funziona

Vale la pena dirlo, perché questo metodo ha un perimetro preciso.

Funziona quando il risultato si giudica a occhio in due secondi. Un pattern, una copertina, un effetto: guardi e sai. Non funziona dove la correttezza è invisibile, dove per capire se una cosa va bene devi ragionarci sopra o verificarla con i dati. Lì generare trecento varianti non ti aiuta a scegliere, ti dà trecento cose da controllare.

Quindi no, non è “l’AI costruisce il software al posto nostro”. È una fascia di problemi, quelli visivi e ripetitivi, che ha smesso di costare quello che costava. Ed è abbastanza per cambiare come progetto la parte grafica di un sito.

Parliamone

Se stai pensando a un sito nuovo per la tua azienda e vuoi parlarne con qualcuno, raccontaci il tuo progetto.