Ho contato ogni modifica che un agente AI ha fatto a un sito Webflow vero. Non esiste una via di mezzo.

C’è un’app di cui mi occupo che si chiama TomoToki. È un calendario condiviso — organizzi con gli amici, chatti dentro ogni evento, vedi chi è libero prima di scegliere l’orario. È ferma da sette mesi, e il suo sito aveva bisogno di una passata seria: design da sistemare, SEO da scrivere, il tutto da riportare in vita.

È un lavoro vero con un perimetro vero. Così, invece di costruire qualcosa di scenografico con un agente AI e filmarlo, ho usato quel lavoro per rispondere a una domanda che volevo davvero togliermi:

Quanto di tutto questo riesce a farlo un agente da solo, e dove esattamente si ferma?

Cosa stavo usando, di preciso

Webflow ha una cosa chiamata MCP: un collegamento che permette a un assistente AI di parlare direttamente con il tuo progetto Webflow. Non “generami del codice che poi incollo”. L’agente legge le tue pagine vere, le tue classi vere, il tuo CMS vero — e le modifica.

Ho collegato Claude, gliel’ho puntato su TomoToki, e ho iniziato.

La differenza rispetto alla solita storia AI-e-Webflow conta: qui niente è un suggerimento che poi implemento a mano. Quando dico che l’agente ha creato una variabile, l’ha creata, nel progetto, e io sono andato a controllare.

Come ho deciso di contare, prima di cominciare

È la parte che dà senso a tutto il resto, quindi viene per prima.

Ho spezzato il lavoro in unità. Un’unità è una modifica piccola e verificabile:

• una variabile creata
• una proprietà impostata su una classe
• un campo aggiunto a una collection CMS
• il titolo SEO di una pagina

Non “l’header” e non “il design system”. Quelli sono contenitori — e se conti i contenitori, nascondi esattamente ciò che stai cercando di misurare. “L’agente ha costruito l’header” non ti dice se ha litigato con te per un’ora per farlo.

Poi mi sono dato cinque esiti possibili per ogni unità, fissati prima di aprire il progetto:

1. Pulito al primo colpo — l’agente l’ha azzeccata subito, senza aiuto.
2. Giusto dopo aver ri-chiesto — ho dovuto riformulare o riprovare, ma ci è arrivato.
3. A metà — l’agente ha fatto una parte e ho finito io a mano.
4. Fatto da me — l’agente non ci è riuscito, l’ho fatto manualmente.
5. Bloccato — non ci riusciva nessuno; non era possibile.

Due regole scritte nello stesso momento, perché sono entrambe facilissime da piegare una volta che vedi come stanno andando i risultati:

Le unità bloccate restano nel totale. Togliere in silenzio le cose che non hanno funzionato è il modo più semplice di ritrovarsi con un numero più bello.

I fallimenti li scrivo prima di decidere cosa pubblicare. Un numero senza i suoi fallimenti è una dichiarazione di marketing in camice bianco.

E durante tutta la prova non ho pubblicato niente. Il sito live non è mai stato toccato, e alla fine il progetto è tornato a un backup.

Il risultato

106 unità. Ecco come sono andate.

92 su 106 al primo tentativo. L’87%, se ti serve la percentuale.

Ed ecco perché quella percentuale, da sola, non serve quasi a niente.

Non è atterrato niente nel mezzo

Ricordi i cinque esiti possibili? Ne ho usati solo due.

Gli esiti 2, 3 e 4 — giusto dopo aver ri-chiesto, a metà, fatto da me — sono vuoti. Non rari. Vuoti. Su 106 modifiche, niente ha avuto bisogno di un secondo tentativo, niente è tornato finito a metà, e non una sola volta ho dovuto intervenire per completare qualcosa che l’agente aveva iniziato.

Ogni singola unità è stata esito 1 o esito 5. Pulita, oppure un muro.

Che è il contrario di come vengono raccontati questi strumenti. “L’AI fa la maggior parte del lavoro” ti fa immaginare una sfumatura — ti porta all’80% e tu rifinisci. Io una sfumatura non l’ho trovata. Ho trovato un dirupo.

Ed è una cosa utile, perché cambia di cosa ti devi preoccupare. Non devi rivedere se l’agente l’ha fatta più o meno giusta. Devi sapere, prima di iniziare, se quello che stai chiedendo sta sul lato possibile del dirupo o su quello impossibile.

Il che mi porta allo schema dentro quella tabella.

Bravissimo sui contenuti. Inaffidabile sui design system.

Guarda dove stanno gli zeri.

Tutto ciò che ha forma di contenuto è passato pulito, e in fretta. Ho scritto titoli e description SEO per sei pagine in tre lingue in una sola richiesta. Ho creato una collection CMS, aggiunto cinque tipi di campo diversi e riempito dieci schede complete in tre richieste. Dati strutturati su sei pagine: una richiesta, nessuna obiezione.

Tutto ciò che ha fallito era lavoro di design system.

Se ti stai chiedendo dove un agente si guadagna un posto nel tuo flusso di lavoro oggi, la linea è questa. Non è una percentuale. È una forma — e conoscere la forma vale più che conoscere il numero.

Una deviazione breve: cosa stavo costruendo, e perché

I fallimenti che seguono non hanno senso senza questo, quindi faccio un passo indietro.

Un design system, nel senso che intendo qui, è un insieme di valori con un nome a cui tutto il resto fa riferimento. Invece di scrivere #2168ca in quaranta punti diversi, lo definisci una volta come “colore primario” e ci punti quaranta cose. Cambi il valore di quel nome, e tutte e quaranta si aggiornano.

In Webflow questi valori con un nome si chiamano variabili. Nel mondo del design più in generale si chiamano spesso token. Stessa idea.

Material Design 3 è il design system aperto di Google, ed è quello da cui parto. È un buon punto di partenza perché non è solo una palette di colori: definisce dei ruoli. Non “blu”, ma “il colore di un pulsante primario” e “il colore che il testo deve avere quando sta sopra quel pulsante”. È quella distinzione che fa sopravvivere un design system all’impatto con un progetto vero, ed è il motivo per cui volevo quello invece di una manciata di colori messi insieme a mano.

Specifica anche due cose che contano per quello che viene dopo:

• Una modalità chiara e una scura, come parte del sistema fin dall’inizio e non come ripensamento.
• Una scala tipografica fluida. Dimensioni del testo che crescono in modo continuo con lo schermo invece di saltare a scatti sui breakpoint. In CSS si scrive normalmente con una funzione che si chiama clamp() — le dai un minimo, una dimensione preferita che scala, e un massimo, e il browser calcola il resto.

Quindi: costruire il set di token, aggiungere le modalità, rendere fluida la tipografia, e poi puntarci sopra le classi che il sito ha già. Questo era il piano.

L’agente ne ha fatta quasi tutta. Una cosa precisa lo ha fermato di netto.

Cosa si è rotto, e come so che non ero io

Quattro fallimenti. Per ognuno ho fatto la stessa cosa: invece di riportarlo da una singola chiamata andata male, ho provato una versione che avrebbe dovuto funzionare di sicuro. Se quella riesce e l’originale continua a fallire, hai trovato il confine vero. Se fallisce anche quella, la tua prima diagnosi era sbagliata.

È questo che intendo più avanti quando dico che l’ho verificato con qualcosa di più semplice.

1. La scala tipografica fluida non si è proprio potuta costruire

Prima, cosa non è rotto: l’agente ha creato 24 variabili al primo tentativo. Dodici ruoli colore, otto spaziature, due dimensioni di testo, due famiglie di font — più una seconda modalità per il tema scuro. Costruire un set di token funziona.

Tutte usavano un valore fisso e semplice. 16px. #2168ca. Roba lineare.

Il guasto sta in un punto preciso. Quando crei una variabile tramite l’MCP, puoi fornire il suo valore in due modi diversi:

• Un valore fisso — passi un numero e un’unità, tipo 16 e px, in due campi separati.
• Un’espressione personalizzata — passi un pezzo di CSS come testo, per tutto ciò che non è un numero semplice. È il campo che serve per clamp(), calc() e qualunque altra cosa contenga una funzione. È l’unica strada.

La strada del valore fisso ha funzionato benissimo, 24 volte. La strada dell’espressione ha fallito ogni singola volta, con lo stesso messaggio inutile: “Si è verificato un errore interno.”

E siccome una scala tipografica Material Design è fluida per definizione, quel campo da solo ha bloccato l’intera scala.

Ecco cosa ho provato, tutto attraverso quello stesso campo espressione:

E, per confronto, la strada del valore fisso sulle stesse identiche variabili: ha funzionato sempre.

La riga di 2rem è quella che chiude la questione, e vale la pena essere precisi sul perché. 2rem e un valore fisso di 2 + rem descrivono la stessa identica dimensione. L’unica differenza è in quale campo l’ho messo. Dai campi del valore fisso: tutto bene. Dal campo espressione: errore interno.

Quindi non è che Webflow rifiuti clamp(). Non è che la variabile sia del tipo sbagliato per quel valore. È il campo espressione che non funziona — fallisce sull’input più semplice possibile, e sull’esempio che sta nella documentazione di Webflow.

Un’ultima cosa, perché cambia quello che puoi farci: clamp() si scrive benissimo come normale proprietà CSS su una classe. Fallisce solo dentro una variabile. Quindi puoi avere dimensioni fluide nelle tue classi, ma non nei tuoi token — il che rompe in silenzio l’idea di un posto solo da cambiare per cui un sistema di token esiste.

2. Uno script che puoi creare, poi non usare, poi non cancellare

Webflow ti dà due modi per aggiungere il tuo JavaScript a una pagina, e sono molto diversi nello spirito.

Quello ordinato è lo script registrato. Carichi il codice una volta, riceve un nome e un numero di versione, Webflow lo ospita, e poi lo attacchi alle pagine che vuoi. Cambi il codice una volta e tutte le pagine si aggiornano. È l’approccio che sceglieresti se stessi costruendo qualcosa per bene.

Quello grezzo è la casella di custom code nelle impostazioni di pagina. Incolli il tuo tag script e basta. Nessuna versione, nessun riuso — codice in una casella.

Ho usato quello ordinato, perché è ciò che un’integrazione fatta con criterio dovrebbe preferire.

Caricare lo script ha funzionato. Tutto quello che viene dopo no:

• Attaccarlo a una pagina — fallito.
• Attaccarlo a tutto il sito — fallito.
• Elencare quali script sono attaccati — fallito.
• Staccarlo — fallito.
• Cancellarlo — fallito.
• Ripristinare l’intero progetto da un backup — era ancora lì.

Nel frattempo, incollare lo stesso identico codice nella casella grezza ha funzionato al primo colpo, e annullarlo è stato svuotare la casella.

Quindi il meccanismo prudente, strutturato e riutilizzabile mi ha lasciato una cosa che non posso usare e non posso rimuovere, mentre quello rozzo si è comportato perfettamente. Su 106 modifiche, l’unica cosa irreversibile che ho fatto è quella che sembrava più sicura. Quello script è ancora nel progetto. Non ho trovato un modo per toglierlo né nell’API né nella documentazione di Webflow.

3. Sei classi che non riuscivo a toccare, e tre tentativi per capire perché

Questa è iniziata come una piccola scocciatura ed è diventata la mia scoperta preferita.

Stavo puntando le classi esistenti sui nuovi token — dicendo alla classe H Paragraph Header di prendere il colore del testo dal token invece che da un esadecimale scritto a mano. Nove hanno funzionato subito. Una è tornata con “stile non trovato”.

Cosa strana, perché quel nome non l’avevo digitato. L’avevo copiato dal progetto pochi istanti prima.

Prima ipotesi: forse ci sono due classi con quel nome. Ho cercato, e c’erano — una classe normale e una combinata, entrambe chiamate H Paragraph Header. Spiegherebbe tutto: l’agente chiede un nome, rispondono in due, non ne viene scelta nessuna.

Bella teoria. Quindi l’ho messa alla prova per bene, cercando una classe con uno spazio finale nel nome ma completamente unica — un solo risultato, niente con cui confondersi. Se la mia teoria era giusta, quella doveva funzionare.

È fallita in modo identico. Quindi non erano i nomi doppi.

Restava la cosa che avevo davanti e non guardavo. Tutti questi nomi di classe finiscono con uno spazio. H Paragraph Header — con un carattere invisibile in fondo. La ricerca la trova, perché la ricerca confronta in modo permissivo. Rinominare e aggiornare vogliono il nome esatto, e qualcosa lungo quella strada taglia lo spazio prima di confrontare, così il nome non coincide più con sé stesso.

Sei delle 334 classi di questo progetto hanno quel problema. Una si chiama F2 — il nome intero è un prefisso di due caratteri e uno spazio.

Ed ecco perché è la mia preferita: uno spazio dimenticato in fondo al nome di una classe è esattamente il tipo di disordine per cui la rinomineresti. Le classi che avrebbero più bisogno di essere sistemate sono proprio quelle che lo strumento per sistemarle non riesce a raggiungere.

4. I messaggi di errore non vanno d’accordo tra loro

Tre messaggi veri, dalla stessa integrazione, nello stesso pomeriggio:

• “Non puoi avere nomi di stile duplicati.” Perfetto. Mi dice cosa c’è che non va e cosa fare.
• “Stile non trovato.” Per uno stile che esiste, dimostrabilmente. Peggio che inutile — mi ha mandato a caccia di una classe mancante invece che di uno spazio invisibile.
• “Si è verificato un errore interno.” Nessun campo, nessuna ragione, niente.

Dal primo ti riprendi. Il secondo ti depista. Sul terzo puoi solo tirare a indovinare — ed è per questo che diagnosticare il problema delle variabili mi è costato cinque tentativi buttati. Il messaggio non mi dava niente a cui mirare.

Tre cose che l’agente semplicemente non vede

Non sono bug. Sono assenze, e insieme rispondono a una domanda che vale la pena farsi prima di lasciare un agente vicino a un sito vivo senza guardarlo.

Non arriva alla rete di sicurezza. L’agente non ha modo di fare un backup, non ha modo di vedere se ne esiste uno, e non ha modo di tornare indietro. Ogni modifica che fa è definitiva, dal punto in cui si trova. Tutta questa prova l’ho protetta con un backup — fatto a mano, nell’interfaccia di Webflow, perché è l’unico modo. La rete c’è. È l’agente che non la tocca.

Non vede cosa ti consente il tuo piano. Può costruire un’intera struttura CMS e scoprire, nel momento in cui provi a pubblicare, che il tuo piano non la comprende.

Non vede cosa ha appena fatto. Questa è la meno ovvia e la più importante. L’agente legge le istruzioni — questa classe ha questa proprietà a questa dimensione di schermo — ma non vede mai la pagina renderizzata. Può recitarti ogni regola di stile del tuo progetto e non avere la minima idea di cosa guardi davvero una persona.

Ed è esattamente così che ho sbagliato io.

Le due cose che ho sbagliato

Sono mie, non di Webflow, e le includo perché lasciarle fuori renderebbe il resto meno affidabile, non di più.

Ho riportato un limite che non esisteva

A un certo punto mi serviva leggere il contenuto di un blocco di codice incorporato — una di quelle caselle in cui qualcuno ha incollato uno script dentro la pagina.

Ho provato la strada ovvia: chiedere gli elementi della pagina. Mi ha detto che il blocco c’era, ma non cosa contenesse. Ho provato a leggerne gli attributi: vuoti. Ho provato le impostazioni di custom code della pagina: vuote anche quelle, perché è una cosa completamente diversa. Ho provato lo strumento che costruisce HTML: quello scrive soltanto, non legge.

Quattro strade, tutte esaurite. Così l’ho scritto come un limite reale: l’agente non sa leggere il codice incorporato. Avevo più prove per quella conclusione che per la maggior parte di quelle giuste.

Era sbagliata.

C’è uno strumento nella cassetta il cui unico compito è darti le istruzioni per usare tutti gli altri. La sua descrizione dice, due volte, in maiuscolo, di chiamarlo prima di fare qualunque altra cosa. Niente nel sistema te lo mette davanti. L’ho trovato elencando tutti gli strumenti disponibili, molto tardi, per scrupolo e non perché qualcuno me l’avesse detto.

L’ho letto. Dice, chiaro e tondo, quale strumento legge il contenuto di un blocco di codice incorporato. Ho provato quello strumento. Mi ha restituito lo script subito, per intero.

Essere scrupolosi nella direzione sbagliata è indistinguibile dall’essere scrupolosi. Quattro strade esaurite sembravano una prova. Erano tutte e quattro la porta sbagliata, e non ho mai verificato se ce ne fosse una quinta.

Ho detto che una cosa era visibile quando non la vedeva nessuno

Passando in rassegna il sito ho trovato dei blocchi rimasti da un vecchio template — tra cui un pulsante, in russo, che non c’entrava niente con questa app.

Ho guardato come quei blocchi erano stilizzati a ogni dimensione di schermo, ho ragionato su quali regole si applicassero dove, e ho concluso che il pulsante si vedeva sui telefoni. L’ho scritto come una scoperta.

Poi qualcuno mi ha fatto una domanda semplice: sei sicuro? Io dal telefono non lo vedo.

Così ho aperto il sito a dimensione telefono e ho guardato. Il pulsante non compare a nessuna larghezza. È completamente invisibile. Il mio ragionamento aveva mancato il modo in cui queste regole scendono a cascata — una dimensione di schermo eredita da un’altra a meno che non la sovrascriva esplicitamente, e io avevo letto una regola come se sostituisse tutto quando invece aggiungeva soltanto.

Le informazioni sugli stili che avevo erano corrette. La conclusione che ne ho tratto no — e un’occhiata alla pagina vera l’avrebbe beccata.

Cos’hanno in comune

Ho ragionato sui dati invece di guardare il risultato.

Nessuno strumento ha beccato uno dei due errori. A beccarli è stato scrivere tutto mentre accadeva, così il ragionamento era ancora visibile giorni dopo — e qualcuno che mi ha fatto una domanda semplice su un’affermazione che avevo fatto con troppa sicurezza.

Quindi: devi lasciar fare questo lavoro a un agente?

In parte, e la risposta utile non è una percentuale. Riguarda da che lato di quel dirupo cade il tuo lavoro.

Se il tuo lavoro ha forma di contenuto — costruire strutture CMS, riempirle, scrivere metadati di pagina e dati strutturati — un agente si guadagna il posto oggi, e la velocità non è un guadagno marginale. Sei pagine di metadati in una richiesta è un altro tipo di pomeriggio.

Se il tuo lavoro ha forma di design system, aspettati dei muri, e aspettateli dove non li avevi previsti. Ho potuto costruire un set di token completo ma non rendere fluida la tipografia. Ho potuto rinominare la maggior parte delle classi ma non quelle che ne avevano più bisogno. Niente di tutto questo era indovinabile in anticipo — l’ho scoperto provando e contando.

E qualunque cosa tu stia facendo, non lasciarlo andare da solo. Non perché sia sbadato — è stato di una precisione sorprendente, 92 volte su 106 senza mai un secondo tentativo — ma per quei tre punti ciechi. Non può verificare il proprio backup, non può vedere cosa gli è permesso fare, e non può guardare quello che ha appena costruito. La precisione senza nessuna di queste tre cose è un buon motivo per restare nella stanza.

La cosa su cui continuo a tornare è il dirupo. Ci siamo tutti bevuti una storia in cui l’AI ti porta quasi in fondo e tu chiudi il lavoro. Su un progetto vero, su 106 modifiche, quella terra di mezzo non è mai comparsa nemmeno una volta. O ha funzionato del tutto, o non ha funzionato per niente — e se vale oltre questo singolo progetto, cambia cosa devi controllare. Smetti di verificare se il risultato è più o meno giusto. Inizia a capire, prima di partire, da che lato sei.

Un’ultima cosa su come è scritto questo pezzo. Ogni affermazione che ho fatto qui ha la sua prova accanto — i conteggi, gli input esatti che ho mandato e gli errori esatti che sono tornati, la teoria sbagliata sui nomi doppi e il test che l’ha smontata, entrambe le ritrattazioni. Niente sta dietro un link a un documento che prometto di pubblicare più avanti.

È voluto. Se un’affermazione come “otto fallimenti su quattro tentativi diversi” vale la pena di essere fatta, la cosa che la sostiene dovrebbe stare nello stesso posto dell’affermazione — non da qualche parte dove forse arrivo.