Codex + one secret tool is the design workflow we've been running at our agency... and the output is genuinely on a different level.
I've been saying this for months. If your app looks like AI slop, that's not a Codex problem. That's a workflow problem.
Most builders are stuck in the same loop. They ship features with AI. The backend works. The logic is solid. But the interface looks like every other vibe coded app. Users decide in two seconds whether it feels real.
The old fix was to hire a designer. Wait weeks for Figma files. Then watch your developer interpret those designs and rebuild them in code. By the time the design was live, you had lost momentum and burned cash you did not need to burn.
That entire process is now optional.
For this walkthrough I built Haven, a real estate mobile app concept. Full design system in 20 minutes. Every screen designed in under an hour. Production code shipped through Codex without rewriting a single line of CSS.
This is the workflow I am running now. And every builder shipping with AI needs to understand how it works.
Moonchild on the left designing the UI. Codex on the right turning it into a working mobile app.
The secret tool is Moonchild.
I've tested almost every AI design tool that's launched in the past year. Most look decent on the first screen, then fall apart the moment you build a second page. Consistency is the problem. Moonchild solves it in a way nothing else has.
It is a chat-powered design canvas that starts from your design system. Not from a blank prompt. Not from a screenshot. From your actual system. You bring your system in three ways:
→ Import from Figma, GitHub, or a live URL
→ Describe your brand to its Agentic Design System Builder
→ Drop in design inspiration from Dribbble or anywhere else
Once that system is in, you don't prompt for designs the old way. You paste a PRD. It generates full screens against your system. You art direct from there.
And the export path is what closes the loop. Moonchild ships an MCP connector that hands your designs directly into Codex as structured output. Not a screenshot for Codex to interpret. The actual design data. Components, tokens, layout, everything.
That is the workflow. Now here's how to actually use it.
Entire UI of Haven, my real estate mobile app, designed inside Moonchild before a single line of code was written.
Here's what most builders do.
They prompt Codex to build a new feature. It ships. Looks okay. Then they prompt the next feature. Looks slightly different. By the fifth feature the app looks like five different products stitched together.
This is what people mean when they say AI design is bad.
The model isn't bad. The workflow is.
Codex has no idea what your design language is. Every prompt is a fresh context. Every screen is a guess. Every component drifts from the last one. The colors shift. The typography shifts. Everything compounds.
The fix is simple. Give Codex a system to follow. Then give it the actual design to build.
Most workflows give it one or the other. Moonchild plus the MCP connection gives it both at the same time.
This is the step everyone skips. It is also the most important.
we build a design system for every single client before we touch a screen. This used to take a designer two days. Moonchild does it in about 20 minutes.
For this walkthrough I built Haven, a real estate mobile app concept. There are a few ways to get a design system into Moonchild. You can import from Figma, GitHub, or a live URL. You can describe your brand to the Agentic Design System Builder. For Haven I did what I usually do when I am starting from a vibe. Design inspiration from Dribbble. I dropped in three screenshots of mobile real estate apps that nailed the feel I was going for and a short description of what Haven is and who it is for. The tool extracted the design language and built the system from scratch.
What surprised me is how previewable everything is. Most AI tools, including the Google Stitch workflow I wrote about in my last article, hand you a flat token file. Colors. Fonts. Maybe spacing. This does something different. It builds a full component library and a gallery. Every badge, button, card, and chip rendered the way it will actually look inside your app. Click any component and you see it live, with controls to test variants and sizes. Right below the preview you get the actual JavaScript, CSS, examples, and dependencies for that component. Ready to pull into the codebase.
The gallery is the part that genuinely changes how you design. Instead of guessing what a "brand badge" or "rating badge" should look like in context, you see them all side by side. For Sale. For Rent. Featured. The whole family at once. You make informed design decisions before a single screen gets generated.
It is the difference between a style sheet and a real system.
Detailed design system for Haven. This is the part that usually makes or breaks the entire app UI.
Once your design system is in, you don't prompt for designs the old way.
A one-page feature brief. A product spec. A goal statement. Whatever you have.
For Haven I pasted a structured PRD covering the product introduction, the objectives, the target users and roles, the key features and the MVP scope, the full user journeys, the technical stack, and the design direction. Around one page. Specific enough to give the tool real context. Structured enough that it pulls the right details into the right screens.
Then I did something most people skip.
I brainstormed with it before generating a single screen.
This is the unlock most builders miss. The chat mode holds the full PRD context. Instead of dumping the PRD and hitting generate, you talk through the product first. Confirm the screen list. Lock the navigation pattern. Pre-define the hierarchy of key screens before any pixels exist.
→ "Based on this PRD, what screens do you recommend we build first? Anything I'm missing for a real estate app?"
→ "Should the primary navigation be a bottom tab with Home, Search, Favorites, Profile? Or something different?"
→ "Before generating, walk me through the priority order for the Property Detail screen. Photos first, then name and price, then specs, then amenities, then agent. Confirm or improve."
→ "Ok, now please proceed and generate these screens in both light as well as the dark mode while sticking to the design system that I currently have attached. Make sure you complete the entire user journey and create all of the screens. "
By the time I hit generate, the tool already knew the product better than most designers would after their first client call.
Now a quick note on variants. Read this carefully.
One cool feature: you can create different variants of your screens. You just have to explicitly mention it to Moonchild and it will take care of it. For Haven I wanted three different aesthetic directions for the whole app before I committed to one. Here's the exact prompt I used:
“I want you to generate 3 complete mobile UI design concepts for Haven:
Concept 1 - Warm Editorial: Cream backgrounds, generous spacing, serif headlines for property names, soft shadows, magazine-style image treatment.
Concept 2 - Bold Modern: Dark mode, high contrast, sans-serif throughout, sharp corners, photo-led with edge-to-edge images.
Concept 3 - Premium Minimal: Neutral palette (off-white, charcoal, single accent), refined typography, lots of breathing room, subtle micro-interactions.
Use the connected design system as the foundation but let each concept pull the system in a different aesthetic direction. Generate full screens, not just sections. What will you do?”
Notice the "What will you do?" at the end. That's the small detail that makes this work. Instead of just generating everything blindly, the tool came back with a plan.
It said it would build 5 representative screens per concept first. I would review the three directions side by side. Once I picked the one I wanted, it would go and design the entire app in that direction.
That changes the cost equation completely. You're not paying for three full builds. You're paying for three quick samplers, then a single full build in the direction you actually pick.
I picked the warm editorial one. The full set of screens came back next.
Moonchild generated the entire Haven UI in one go, including both light and dark mode versions across every screen.
Three different UI variants generated from three separate concepts. Pick the direction you like, then have Moonchild generate the rest of the screens around it.
Now the part that genuinely surprised me.
Every screen Moonchild generates is interactive in preview mode. Not a static mockup. Actually interactive.
You can click into input fields. Tap buttons. Move between screens like a real user testing the prototype before any code is written. For Haven I caught two flow issues in preview that would have shipped to Codex otherwise. The property detail screen had no obvious way back to browse. The contact agent CTA was too far below the fold. Both would have shipped if I had handed the design to Codex without clicking through first.
That is the unlock. You test the product before any code gets written.
Interactive preview mode in action on the Haven properties screen
The refinement loop is the last piece.
When a screen needs work, you don't re-prompt from scratch. You select the screen, tell the tool what to change, and it generates a v2 in place. Want a more cinematic hero? v2. Want to swap a card layout for a list view? v3. The variants stack so you can compare and pick the strongest.
For Haven's property detail screen I went through three iterations. v1 had the agent block too high. v2 fixed the hierarchy but the photo gallery felt small. v3 nailed both. About 8 minutes of back-and-forth.
You're not curating from a blank slate. You're refining a real direction. This is the part that feels closest to working with a senior designer.
Multiple variations of the same screen generated instantly. Keep refining the direction until you find the version that feels right, then finalize it.
This is where the workflow gets CRACKED.
The design system gives Codex the rules. The MCP connection gives Codex something more powerful. Direct access to the actual design output. Not screenshots. Not text descriptions of the design. Structured design data Codex can read and rebuild.
→ Go to Moonchild Settings, then MCP
→ Copy the install command for your setup
→ Paste the install command
→ Authenticate with your Moonchild account
Once connected, Codex sees both your design system and the specific Haven screens you've designed.
Codex showing the Moonchild MCP as connected
Now you prompt Codex like this:
Fetch the Haven Real Estate Mobile App project using the Moonchild MCP, and let me know what all screens we have inside it.
This first prompt does two jobs. It confirms the MCP is wired up correctly. And it gives Codex full visibility into every screen you've designed.
A quick tip before you let Codex do anything heavier. Stay in plan mode. Codex surfaces what it's about to do before executing. Read the plan every time. Make sure it understands which screens you want, in what order, and at what fidelity. This is the difference between Codex coding what you actually need and Codex coding what it thinks you need.
Once you've reviewed the plan and pointed it at the screen you want, Codex pulls the design data straight from Moonchild, references your design system, and writes the code. It even adds the hover states, transitions, and edge-case handling because it's working from real design data instead of guessing from a prompt.
The result. Production-grade UI in your actual codebase, matching the design exactly, in minutes.
we used to budget two weeks for design across every client MVP. A designer would build the Figma file. A developer would interpret it. The interpretation would drift. We'd correct. Cycle. With this workflow the entire loop collapses into a single afternoon of work. Same quality. Higher margin. Way less context switching.
Full screen recording of the moonchild design + codex output
This isn't the right workflow for every team. Be honest about when it fits.
→ You're shipping MVPs as a solo builder or small team
→ Design consistency keeps breaking across screens
→ You don't want to maintain a separate Figma to designer to developer pipeline
→ You already have a design system and want it enforced everywhere
→ You're at scale with a full in-house design team and a mature Figma library
→ You need pixel-perfect handoff for a marketing site or brand work where every shadow matters
→ Your codebase has highly custom UI patterns that need bespoke design work
For 80% of builders shipping MVPs and SaaS products, this workflow covers everything you need.
A few honest flags before you run this.
Your design system quality determines your output quality. Garbage in, garbage out. A half-finished Figma file with three color tokens will produce mediocre screens. Spend time on the system upfront. It pays back across every screen.
PRD quality matters. A vague brief gets you generic screens. A specific PRD with user flows, edge cases, and clear hierarchy gets you useful designs. This isn't a tool limitation. It's a thinking limitation.
You still need taste. The tool produces. You direct. Picking the right variant and refining it is where your judgment lives. If you skip the curation step, you're back to vibe-designing.
Some components need manual nudging. Complex animated states, custom interaction patterns, anything outside the design system needs a manual pass in Codex. The MCP gets you 90% there. The last 10% is your taste.
The bottleneck in shipping AI-built products has never been the code. AI can write the code. The bottleneck has always been the design layer. The consistency, the taste, the system that ties everything together.
That bottleneck just collapsed.
At our agency we used to budget two weeks for design across every client MVP. Hire a designer. Wait on Figma files. Watch the developer interpret it. Cycle. What used to take two weeks now takes two days. Same quality. Faster delivery. Higher margin.
This is the workflow funded teams already have with their Figma plus designer plus developer pipelines. The difference is now solo builders, indie agencies, and small studios get the same leverage without the headcount.
2026 is going to be UNFAIR for agencies and builders who figure this out first.
→ Stop blaming Codex for bad UI. Codex isn't the problem. Your workflow is.
→ Step 1: Build your design system inside Moonchild. Import from Figma, GitHub, or a live URL. Or describe your brand. Or drop in Dribbble inspiration like I did for Haven.
→ Step 2: Paste your PRD. Brainstorm in chat mode before generating. Lock the screen list and navigation pattern first.
→ Default generates one variant. Ask explicitly for multiple variants on hero screens with different vibes specified.
→ Use interactive preview to test the flow before any code gets written. Refine screens with v2, v3 iterations in place.
→ Step 3: Connect Moonchild to Codex via MCP. This gives Codex real design data, not screenshots.
→ Step 4: Prompt Codex to build each screen using the MCP. Production-grade UI ships in minutes.
→ Your design system quality determines your output quality. Invest there.
→ The Figma to handoff to developer cycle is dead. One workflow now runs design and code together.