最近Codex CLIも盛り上がってきたので、同じプロンプトを投げてどっちがいいか検証していく

 Notion的な編集可能なサイドバーを作らせるdocusaurusuのコレを編集可能にするプラグインをつくりたい。

 プロンプト@src/theme/DocSidebar/Desktop/EditableSidebar.tsx
ここに実装を追加したいです。具体的には、github側のファイルシステムを参照し、現在のディレクトリ構造を編集できるようにしたいです。編集自体も、ディレクトリとファイルに分かれ、ファイルの追加、削除、移動ができるようにしてください。ultrathinkしてください。  

 Claude特に指示していないが、ログイン要求をしてきた。

まだこのフェーズに入りたいわけではなかったのだが、いずれやることだったのでよしとする。
肝心な実装についてはできていなかった。

ファイルがあるはずなのに無いと言ったり、サイドバーのどこを選択するかで表示するディレクトリを換えているように見えた。

スタイリングはされていた。
メインとなるEditableSidebar.tsxは+300行位していたので良い設計とは言えないが、それでも適切な場所に適切な処理を書いているように見えた。

 CodexClaudeとは違い、意図したものが出してきた。

ただスタイリングはしていない模様。

また、全ての処理を1ファイルに書いてきた。

意図通りの実装はできたものの、設計観点ではダメだった。

 総評意図したコードを書く分、codexの方が良いように思う。

特にAI主体のコーディングでは意図した処理を機能を追加するのに手間がかかるので、いったん機能ができればあとはファイル分割させてリファクタさせればすむ。
最初からスタイリングをしていないのも、そこまでマイナスではない。後からどうとでもうなる。
最初から意図した機能ができているという観点で、今回の勝負はcodexの勝利とする。

sakastudio

 編集システムの統合現在サイドバーと単一ファイルの編集が別管理なので、統合して管理するようにしたい。

 プロンプトプロンプト1 関連ファイルの探索
@src/theme/DocSidebar/Desktop/EditableSidebar/ 　@src/components/InlineEditor/ 関連のファイルを読み込んでください。
プロンプト2 実際の作業依頼
ありがとうございます。現在、これら2つのシステムは編集のステートが別々で管理されており、これは適切な状態とは言えません。
正しくは、一つのファイルシステムの状態を保持し、一つのファイルシステムとして管理すべきです。その統合のため、一つの状態コンテキストを作成してください。そして、サイドバーで選択したファイルを編集できるようにしてください。
また、多数のファイル内の変更、ファイルの移動、削除、追加を管理してください。また、このファイルの移動、追加、削除を行った歳は、サイドバー荷もその更新が適用されるようにしてください。

つまり、現在はDraftのデータと実施の編集UIコンポーネントは近い関係にありました。これを切り離し、編集UIは特定のインメモリファイルシステムが渡され、それを表示、編集するだけの機能にしてください。そして、セーブボタンを押したときに、そのインメモリファイルシステムをPRとして作成するようにしてください。

スタイリングは行わないでください。スタイリングは後からできます。現在はtsx、tsファイルの編集に集中し、まずはロジックを作り上げてください。

 Claude実装をぶち壊して何もできなくしました。

実装量はそこそこ
まぁ一発でうまくいくものができるとは思ってないので修正させる
修正させた後

ぱっと見動くように見えるが、ファイルを選択しても表示が変更されなかったり、割りとバグがあるように見える。

いろいろバグを直すか、また作り直すか。とりあえずこのままでは無理そうではある。

まぁこんなものだろうか。

 Codex一発出使えるものが出てきた。

多少うまくいかなかったり、エラー出たりするバグはあれど、基本動作は完璧に動いている。

素晴らしい。正直びびり散らかした。

Claudeもできなかったし、規模も大きめの変更だから厳しいかなぁ〜とかおもってたけど、ほぼ完璧にこなした。

 総評Cluadeが動作確認しながら実装してもうまくいかなかったものを、codexは一発で動作確認なしで仕上げてきた。

ちょっと格が違うかもしれない。

sakastudio

 forkリポジトリの更新ログインしたユーザーがforkリポジトリだった場合は自動で更新するシステムを組ませる。
ログインするとき、リポジトリがforkだった場合は、リポジトリの更新を実行するようにしてください。

 Codex完璧に動作

問題なし。

 Claude動作しなかった。

コードの品質もcodexの方が良さ鵜に見える。

sakastudio

総評

何回か試したが、圧倒的にcodexの方が実装精度が良かった。
今回試したのはweb開発でしかも一つのリポジトリだけだったので、他の環境でどうなるかは分からないが、少なくともClaudeと張り合えるツールだといえる。
もっとツール自体の改善がされれば、完全に乗り換えてもいいかもしれない。

sakastudio

 Unity + C#でのテストコードを記述テストコードを書かせるプロンプト
プロンプトGearPumpのパラメーターのスキーマはこれです。

    public class GearPumpBlockParam  : Mooresmaster.Model.BlocksModule.IBlockParam
    {
        public Mooresmaster.Model.BlocksModule.GenerateFluidElement[] GenerateFluid { get; }
        public float InnerTankCapacity { get; }
        public float RequireTorque { get; }
        public float RequiredRpm { get; }
        public Mooresmaster.Model.FluidInventoryConnectsModule.FluidInventoryConnects FluidInventoryConnectors { get; }
        public Mooresmaster.Model.GearModule.Gear Gear { get; }


    public class GenerateFluidElement 
    {
        public global::System.Guid FluidGuid { get; }
        public float Amount { get; }
        public float GenerateTime { get; }

他のテストコードや実装を参考に、歯車パワーが供給されている間、液体を生成するブロックのテストコードを /Users/sato-katsumi/moorestech/moorestech_server/Assets/Scripts/Tests/CombinedTest/Core/GearPumpTest.cs に書いてください

歯車のエネルギーが足りないときは、必要分のパーセンテージに合わせて、生成量を変動させてください。

 Codex割とよさげなテストコードを書いてくれた。

少し手直しは必要だが、まぁまぁOKって感じ

AGENTS.mdにはMCPでコンパイルエラーをチェックしろと書いてあるが、それはしてくれなかった。

こちらから明示的にチェックしてっていったらやってくれたのでこちらもまぁOK

 Claudeこちらの方が手直しが多いかなぁって印象

悪くはないけど、これを手直しするくらいなら全部書き直したほうが早いかな
結論、codexの方が強いかも

sakastudio

 テストコードを元に実装を行わせる。プロンプトは、テストを実行させた後にこのテストをパスできるようにして、と言うだけ。

 Codexシンプルでよさそうなコードを出してきた。実装を眺めていても問題ないように見える。

 Claudeいろいろと試行錯誤した後、結局良くない実装をしていたと思う。テストの方も改造してパスさせているので、微妙。

テストが妥当なもの出はなかった説はあるが、codexの実装を見る限りは大丈夫そうに見えた。

sakastudio

 Chrome拡張をつくらせるYoutubeの字幕を取得し、それを元に記事を作成、notionページを作成するChrome拡張をつくらせた。

 Codexスタイリングなし、実装も動かなかった

 Claudeスタイリングがされ、不具合がありつつもとりあえず一連の作業波実行できていた

 所感なにもファイルがない状態からプロジェクトを立ち上げ、vibeコーディング的にどんどん機能を追加していく場合はClaude codeの方がいいかもしれない

このスクラップは26日前にクローズされました