A marzo 2026 abbiamo rinnovato l’esperienza di moonshot.ai su tutta la platform. L’aggiornamento sembrava semplice: una nuova palette cromatica, una tipografia più precisa e animazioni aggiornate. In pratica, ha coinvolto componenti condivisi, design token, route e livelli interattivi dell’intero sito.
Abbiamo usato Kimi Code CLI, basato su Kimi K2.5, come agent di coding AI per aiutarci a realizzare il rifacimento. Questo progetto è diventato una prova concreta di come un agent da terminale si inserisca in un vero flusso di lavoro di produzione, non in un ambiente demo. In questo articolo raccontiamo come lo abbiamo usato e che cosa abbiamo imparato lungo il percorso.
Che cosa significava davvero questo refresh
Il refresh di moonshot.ai non consisteva nel riprogettare il brand da zero. Gran parte del lavoro di design esisteva già in Figma. La vera sfida era applicare quegli aggiornamenti in modo coerente a una codebase esistente.
Questo significava tracciare i token condivisi, aggiornare i componenti, verificare i comportamenti interattivi e assicurarsi che analytics e accessibilità non venissero compromessi. Molte modifiche erano piccole prese singolarmente, ma attraversavano più livelli del sito.
Questo tipo di lavoro non è difficile per la complessità algoritmica. È difficile per ampiezza e coerenza. La sfida è sapere che cosa viene toccato da una modifica e assicurarsi che nulla sfugga. Per supportare questo processo, abbiamo usato una connessione Model Context Protocol (MCP) con Figma, così da allineare meglio le specifiche di design all’implementazione, aiutando l’agent a comprenderne la struttura e riducendo l’interpretazione manuale.
Regole di base: rendere utile l’agent
Il primo passo non è stato scrivere prompt, ma impostare il contesto. Abbiamo usato il comando /init per generare un file AGENTS.md, poi abbiamo dedicato circa un’ora a perfezionarlo. Al suo interno abbiamo documentato che cosa rientrava nell’ambito del refresh, che cosa non poteva cambiare, come era strutturato il progetto e come funzionava il processo di build. Abbiamo anche aggiunto un file di regole con convenzioni di naming, spaziature e requisiti di contrasto.
Questa configurazione ha ridotto la necessità di ripetere spiegazioni in seguito e ha reso più coerente il workflow di Kimi Code CLI. Senza un contesto specifico del progetto, l’agent di coding AI tende a produrre risultati ragionevoli ma generici. Con quel contesto, il comportamento si avvicina a quello di un compagno di squadra che conosce già la codebase.
Come lo abbiamo usato davvero
Questa sezione descrive come Kimi Code CLI è stato usato concretamente durante il refresh: tracciamento delle dipendenze, allineamento al design, analisi dei comportamenti, controlli delle prestazioni e revisione dei rischi di integrazione. L’obiettivo non era automatizzare, ma ridurre l’incertezza in un refactor su larga scala.
Capire che cosa viene toccato dalla modifica
Prima di modificare qualsiasi cosa, abbiamo chiesto all’agent in Kimi Code CLI di leggere l’area interessata e di elencare che cos’altro dipendesse da essa. Una singola modifica, come il colore di un pulsante, può influire su hero section, sezioni di download, stati hover e token condivisi; componenti condivisi, timing delle animazioni e hook di analytics possono poi ampliarne ulteriormente l’impatto. Ottenere prima un elenco delle dipendenze ha ridotto le sorprese successive e reso le modifiche più prevedibili.
Allineare il codice alle specifiche di design
Abbiamo quindi confrontato i componenti con le specifiche di design, sezione per sezione: hero, navigazione, sezioni prodotto, CTA di download e footer. L’agent ha prodotto elenchi di modifiche a livello di proprietà confrontando gli stili con i design token e i valori di layout. Il processo è sembrato più vicino a un’automazione strutturata del design system che a un controllo visivo manuale. La maggior parte delle differenze era minima, come spaziature, border radius o peso del font, ma talvolta emergevano incoerenze più ampie, in punti in cui componenti che avrebbero dovuto condividere le stesse varianti si erano allontanati nel tempo. Il risultato è stato un elenco concreto di modifiche, non un processo di supposizioni visive.
Studiare i nuovi comportamenti
Il refresh ha introdotto nuovi comportamenti UI non ancora implementati nella codebase: un cursore personalizzato, una hero guidata a runtime, card illustrative che si animano all’hover e ingressi attivati dallo scroll.
Per ciascuna funzionalità abbiamo usato Kimi Code CLI come ambiente contestuale, caricando insieme documentazione e stato del repository. Qui Kimi K2.5 ha fatto la differenza: un contesto più ampio ha reso più facile ragionare su implementazione e riferimenti in un unico spazio.
Le domande erano pratiche:
Le animazioni all’hover devono completarsi o annullarsi all’uscita?
Lo stato del cursore deve interagire con il canvas della hero?
Che cosa si rompe quando più livelli si sovrappongono?
La finestra di contesto ampia ha reso possibile un workflow Kimi Code più continuo, in cui intento di design e codice convivono nella stessa sessione.
Controllare peso e prestazioni
Il refresh ha introdotto un nuovo carattere, più animazioni e asset aggiuntivi, aumentando il peso della pagina. Abbiamo usato l’agent per adattare lo script esistente di subsetting dei font e verificare l’output; in seguito ci ha aiutato a interpretare i report Lighthouse, così da individuare tempestivamente le regressioni. L’obiettivo non era ottimizzare tutto alla fine, ma decidere che cosa tenere o tagliare quando le modifiche erano ancora piccole.
Tracciare il rischio di integrazione prima del merge
Più livelli interattivi — animazione d’ingresso, cursore, canvas della hero — condividono ordinamento e comportamento del puntatore pur trovandosi in componenti separati, quindi una modifica in un livello può comunque influire sugli altri. Dovevamo anche tenere conto delle differenze tra browser e sistemi operativi, dove CSS e comportamento di rendering non sempre coincidono. Prima di fare il merge di gruppi di modifiche, abbiamo passato i diff a Kimi Code CLI chiedendogli di tracciare quali interazioni potessero essere interessate; poi abbiamo verificato quei percorsi nel browser ed eseguito un controllo leggero sui vari ambienti.
Integrazioni MCP e Skills
Model Context Protocol (MCP) ha permesso a Kimi Code CLI di collegarsi direttamente a sistemi esterni contenenti dati di progetto. Abbiamo usato MCP Figma per estrarre da Figma design token, dati di layout e tipografia, riducendo la traduzione manuale tra design e codice; abbiamo inoltre collegato strumenti interni, esponendo task, specifiche ed edge case senza cambiare contesto.
Aggiungere un server richiede un solo comando:
Il pattern si estende a tutto l’ecosistema MCP. Per ispirazione, puoi collegare gli agent a:
Figma — MCP ufficiale per contesto di design, variabili e dati di layout dal canvas
Atlassian Cloud — pagine Confluence e work item Jira tramite l’entry point MCP remoto di Atlassian (documentato insieme a Rovo)
Database, API CMS — server MCP di vendor o community; i registri elencano centinaia di opzioni per categoria
Il tuo stack può essere diverso: una API privata per la documentazione, un servizio interno di design token o un data warehouse. L’idea è la stessa: collegare l’agent ai sistemi che contengono già i dati rilevanti. Per file di configurazione, definizioni dei server e altri modi per configurare MCP in Kimi Code CLI, consulta la guida della platform.
Skill di revisione
Abbiamo anche scritto una Skill per la revisione del codice. È un file di regole che indica a Kimi Code CLI come valutare una merge request end-to-end: leggere il diff, tracciare file e componenti interessati, verificare violazioni del design system (colori letterali grezzi, spaziature fuori griglia, fallback di accessibilità mancanti), valutare il rischio per area e generare un report strutturato.
Il report segue un formato fisso:
Un riepilogo di intento e ambito
Risultati raggruppati per gravità (problemi critici che bloccano il merge, miglioramenti consigliati, suggerimenti minori di coerenza)
Per ciascun rilievo: evidenze dal diff, valutazione dell’impatto e un’azione concreta
La Skill segnala anche potenziali rischi che possono richiedere una rapida validazione su browser o dispositivo: casi in cui l’agent è incerto, ma il costo della verifica è basso.
In pratica, ogni PR durante il refresh visivo di moonshot.ai è passata attraverso questa verifica strutturata prima del completamento della review. L’output includeva sempre riepilogo dell’intento, rilievi ordinati per gravità, evidenze e correzioni.
Questo ha contribuito a ridurre il rimaneggiamento nelle fasi finali e ha migliorato la coerenza del workflow Kimi Code, facendo emergere problemi come URL hardcoded accanto a costanti condivise, campi analytics da allineare ed edge case di interazione mobile.
Cose che non ci aspettavamo
Durante il refactor sono emersi alcuni pattern che all’inizio non erano evidenti.
Il passaggio da specifica a codice è stato più rapido del previsto
Con Figma MCP e Kimi Code CLI nello stesso thread, dimensioni e design token arrivavano come input strutturato invece di essere trascritti manualmente. Il risultato sono stati cicli di iterazione più brevi per sezione: modifiche e correzioni a livello di proprietà spesso arrivavano in un solo passaggio, senza rimbalzi tra strumenti.
I prompt di ricerca hanno reso più del previsto
Il refresh si è basato molto su passaggi lunghi guidati dalla documentazione, attraverso documentazione runtime e implementazioni di riferimento accanto al repository. Tenere questi materiali nella stessa sessione del codice si è spesso rivelato prezioso quanto le modifiche stesse.
La Skill di review ha trasformato piccole incoerenze in un elenco
Il report strutturato ha fatto emergere le stesse classi di problemi descritte prima: URL hardcoded accanto a costanti condivise, campi analytics da allineare ed edge case di interazione mobile. Singolarmente erano per lo più minori, ma una volta raccolti in un unico passaggio risultavano più facili da affrontare.
Riprendere thread lunghi è rimasto poco costoso
Comandi come kimi --continue e /compact facevano sì che un lavoro di più giorni non richiedesse di ricostruire il contesto ogni mattina. Questo ha ridotto la necessità di ripetere prompt e ha mantenuto fluido lo stesso workflow Kimi Code.
Per maggiori dettagli su come riprendere le sessioni, passare dall’una all’altra e gestire il contesto con /compact e comandi correlati, consulta la guida alle sessioni di Kimi Code CLI.
Lezioni apprese dal rifacimento di moonshot.ai
Se dovessimo affrontare di nuovo un refresh visivo simile di moonshot.ai, ci sono alcune cose che faremmo in modo diverso.
Partire dal contesto, non dal codice
Dedicare la prima ora a documentare ambito, vincoli e convenzioni ha fatto risparmiare più tempo di qualsiasi prompt successivo. Stabilire tutto questo in anticipo ha reso strumenti come Kimi Code CLI più coerenti lungo l’intero workflow.
Collegare presto una fonte di verità
Nel nostro caso era Figma. In altri progetti potrebbe essere un CMS, una API interna o un design system. L’aspetto essenziale è garantire che il sistema lavori su dati reali invece che su ipotesi inferite, soprattutto quando si usa un agent di coding AI in un contesto di refactor frontend.
Tenere design e contesto del task nello stesso ciclo
Portare token, specifiche e implementazione in un contesto condiviso ha ridotto il vai e vieni e reso più stabili i cicli di iterazione. È qui che i workflow con Figma MCP e Kimi Code CLI si sono dimostrati particolarmente efficaci, perché hanno aiutato a mantenere allineati intento di design e modifiche al codice in un ciclo continuo.
Se non vuoi scrivere codice: Kimi Websites
Tutto quanto sopra descrive un workflow centrato sugli sviluppatori: terminali, diff e file di contesto. Tuttavia, lo stesso risultato — un sito web curato e responsive — può essere ottenuto anche senza quello stack, quando la velocità conta più del controllo a livello di framework.
Kimi Websites utilizza lo stesso modello Kimi K2.5, ma attraverso un’interfaccia visiva no-code. Descrivi ciò che vuoi in linguaggio naturale, perfezioni le sezioni tramite conversazione e pubblichi con un clic. Può anche ricevere come input uno screenshot esistente e ricostruirne la struttura di layout.
Per founder che prototipano landing page o marketer che devono pubblicare siti di campagna in tempi stretti, offre un percorso più rapido rispetto al lavoro diretto con uno stack frontend tradizionale.
Conclusione
Kimi Code CLI e Kimi K2.5 sono stati più utili nelle parti del progetto in cui contava più l’ampiezza che la complessità. Un refresh visivo raramente riguarda problemi difficili: riguarda molte piccole modifiche che devono restare coerenti in tutto il sistema. Questo lo rende dispendioso in termini di tempo per le persone, ma relativamente adatto a un agent capace di tracciare e confrontare elementi tra file diversi.
Le decisioni le abbiamo comunque prese noi, abbiamo revisionato ogni modifica e validato il risultato finale. L’agent si è occupato del tracciamento ripetitivo, dei confronti e del lavoro iniziale di review. In pratica, questa divisione del lavoro si è rivelata un modo concreto per integrare un agent di coding AI in un workflow di produzione. Per refactor su più file, verifica dal design al codice e lavoro di coerenza su larga scala, questo approccio si è dimostrato utile.