Perché uso Cursor con l'MCP di Figma — e perché continuo a testare su un iPhone via cavo

"Frontend assistito dall'AI" prima significava incollare uno screenshot in una chat e ricevere un CSS vicino, ma mai con lo spazio giusto, il grigio giusto, la line-height giusta. Il Model Context Protocol ha cambiato proprio quella parte del passaggio di consegne del design. Cursor parla con il server MCP di Figma e, invece di appiattire un frame in pixel su cui il modello deve indovinare, riceve il vero albero dei nodi: auto-layout, valori di spaziatura, variabili collegate, nomi dei componenti, scala tipografica. È su questa parte che mi affido davvero ogni giorno.

1. Cosa l'MCP fa davvero bene

Seleziono un frame in Figma, do il link a Cursor, e interroga il server MCP per quel nodo esatto. Quello che torna è strutturato: un gap di 8px è il numero letterale 8, non qualcosa che misuro con un righello su un PNG. Un colore è il token di design o l'hex che la designer ha collegato, non un valore che scelgo con un contagocce sperando che coincida. Peso del font, line-height, raggio degli angoli, la vera gerarchia dei componenti — tutto arriva come dati, non come un'immagine che reverse-engineerizzo.

• Spaziature che corrispondono al design system, non al numero tondo più vicino che ho indovinato.
• Colori e tipografia come token, così un rebranding aggiorna una variabile invece di un grep su tutti i componenti.
• Confini dei componenti che corrispondono a come la designer ha effettivamente raggruppato le cose, il che rende più facile mantenere semantico il markup generato.

2. Cosa continuo a controllare a mano

I dati strutturati non sono giudizio. Un frame Figma mostra un breakpoint alla volta; non dice a Cursor cosa succede tra 768px e 1024px, né come appare una card con un titolo su due righe invece che su una. Non c'è stato vuoto, stato di errore, skeleton di caricamento, perché quelli non hanno mai avuto un frame di design. E il markup generato può essere strutturalmente fedele al frame pur restando un div dove dovrebbe esserci un button, una nav o un tag di intestazione — leggo ancora ogni componente per la semantica e l'accesso da tastiera prima del merge.

3. Perché un emulatore non basta

La barra dei dispositivi di Chrome DevTools è Chromium che renderizza un viewport ridimensionato. Non è WebKit, non ha il comportamento del viewport dinamico di Safari su iOS, e non mostrerà i bug che esistono solo sul motore reale. Quindi l'ultimo passo prima che qualcosa vada in produzione è collegare un vero iPhone al mio Mac con un cavo. Impostazioni → Safari → Avanzate → Web Inspector, attivato una volta sul telefono. Poi un cavo Lightning o USB-C al Mac, il menu Develop di Safari rileva il dispositivo, e ottengo un Web Inspector dal vivo — DOM reale, console reale, pannello di rete reale — collegato a una pagina che gira davvero su Safari iOS, non su una sua simulazione.

È lì che catturo i bug che un emulatore nasconde: un padding safe-area-inset che sembra a posto in DevTools e viene tagliato sotto il notch sul telefono reale, un salto di 100vh quando la barra degli indirizzi di Safari si comprime durante lo scroll (dvh lo risolve, ma solo un test dal vivo lo dimostra), il salto del focus dell'input quando la tastiera si apre con un footer fisso a schermo, l'overscroll elastico che trascina tutto il layout, e come si comporta davvero la pagina aggiunta alla schermata home come PWA autonoma. Niente di tutto ciò appare in un emulatore. Tutto ciò appare la prima volta che un cliente reale apre il link sul proprio telefono — quindi preferisco vederlo prima io.

4. Perché proprio Safari — il browser per cui rilascio davvero

Guardo le analytics prima di decidere cosa significhi anche solo "corretto" per un progetto. Per la maggior parte dei siti di piccole imprese e servizi che costruisco, la cliente che apre il sito è sul telefono, arrivando da Instagram, Telegram, Google Maps o un messaggio — e per una grande fetta di quel traffico, quel telefono è un iPhone. Chrome desktop è dove sviluppo. Safari iOS è dove si trova davvero la persona con la carta di credito. Ottimizzare il pixel-perfect per il browser che fisso tutto il giorno e saltare quello che tiene davvero in mano la cliente del mio cliente significa ottimizzare per il pubblico sbagliato.

Il ciclo reale

Frame di Figma, selezionato e passato a Cursor tramite l'MCP. Componente costruito con token reali, non pixel indovinati. Un passaggio per la semantica, gli stati e i breakpoint che il frame non ha mai mostrato. Poi l'iPhone esce dal cassetto, si collega al Mac, e la stessa pagina gira dal vivo nel Web Inspector di Safari sul motore reale. Solo dopo qualcosa viene unito. Due strumenti diversi, due compiti diversi: uno mi avvicina velocemente al design, l'altro mi dice la verità sul dispositivo che la cliente del mio cliente userà davvero.

Vuoi che sembri davvero giusto sul telefono del tuo cliente?

Questa è la pipeline che eseguo su ogni build: veri token di design in entrata, dispositivo reale in uscita. Scrivimi tramite il modulo di contatto e dimmi quale piattaforma usano davvero i tuoi clienti — costruirò e testerò per quella, non per il browser comodo per me.