Codex + uno strumento segreto è il flusso di lavoro di design che stiamo usando nella nostra agenzia... e il risultato è davvero su un altro livello.
Lo dico da mesi. Se la tua app sembra robaccia AI, non è un problema di Codex. È un problema di flusso di lavoro.
La maggior parte degli sviluppatori è bloccata nello stesso loop. Lanciano funzionalità con l'AI. Il backend funziona. La logica è solida. Ma l'interfaccia sembra uguale a quella di tutte le altre app fatte con vibe coding. Gli utenti decidono in due secondi se sembra reale o no.
La vecchia soluzione era assumere un designer. Aspettare settimane per i file Figma. Poi guardare il tuo sviluppatore interpretare quei design e ricostruirli in codice. Quando il design era finalmente in produzione, avevi perso slancio e bruciato soldi che non era necessario bruciare.
Ora l'intero processo è opzionale.
Per questo walkthrough ho creato Haven, un concept di app immobiliare mobile. Sistema di design completo in 20 minuti. Ogni schermata progettata in meno di un'ora. Codice di produzione distribuito tramite Codex senza riscrivere una sola riga di CSS.
Questo è il flusso di lavoro che sto usando ora. E chiunque costruisca con l'AI deve capire come funziona.
Cosa è veramente Moonchild
Lo strumento segreto è Moonchild.
Ho testato quasi tutti i tool di design AI lanciati nell'ultimo anno. La maggior parte sembra decente sulla prima schermata, poi crolla nel momento in cui costruisci una seconda pagina. Il problema è la coerenza. Moonchild lo risolve in un modo che nessun altro ha fatto finora.
È una tela di design basata su chat che parte dal tuo sistema di design. Non da un prompt vuoto. Non da uno screenshot. Dal tuo sistema reale. Puoi inserire il tuo sistema in tre modi:
→ Importare da Figma, GitHub o un URL live
→ Descrivere il tuo brand al suo Agentic Design System Builder
→ Inserire ispirazione di design da Dribbble o da qualsiasi altra parte
Una volta che il sistema è dentro, non fai prompt per i design nel vecchio modo. Incolli un PRD. Genera schermate complete in base al tuo sistema. Da lì fai art direction.
E il percorso di export è ciò che chiude il cerchio. Moonchild distribuisce un connettore MCP che passa i tuoi design direttamente a Codex come output strutturato. Non uno screenshot che Codex deve interpretare. I veri dati di design. Componenti, token, layout, tutto.
Questo è il flusso di lavoro. Ora ecco come usarlo davvero.
Il problema con il modo in cui la maggior parte degli sviluppatori usa l'AI per il design
Ecco cosa fa la maggior parte degli sviluppatori.
Fanno un prompt a Codex per costruire una nuova funzionalità. Viene distribuita. Sembra ok. Poi fanno un prompt per la funzionalità successiva. Sembra leggermente diversa. Alla quinta funzionalità l'app sembra fatta di cinque prodotti diversi messi insieme.
Questo è ciò che la gente intende quando dice che il design AI fa schifo.
Il modello non fa schifo. Il flusso di lavoro sì.
Codex non ha idea di quale sia il tuo linguaggio di design. Ogni prompt è un contesto nuovo. Ogni schermata è un tentativo. Ogni componente si allontana dal precedente. I colori cambiano. La tipografia cambia. Tutto si accumula.
La soluzione è semplice. Dai a Codex un sistema da seguire. Poi dagli il design reale da costruire.
La maggior parte dei flussi di lavoro dà l'uno o l'altro. Moonchild più la connessione MCP dà entrambi contemporaneamente.
Step 1: Costruisci il tuo sistema di design per primo. Sempre.
Questo è lo step che tutti saltano. Ed è anche il più importante.
Noi di @ignytlabs costruiamo un sistema di design per ogni singolo cliente prima ancora di toccare una schermata. Una volta ci volevano due giorni di lavoro per un designer. Moonchild lo fa in circa 20 minuti.
Per questo walkthrough ho creato Haven, un concept di app immobiliare mobile. Ci sono diversi modi per inserire un sistema di design in Moonchild. Puoi importare da Figma, GitHub o un URL live. Puoi descrivere il tuo brand all'Agentic Design System Builder. Per Haven ho fatto quello che faccio di solito quando parto da un vibe: ispirazione di design da Dribbble. Ho inserito tre screenshot di app immobiliari mobile che avevano la sensazione che cercavo e una breve descrizione di cos'è Haven e a chi è destinata. Lo strumento ha estratto il linguaggio di design e ha costruito il sistema da zero.
Quello che mi ha sorpreso è quanto tutto sia visualizzabile. La maggior parte degli strumenti AI, incluso il flusso di lavoro Google Stitch di cui ho scritto nel mio ultimo articolo, ti danno un file di token piatto. Colori. Font. Forse spaziatura. Questo fa qualcosa di diverso. Costruisce una libreria completa di componenti e una galleria. Ogni badge, bottone, card e chip renderizzato nel modo in cui apparirà realmente nella tua app. Clicca su qualsiasi componente e lo vedi dal vivo, con controlli per testare varianti e dimensioni. Subito sotto l'anteprima ottieni il vero JavaScript, CSS, esempi e dipendenze per quel componente. Pronto per essere integrato nel codebase.
La galleria è la parte che cambia veramente il modo di progettare. Invece di indovinare come dovrebbe apparire un "badge del brand" o un "badge di valutazione" nel contesto, li vedi tutti affiancati. In vendita. In affitto. In evidenza. Tutta la famiglia in una volta. Prendi decisioni di design informate prima che venga generata una singola schermata.
È la differenza tra un foglio di stile e un sistema reale.
Step 2: Dal PRD all'UI
Una volta che il tuo sistema di design è dentro, non fai prompt per i design nel vecchio modo.
Incolli un PRD.
Un brief di una pagina sulle funzionalità. Una specifica di prodotto. Una dichiarazione di obiettivo. Qualunque cosa tu abbia.
Per Haven ho incollato un PRD strutturato che copriva l'introduzione del prodotto, gli obiettivi, gli utenti target e i ruoli, le funzionalità chiave e l'ambito MVP, i percorsi utente completi, lo stack tecnico e la direzione di design. Circa una pagina. Abbastanza specifico da dare al contesto reale allo strumento. Abbastanza strutturato da estrarre i dettagli giusti nelle schermate giuste.
Poi ho fatto qualcosa che la maggior parte delle persone salta.
Ho fatto un brainstorming con lo strumento prima di generare una singola schermata.
Questa è la chiave che la maggior parte degli sviluppatori si perde. La modalità chat contiene tutto il contesto del PRD. Invece di dumpare il PRD e premere genera, prima discuti il prodotto. Conferma l'elenco delle schermate. Blocca il pattern di navigazione. Pre-definisci la gerarchia delle schermate chiave prima che esista un pixel.
Per Haven ho chiesto:
→ "Sulla base di questo PRD, quali schermate mi consigli di costruire per prime? Mi manca qualcosa per un'app immobiliare?"
→ "La navigazione principale dovrebbe essere un tab in basso con Home, Cerca, Preferiti, Profilo? O qualcosa di diverso?"
→ "Prima di generare, guidami attraverso l'ordine di priorità per la schermata dei dettagli della proprietà. Prima le foto, poi nome e prezzo, poi specifiche, poi servizi, poi agente. Conferma o migliora."
→ "Ok, ora procedi e genera queste schermate sia in modalità chiara che scura, attenendoti al sistema di design che ho attualmente collegato. Assicurati di completare l'intero percorso utente e creare tutte le schermate."
Quando ho premuto genera, lo strumento conosceva già il prodotto meglio di quanto la maggior parte dei designer farebbe dopo la prima chiamata con il cliente.
Ora una nota rapida sulle varianti. Leggi attentamente.
Una bella funzionalità: puoi creare diverse varianti delle tue schermate. Devi solo menzionarlo esplicitamente a Moonchild e lui se ne occuperà. Per Haven volevo tre diverse direzioni estetiche per l'intera app prima di impegnarmi in una. Ecco il prompt esatto che ho usato:
"Voglio che tu generi 3 concept di design UI mobile completi per Haven:
Concept 1 - Editoriale Caldo: Sfondo crema, spaziatura generosa, titoli serif per i nomi delle proprietà, ombre morbide, trattamento delle immagini in stile rivista.
Concept 2 - Moderno Audace: Modalità scura, alto contrasto, sans-serif ovunque, angoli netti, dominato dalle foto con immagini da bordo a bordo.
Concept 3 - Minimal Premium: Palette neutra (bianco sporco, carbone, un accento), tipografia raffinata, tanto spazio, micro-interazioni sottili.
Usa il sistema di design collegato come base ma lascia che ogni concept porti il sistema in una direzione estetica diversa. Genera schermate complete, non solo sezioni. Cosa farai?"
Nota il "Cosa farai?" alla fine. È il piccolo dettaglio che fa funzionare il tutto. Invece di generare tutto alla cieca, lo strumento è tornato con un piano.
Ha detto che avrebbe costruito 5 schermate rappresentative per concept per prime. Avrei esaminato le tre direzioni affiancate. Una volta scelta quella che volevo, avrebbe progettato l'intera app in quella direzione.
Questo cambia completamente l'equazione dei costi. Non stai pagando per tre build complete. Stai pagando per tre campioni rapidi, poi una singola build completa nella direzione che scegli effettivamente.
Ho scelto quella editoriale calda. Il set completo di schermate è tornato dopo.
Ora la parte che mi ha veramente sorpreso.
Ogni schermata generata da Moonchild è interattiva in modalità anteprima. Non un mockup statico. Veramente interattiva.
Puoi cliccare nei campi di input. Toccare i pulsanti. Muoverti tra le schermate come un vero utente che testa il prototipo prima che venga scritto qualsiasi codice. Per Haven ho individuato due problemi di flusso in anteprima che sarebbero finiti in Codex altrimenti. La schermata dei dettagli della proprietà non aveva un modo ovvio per tornare alla navigazione. Il CTA per contattare l'agente era troppo in basso. Entrambi sarebbero stati distribuiti se avessi passato il design a Codex senza prima cliccare.
Questa è la chiave. Testi il prodotto prima che venga scritto qualsiasi codice.
Il ciclo di raffinamento è l'ultimo pezzo.
Quando una schermata ha bisogno di lavoro, non ripeti il prompt da zero. Selezioni la schermata, dici allo strumento cosa cambiare, e genera una v2 al suo posto. Vuoi un hero più cinematografico? v2. Vuoi scambiare un layout a card per una vista a elenco? v3. Le varianti si accumulano così puoi confrontare e scegliere la più forte.
Per la schermata dei dettagli della proprietà di Haven ho fatto tre iterazioni. La v1 aveva il blocco agente troppo in alto. La v2 ha sistemato la gerarchia ma la galleria foto sembrava piccola. La v3 ha azzeccato entrambe. Circa 8 minuti di avanti e indietro.
Non stai curando da una lavagna vuota. Stai raffinando una direzione reale. Questa è la parte che sembra più vicina a lavorare con un designer senior.
Step 3: Collega Moonchild a Codex tramite MCP
Qui è dove il flusso di lavoro diventa PAZZESCO.
Il sistema di design dà a Codex le regole. La connessione MCP dà a Codex qualcosa di più potente: accesso diretto all'output di design reale. Non screenshot. Non descrizioni testuali del design. Dati di design strutturati che Codex può leggere e ricostruire.
Ecco la configurazione:
→ Vai su Impostazioni Moonchild, poi MCP
→ Copia il comando di installazione per la tua configurazione
→ Apri Codex CLI
→ Incolla il comando di installazione
→ Autenticati con il tuo account Moonchild
→ Fatto
Una volta connesso, Codex vede sia il tuo sistema di design che le schermate specifiche di Haven che hai progettato.
Step 4: Codex Distribuisce il Codice
Ora fai un prompt a Codex in questo modo:
Recupera il progetto Haven Real Estate Mobile App utilizzando il Moonchild MCP e fammi sapere tutte le schermate che abbiamo al suo interno.
Questo primo prompt fa due cose: conferma che l'MCP è collegato correttamente e dà a Codex visibilità completa su ogni schermata che hai progettato.
Un consiglio rapido prima di lasciare che Codex faccia cose più pesanti. Resta in modalità piano. Codex mostra cosa sta per fare prima di eseguire. Leggi il piano ogni volta. Assicurati che capisca quali schermate vuoi, in che ordine e con quale fedeltà. Questa è la differenza tra Codex che codifica ciò di cui hai veramente bisogno e Codex che codifica ciò che pensa tu voglia.
Una volta che hai esaminato il piano e l'hai puntato sulla schermata che desideri, Codex prende i dati di design direttamente da Moonchild, fa riferimento al tuo sistema di design e scrive il codice. Aggiunge anche gli stati hover, le transizioni e la gestione dei casi limite perché lavora da dati di design reali invece di indovinare da un prompt.
Il risultato: UI di livello produzione nel tuo codebase reale, corrispondente esattamente al design, in pochi minuti.
Noi di @ignytlabs una volta preventivavamo due settimane per il design su ogni MVP cliente. Un designer creava il file Figma. Uno sviluppatore lo interpretava. L'interpretazione si discostava. Correggiamo. Ciclo. Con questo flusso di lavoro l'intero ciclo si riduce a un singolo pomeriggio di lavoro. Stessa qualità. Margine più alto. Molto meno cambio di contesto.
Quando Usare Questo Flusso di Lavoro
Non è il flusso di lavoro giusto per ogni team. Sii onesto su quando si adatta.
Usalo quando:
→ Distribuisci MVP da solo o con un piccolo team
→ La coerenza del design si rompe continuamente tra le schermate
→ Non vuoi mantenere un pipeline separato Figma → designer → sviluppatore
→ Hai già un sistema di design e vuoi che venga applicato ovunque
Saltalo quando:
→ Sei in scala con un team di design interno completo e una libreria Figma matura
→ Hai bisogno di un handoff pixel-perfect per un sito marketing o lavoro di brand dove ogni ombra conta
→ Il tuo codebase ha pattern UI altamente personalizzati che richiedono lavoro di design su misura
Per l'80% degli sviluppatori che distribuiscono MVP e prodotti SaaS, questo flusso di lavoro copre tutto ciò di cui hai bisogno.
A cosa Fare Attenzione
Qualche bandiera onesta prima di metterlo in pratica.
La qualità del tuo sistema di design determina la qualità dell'output. Immondizia in, immondizia fuori. Un file Figma a metà con tre token di colore produrrà schermate mediocri. Investi tempo sul sistema all'inizio. Si ripaga su ogni schermata.
La qualità del PRD conta. Un brief vago produce schermate generiche. Un PRD specifico con flussi utente, casi limite e una gerarchia chiara produce design utili. Non è un limite dello strumento. È un limite di pensiero.
Hai ancora bisogno di gusto. Lo strumento produce. Tu dirigi. Scegliere la variante giusta e raffinarla è dove vive il tuo giudizio. Se salti lo step di curation, torni al vibe-design.
Alcuni componenti hanno bisogno di aggiustamenti manuali. Stati animati complessi, pattern di interazione personalizzati, qualsiasi cosa al di fuori del sistema di design ha bisogno di un passaggio manuale in Codex. L'MCP ti porta al 90%. L'ultimo 10% è il tuo gusto.
Cosa Significa Veramente
Ecco la mia opinione onesta.
Il collo di bottiglia nella distribuzione di prodotti costruiti con l'AI non è mai stato il codice. L'AI sa scrivere codice. Il collo di bottiglia è sempre stato lo strato di design. La coerenza, il gusto, il sistema che tiene tutto insieme.
Quel collo di bottiglia è appena crollato.
Nella nostra agenzia una volta preventivavamo due settimane per il design su ogni MVP cliente. Assumere un designer. Aspettare i file Figma. Guardare lo sviluppatore interpretare. Ciclo. Quello che una volta richiedeva due settimane ora richiede due giorni. Stessa qualità. Consegna più veloce. Margine più alto.
Questo è il flusso di lavoro che i team finanziati hanno già con i loro pipeline Figma + designer + sviluppatore. La differenza è che ora gli sviluppatori solitari, le agenzie indie e i piccoli studi ottengono la stessa leva senza dover assumere personale.
Il 2026 sarà DA PAURA per le agenzie e gli sviluppatori che lo capiscono per primi.
TLDR
→ Smetti di incolpare Codex per una UI brutta. Codex non è il problema. Il tuo flusso di lavoro lo è.
→ Step 1: Costruisci il tuo sistema di design all'interno di Moonchild. Importa da Figma, GitHub o un URL live. Oppure descrivi il tuo brand. Oppure inserisci ispirazione da Dribbble come ho fatto io per Haven.
→ Step 2: Incolla il tuo PRD. Fai brainstorming in modalità chat prima di generare. Blocca prima l'elenco schermate e il pattern di navigazione.
→ Default genera una variante. Chiedi esplicitamente varianti multiple sulle schermate hero con vibe differenti specificati.
→ Usa l'anteprima interattiva per testare il flusso prima che venga scritto qualsiasi codice. Raffina le schermate con iterazioni v2, v3 al loro posto.
→ Step 3: Collega Moonchild a Codex tramite MCP. Questo dà a Codex dati di design reali, non screenshot.
→ Step 4: Fai un prompt a Codex per costruire ogni schermata usando l'MCP. UI di livello produzione viene distribuita in pochi minuti.
→ La qualità del tuo sistema di design determina la qualità dell'output. Investi lì.
→ Il ciclo da Figma a handoff a sviluppatore è morto. Un unico flusso di lavoro ora gestisce design e codice insieme.
ANDIAMO.
