エージェントビルドループで Slack スタイル UI を設計する

最近の一つのプロジェクトを、5時間の使用制限と GPT-5.5 で制約された単一の Codex セッションで Slack スタイル UI をリビルドして完了した。

重要だったのは制限自体ではなかった。それはシーケンスだった：

1. プレースホルダーブロックで作られたモック化されたレガシー UI から始める
2. アプリを従来のヘッダー・サイドバー・メインビューレイアウトとして扱う
3. プランニングスキルを使って新しいサイドバーレール・ワークスペースリスト・プライマリビューを設計する
4. 実装に触れる前にビジュアルプランを反復する
5. 形状が十分明確になったら作業を実行させる

レガシーシェル

出発点は意図的にシンプルにした。新しいレイアウトが空白のキャンバスではなく、それと対比して判断できるように、古い構造を明確にしたかった。

つまり馴染みのあるプロダクトのスケルトンを維持することを意味した：

• トップヘッダー
• ナビゲーションサイドバー
• プライマリコンテンツビュー

そこから問いは「モデルは UI を生成できるか？」ではなかった。「デザインの意図がすでに明示的であれば、モデルは正しい UI を構築できるか？」だった。

コードの前にプランニング

実装の前に、Superpowers ワークフローを使ってビジュアルプランニングのパスを通った。

これにより、最初のパスが通常ドリフトする詳細を定める助けになった：

• サイドバーレールがワークスペースリストをどうフレームするか
• ワークスペースリストがどれだけ密に感じるべきか
• メインビューが構造とコンテンツスペースをどうバランスさせるか
• どの部分が意図的に見えるべきで、どれがプレースホルダーのように見えるか

このステップはコード生成自体よりも重要だった。プランが強ければ強いほど、実装の推測が少なくなった。

最初の出力

最初の出力は有用なほど良かった。

全体的な方向性を捉えていたが、特にタブとボタンがきれいに揃っていないところで、まだ小さな UI の問題があった。これは最初の実行で排除するのが難しい部分だ。たとえ大きなレイアウトが正しくても。

その最初のラウンドを10点中7点と評価する。

反復後

いくつかの調整の後、インターフェースは欲しかった UI 機能のほとんどに達した。

その時点で、作業は10点中8点に近い感じになった：形状は正しく、インタラクションサーフェスは読みやすく、プランはほぼ一貫したインターフェースに変換されていた。

それはレビューの次の層に移るのに十分だった。

なぜシステムに属するか

教訓は、ワンショット生成が十分だということではない。

教訓は、インターフェース設計をシステムサーフェスの一部として扱えるということだ：

• まずレイアウトをプランする
• 構造を明示的にする
• 最初のパスにはまだクリーンアップが必要だと受け入れる
• 次の反復を使って「動く」と「よく設計されている」のギャップを縮める

これがこのサイトが保存したいエンジニアリングの判断の種類だ。