Il pulsante esiste già. Eppure un agente di IA ne crea uno nuovo, con un colore proprio, spaziature diverse e una variante in più. Nello screenshot la replica sembra simile. Nel progetto, però, è comparso un secondo componente che d'ora in poi andrebbe mantenuto separatamente. Il problema non è soltanto la comprensione delle immagini, ma l'identità mancante del componente.
Figma Code Connect collega i componenti di design ai loro corrispettivi nel codice e rende queste relazioni utilizzabili per Dev Mode e MCP. La documentazione attuale descrive quindi un percorso specifico per il contesto. Non dimostra alcun miglioramento generalizzato di qualità o costi. La nostra domanda è: di quali informazioni ha bisogno un agente per riutilizzare davvero il pulsante esistente?
La variante è un contratto
Il nostro componente di esempio si chiama QuietButton. Ha un aspetto primario e uno secondario, oltre a uno stato disabilitato. L'istruzione non è «Costruisci qualcosa di simile», ma «Usa questo componente in una configurazione consentita». Sembra ovvio, ma richiede una relazione precisa tra design e codice.
Design: understated action button
Code: QuietButton
Allowed variant: secondary
Label: View details
State: enabledQuesta scheda è uno schema di mappatura nostro, non un file di configurazione di Code Connect. Rende visibile dove altrimenti un agente dovrebbe tirare a indovinare. Un valore dal suono simile come «quiet» non è automaticamente un parametro valido se il componente effettivo si aspetta «secondary».
Lo stesso vale per contenuto e stato. Un pulsante attenuato a scopo decorativo può essere implementato in modo diverso da un controllo effettivamente disabilitato. La sola impressione visiva non basta quindi per la mappatura tecnica.
Un piccolo esempio reale è meglio di una lunga descrizione dello stile
Oltre alla mappatura, fornisci all'agente un utilizzo esistente. Per un semplice componente HTML potrebbe apparire così:
<button class="action action--secondary" type="button">
View details
</button>Le classi appartengono al nostro esempio. Quali regole CSS portino con sé deve stabilirlo il tuo progetto. Il valore aggiunto è che all'agente non si chiede di inventare prima una nuova struttura. Riceve un punto di partenza concreto con modifiche limitate.
Un'integrazione utile indica che cosa va preservato: lo stesso componente, varianti valide, l'operatività da tastiera esistente e lo scopo effettivo dell'azione. Un'ampia raccolta di materiale con esempi contraddittori potrebbe aiutare meno di un estratto breve e aggiornato.
Le mappature obsolete possono sembrare molto convincenti
Supponi che il progetto rinomini una proprietà. La vecchia mappatura resta comprensibile e ben formattata. Per l'agente è un contesto plausibile, ma tecnicamente sbagliato. Anche il collegamento al codice attuale va quindi mantenuto.
Per una verifica pratica di ciò che hai già, scegli tre componenti usati di frequente. Annota per ciascuno un utilizzo reale e le sue varianti consentite. Confronta questi dettagli con il codice attuale prima di pubblicare una nuova mappatura. Questo esercizio suggerito non afferma che sia già stata effettuata una revisione del repository né che un'esecuzione di IA abbia avuto esito positivo.
Un controesempio affina la mappatura: che cosa dovrebbe succedere se il design richiede una variante che il componente non ha affatto? Invece di inventare in silenzio un nuovo pulsante, l'implementazione dovrebbe segnalare questa lacuna. Il contesto mancante diventa allora una decisione di design consapevole, che può essere presa nel progetto reale.
I valori del brand completano il componente, ma non lo sostituiscono
Se riutilizzi un tuo componente di pagina in KENJTEC, la scheda del brand di KENJTEC BrandStudio ai può fornire colori, font e forme specifici. Applica questi valori in modo consapevole all'esempio HTML/CSS esistente, invece di far reinventare il componente partendo solo da un'immagine.
I tuoi HTML, CSS e JavaScript possono poi essere preparati manualmente nella modalità sviluppatore di KENJTEC WebSiteBuilder ai, visualizzati separatamente nell'anteprima e pubblicati come codice personalizzato. Ciò non significa un'importazione automatica da Code Connect né l'hosting di app React. La mappatura resta nel tuo flusso di sviluppo esterno.
La lezione tecnica è trasferibile: un design system non è fatto solo di forme simili. Ha bisogno di relazioni verificabili tra varianti visibili e componenti effettivi. Quanto più concrete sono queste relazioni, tanto meno un agente deve indovinare e tanto più facile è valutarne il risultato rispetto al progetto esistente.
Fonti e stato
Ricerca e documentazione aggiornate al 25 ottobre 2026. Code Connect: Introduction.
