記事一覧へ
Codex + あるシークレットツールの組み合わせが、私たちのエージェンシーで稼働しているデザインワークフローです。そしてその出力は、本当に別次元のレベルにあります。
何ヶ月もこう言い続けてきました。あなたのアプリがAIスロップに見えるなら、それはCodexの問題ではありません。ワークフローの問題です。
ほとんどのビルダーは同じループにはまっています。AIで機能をリリースする。バックエンドは動く。ロジックはしっかりしている。でもインターフェースは、他のすべてのバイブコーディングアプリと変わらない見た目をしている。ユーザーはわずか2秒で、それが本物かどうかを判断します。
従来の解決策はデザイナーを雇うことでした。Figmaファイルを何週間も待って、それからデベロッパーがそのデザインを解釈してコードに落とし込むのを見守る。デザインが本番に出る頃には、モメンタムを失い、不要なキャッシュを燃やしていました。
そのプロセス全体が、今や任意選択になりました。
このウォークスルーでは、不動産モバイルアプリのコンセプト「Haven」を構築しました。20分でフルデザインシステム。1時間以内にすべての画面をデザイン。CSSを1行も書き直すことなく、Codex経由でプロダクションコードをリリース。
これが私が今稼働させているワークフローです。AIでリリースするすべてのビルダーが、この仕組みを理解する必要があります。
左側でMoonchildがUIをデザインし、右側でCodexがそれを動くモバイルアプリに変換しています。
## Moonchildとは何か
シークレットツールはMoonchildです。
この1年間に登場したほぼすべてのAIデザインツールをテストしました。ほとんどは最初の画面では良く見えますが、2ページ目を構築した瞬間に崩壊します。一貫性が問題です。Moonchildは、他のどのツールとも異なる方法でそれを解決します。
これはあなたのデザインシステムから始まる、チャット駆動のデザインキャンバスです。空白のプロンプトからではありません。スクリーンショットからでもありません。あなたの実際のシステムから始まります。システムを3つの方法で持ち込めます：
→ Figma、GitHub、またはライブURLからインポート
→ Agentic Design System Builderにブランドを説明
→ DribbbleやどこかからデザインインスピレーションをドロップIn
そのシステムが入ったら、昔のやり方でデザインをプロンプトしません。PRDを貼り付けます。それがシステムに対してフル画面を生成します。そこからアートディレクトします。
そしてエクスポートパスがループを閉じます。MoonchildはMCPコネクターを出荷しており、デザインをCodexに直接構造化出力として渡します。Codexが解釈するスクリーンショットではありません。実際のデザインデータ。コンポーネント、トークン、レイアウト、すべてです。
それがワークフローです。では実際の使い方を説明します。
コードが1行も書かれる前に、Moonchild内でデザインされたHaven（不動産モバイルアプリ）の全UI。
## ほとんどのビルダーがAIデザインを使う方法の問題
ほとんどのビルダーがやることはこうです。
Codexに新機能を構築するようプロンプトします。リリースされます。まあまあな見た目。次の機能をプロンプトします。微妙に違う見た目。5番目の機能までに、アプリは5つの異なるプロダクトを縫い合わせたように見えます。
これが人々が「AIデザインは悪い」と言う意味です。
モデルが悪いのではありません。ワークフローが悪いのです。
Codexはあなたのデザイン言語が何かを知りません。すべてのプロンプトは新鮮なコンテキストです。すべての画面は推測です。すべてのコンポーネントが前のものからドリフトします。色がシフトします。タイポグラフィがシフトします。すべてが複合します。
修正はシンプルです。Codexに従うべきシステムを与えます。そして実際に構築すべきデザインを与えます。
ほとんどのワークフローはどちらか一方を与えます。Moonchild + MCPコネクションが両方を同時に与えます。
## ステップ1：まずデザインシステムを構築する。常に。
これはみんながスキップするステップです。そして最も重要でもあります。
@ignytlabsでは、画面に触れる前に、すべてのクライアントのデザインシステムを構築します。これはかつてデザイナーが2日かけていました。Moonchildは約20分でやります。
このウォークスルーでは、不動産モバイルアプリのコンセプト「Haven」を構築しました。Moonchildにデザインシステムを入れる方法はいくつかあります。Figma、GitHub、またはライブURLからインポートできます。Agentic Design System Builderにブランドを説明できます。Havenでは、バイブから始めるときに通常やることをしました。Dribbbleからデザインインスピレーション。目指していた感覚を完璧に捉えたモバイル不動産アプリの3枚のスクリーンショットと、Havenが何であり誰のためのものかの短い説明をドロップしました。ツールがデザイン言語を抽出し、スクラッチからシステムを構築しました。
驚いたのは、すべてがどれほどプレビュー可能かということです。私の最後の記事で書いたGoogle Stitchワークフローを含む、ほとんどのAIツールは、フラットなトークンファイルを渡します。色。フォント。たぶんスペーシング。これは違うことをします。フルコンポーネントライブラリとギャラリーを構築します。すべてのバッジ、ボタン、カード、チップが、実際にアプリ内で見える方法でレンダリングされます。任意のコンポーネントをクリックするとライブで表示され、バリアントとサイズをテストするためのコントロールがあります。プレビューのすぐ下に、そのコンポーネントの実際のJavaScript、CSS、例、依存関係があります。コードベースに引き込む準備ができています。
ギャラリーは、デザインの仕方を本当に変える部分です。コンテキスト内で「ブランドバッジ」や「レーティングバッジ」がどのように見えるかを推測する代わりに、すべてを並べて見ます。For Sale。For Rent。Featured。家族全員が一度に。1つの画面が生成される前に、インフォームドなデザイン決定をします。
それはスタイルシートと本物のシステムの違いです。
Havenの詳細なデザインシステム。これは通常、アプリUI全体を左右する部分です。
## ステップ2：PRDからUIへ
デザインシステムが入ったら、昔のやり方でデザインをプロンプトしません。
PRDを貼り付けます。
1ページの機能ブリーフ。プロダクトスペック。目標ステートメント。何でも持っているものを。
Havenでは、プロダクト紹介、目標、ターゲットユーザーと役割、主要機能とMVPスコープ、完全なユーザージャーニー、技術スタック、デザインの方向性をカバーする構造化されたPRDを貼り付けました。約1ページ。ツールに本物のコンテキストを与えるのに十分な具体性。適切なディテールを適切な画面に引き込むのに十分な構造性。
それから、ほとんどの人がスキップすることをしました。
1つの画面を生成する前に、ツールとブレインストーミングしました。
これはほとんどのビルダーが見逃すアンロックです。チャットモードはフルPRDコンテキストを保持します。PRDをダンプして生成を押す代わりに、まずプロダクトについて話し合います。画面リストを確認します。ナビゲーションパターンをロックします。ピクセルが存在する前に主要画面の階層を事前定義します。
Havenでは以下を聞きました：
→「このPRDに基づいて、最初に構築することを推奨する画面は？不動産アプリで欠けているものは？」
→「プライマリナビゲーションは、ホーム、検索、お気に入り、プロフィールのボトムタブにすべき？それとも別のもの？」
→「生成前に、物件詳細画面の優先順位を通してください。写真、次に名前と価格、次に仕様、次にアメニティ、次にエージェント。確認または改善してください。」
→「了解、それではこれらの画面をライトモードとダークモードの両方で生成し、現在添付しているデザインシステムに従ってください。完全なユーザージャーニーを完了し、すべての画面を作成してください。」
生成ボタンを押す頃には、ツールはほとんどのデザイナーが最初のクライアントコール後に把握するよりもプロダクトをよく知っていました。
バリアントについて簡単なメモがあります。よく読んでください。
クールな機能：画面のさまざまなバリアントを作成できます。Moonchildに明示的に言うだけで、それが対応してくれます。Havenでは、1つにコミットする前に、アプリ全体の3つの異なる美的方向性が欲しかったです。使った正確なプロンプトは以下です：
「Havenの3つの完全なモバイルUIデザインコンセプトを生成してほしい：
コンセプト1 - ウォームエディトリアル：クリームの背景、ゆとりあるスペーシング、物件名にセリフ見出し、ソフトシャドウ、マガジンスタイルの画像処理。
コンセプト2 - ボールドモダン：ダークモード、高コントラスト、全体的にサンセリフ、シャープな角、エッジツーエッジ画像でフォト主導。
コンセプト3 - プレミアムミニマル：ニュートラルパレット（オフホワイト、チャコール、単一アクセント）、洗練されたタイポグラフィ、多くの余白、繊細なマイクロインタラクション。
各コンセプトの基盤として接続されたデザインシステムを使用するが、それぞれのコンセプトがシステムを異なる美的方向に引っ張るようにする。セクションだけでなく、フル画面を生成する。どうする？」
最後の「どうする？」に注目してください。これが機能させる小さなディテールです。盲目的に何もかも生成する代わりに、ツールはプランを返してきました。
コンセプトごとに5つの代表的な画面を最初に構築すると言いました。3つの方向性を並べてレビューします。選んだものが決まったら、その方向性でアプリ全体をデザインしに行きます。
それがコスト方程式を完全に変えます。3つのフルビルドにお金を払うのではありません。3つのクイックサンプラーにお金を払い、それから実際に選んだ方向性で1つのフルビルドをします。
ウォームエディトリアルを選びました。次のフルセットの画面が返ってきました。
Moonchildは、すべての画面でライトモードとダークモードのバージョンを含む、Haven UI全体を一度に生成しました。
3つの別々のコンセプトから生成された3つの異なるUIバリアント。好みの方向性を選び、MoonchildにそれをベースとしてAppの残りの画面を生成させます。
本当に驚いたことがあります。
Moonchildが生成するすべての画面は、プレビューモードでインタラクティブです。静的なモックアップではありません。本当にインタラクティブです。
入力フィールドにクリックして入れます。ボタンをタップします。コードが書かれる前に本物のユーザーとしてプロトタイプをテストするように、画面間を移動します。Havenでは、プレビューで2つのフローの問題を発見しました。Codexに渡さなければリリースしていたでしょう。物件詳細画面に、閲覧に戻る明確な方法がありませんでした。コンタクトエージェントのCTAがフォールドの下にありすぎました。クリックスルーせずにデザインをCodexに渡していたら、両方ともリリースされていたでしょう。
それがアンロックです。コードが書かれる前にプロダクトをテストします。
Havenの物件画面でのインタラクティブプレビューモードの動作
リファインメントループが最後のピースです。
画面に修正が必要なとき、スクラッチから再プロンプトしません。画面を選択して、変えたいことをツールに伝えると、その場でv2を生成します。より映画的なヒーローが欲しい？v2。カードレイアウトをリストビューに入れ替えたい？v3。バリアントが積み重なって、比較して最強なものを選べます。
Havenの物件詳細画面では3回のイテレーションを経ました。v1はエージェントブロックが高すぎました。v2は階層を修正しましたが、写真ギャラリーが小さく感じました。v3は両方を完璧にしました。約8分の往復です。
空白のスレートからキュレーションするのではありません。本物の方向性をリファインしています。これが上級デザイナーと働くことに最も近いと感じる部分です。
同じ画面の複数バリエーションが即座に生成されます。正しいと感じるバージョンを見つけるまで方向性をリファインし続けて、それを確定します。
## ステップ3：MCP経由でMoonchildをCodexに接続する
ここでワークフローがCRACKEDになります。
デザインシステムはCodexにルールを与えます。MCPコネクションはCodexにより強力なものを与えます。実際のデザイン出力への直接アクセス。スクリーンショットではありません。テキストによるデザインの説明でもありません。Codexが読んで再構築できる構造化されたデザインデータです。
セットアップはこうです：
→ Moonchild Settingsに行き、MCPを選択
→ セットアップのインストールコマンドをコピー
→ Codex CLIを開く
→ インストールコマンドを貼り付け
→ Moonchildアカウントで認証
→ 完了
接続されると、Codexはデザインシステムと設計した特定のHaven画面の両方を見ます。
Moonchild MCPが接続されていることを示すCodex
## ステップ4：Codexがコードをリリースする
今、Codexに以下のようにプロンプトします：
Moonchild MCPを使ってHaven Real Estate Mobile Appプロジェクトをフェッチして、その中にある画面を全部教えて。
この最初のプロンプトは2つの仕事をします。MCPが正しく接続されていることを確認します。そしてCodexが設計したすべての画面への完全な可視性を与えます。
Codexにより重いことをさせる前のクイックヒント。プランモードを維持してください。Codexは実行前にやろうとしていることを表示します。毎回プランを読んでください。欲しい画面、どの順序で、どの忠実度で、を理解しているか確認してください。これがCodexが実際に必要なものをコーディングするか、Codexが必要だと思うものをコーディングするかの違いです。
プランをレビューして欲しい画面に向けたら、Codexはデザインデータを直接Moonchildから引き込み、デザインシステムを参照して、コードを書きます。プロンプトから推測するのではなく、本物のデザインデータから作業しているので、ホバーステート、トランジション、エッジケースの処理まで追加します。
結果。実際のコードベースにプロダクショングレードのUIが、デザインに正確に合致した形で、数分で。
@ignytlabsでは、以前すべてのクライアントMVPのデザインに2週間の予算を組んでいました。デザイナーがFigmaファイルを構築します。デベロッパーがそれを解釈します。解釈がドリフトします。修正します。サイクル。このワークフローでは、ループ全体が1日の作業に凝縮されます。同じ品質。より高いマージン。コンテキストスイッチングがはるかに少ない。
MoonchildデザインとCodex出力のフル画面録画
## このワークフローをいつ使うか
これはすべてのチームに適したワークフローではありません。いつフィットするかについて正直に考えてください。
以下の場合に使ってください：
→ ソロビルダーまたは小チームとしてMVPをリリースしている
→ 画面間でデザインの一貫性が崩れ続けている
→ 別個のFigmaからデザイナーからデベロッパーへのパイプラインを維持したくない
→ すでにデザインシステムがあり、それをどこでも適用したい
以下の場合はスキップしてください：
→ フルインハウスデザインチームと成熟したFigmaライブラリを持つスケール状態にある
→ すべてのシャドウが重要なマーケティングサイトやブランドワークのためにピクセルパーフェクトなハンドオフが必要
→ コードベースにビスポークデザイン作業が必要な高度なカスタムUIパターンがある
MVPとSaaSプロダクトをリリースするビルダーの80%について、このワークフローは必要なすべてをカバーします。
## 注意すべき点
これを実行する前にいくつかの正直なフラグを立てておきます。
あなたのデザインシステムの品質が出力の品質を決めます。ゴミを入れれば、ゴミが出ます。3つの色トークンしかない半分未完成のFigmaファイルは、平凡な画面を生成します。最初にシステムに時間を投資してください。すべての画面で報われます。
PRDの品質が重要です。漠然としたブリーフでは汎用的な画面になります。ユーザーフロー、エッジケース、明確な階層を持つ具体的なPRDが、有用なデザインをもたらします。これはツールの制限ではありません。思考の制限です。
まだセンスが必要です。ツールが生成します。あなたが方向性を決めます。正しいバリアントを選んでリファインすることが、あなたの判断が活きる場所です。キュレーションのステップをスキップすると、またバイブデザインに戻ります。
一部のコンポーネントは手動の調整が必要です。複雑なアニメーションステート、カスタムインタラクションパターン、デザインシステム外のものは、Codexで手動パスが必要です。MCPが90%まで連れて行きます。残りの10%はあなたのセンスです。
## これが実際に意味すること
私の正直な見解です。
AIで構築されたプロダクトをリリースする際のボトルネックは、コードではありませんでした。AIはコードを書けます。ボトルネックは常にデザイン層にありました。一貫性、センス、すべてをまとめるシステム。
そのボトルネックが今崩壊しました。
私たちのエージェンシーでは、以前すべてのクライアントMVPのデザインに2週間の予算を組んでいました。デザイナーを雇います。Figmaファイルを待ちます。デベロッパーがそれを解釈するのを見守ります。サイクル。2週間かかっていたものが今では2日になりました。同じ品質。より速い納品。より高いマージン。
これはFigmaとデザイナーとデベロッパーのパイプラインを持つ資金調達済みチームがすでに持っているワークフローです。違いは、ソロビルダー、インディーエージェンシー、小スタジオが今や人員なしで同じレバレッジを得られることです。
2026年は、これを最初に理解したエージェンシーとビルダーにとってUNFAIRになるでしょう。
## TLDR
→ 悪いUIのためにCodexを責めるのをやめる。Codexは問題ではありません。あなたのワークフローが問題です。
→ ステップ1：Moonchild内でデザインシステムを構築する。Figma、GitHub、またはライブURLからインポート。ブランドを説明する。またはHavenでしたように、Dribbbleインスピレーションをドロップする。
→ ステップ2：PRDを貼り付ける。生成前にチャットモードでブレインストーミングする。まず画面リストとナビゲーションパターンをロックする。
→ デフォルトは1つのバリアントを生成する。ヒーロー画面で異なるバイブを指定して複数バリアントを明示的に求める。
→ コードが書かれる前にフローをテストするためにインタラクティブプレビューを使う。v2、v3のイテレーションで画面をその場でリファインする。
→ ステップ3：MCP経由でMoonchildをCodexに接続する。これによりCodexにスクリーンショットではなく実際のデザインデータが渡される。
→ ステップ4：MCPを使って各画面を構築するようCodexにプロンプトする。プロダクショングレードのUIが数分でリリースされる。
→ あなたのデザインシステムの品質が出力の品質を決める。そこに投資する。
→ Figmaからハンドオフからデベロッパーへのサイクルは死んだ。1つのワークフローが今やデザインとコードを一緒に動かす。
LFG。
design-workflowcodexmcpclaude-workflowagent-ops
CodexはデザインでCRACKED。実際に機能するワークフローを公開
♥ 10
原文を表示 / Show original
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.
What Moonchild Actually Is
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.
The Problem With How Most Builders Use AI for Design
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.
Step 1: Build Your Design System First. Always.
This is the step everyone skips. It is also the most important.
At @ignytlabs 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.
Step 2: PRD to UI
Once your design system is in, you don't prompt for designs the old way.
You paste a PRD.
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.
For Haven I asked:
→ "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.
Step 3: Connect Moonchild to Codex via MCP
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.
Here's the setup:
→ Go to Moonchild Settings, then MCP
→ Copy the install command for your setup
→ Open Codex CLI
→ Paste the install command
→ Authenticate with your Moonchild account
→ Done
Once connected, Codex sees both your design system and the specific Haven screens you've designed.
Codex showing the Moonchild MCP as connected
Step 4: Codex Ships the Code
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.
At @ignytlabs 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
When to Use This Workflow
This isn't the right workflow for every team. Be honest about when it fits.
Use it when:
→ 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
Skip it when:
→ 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.
What to Watch Out For
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.
What This Actually Means
Here's my honest take.
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.
TLDR
→ 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.
LFG.