OpenAIが開発者向けに新たにリリースしたCursorキラーアプリ「Codex」についての詳細レビューである。従来のCursorやClaude Codeとは一線を画す、エージェント管理に特化した革新的なツールとして紹介されている。複数プロジェクトの並行作業を可能にする独自のワークフロー、CLIとGUIの統合、ワークツリー機能、クラウド環境統合など、実際の開発現場で2週間使い込んだ経験に基づく包括的な評価が展開される。開発者が実際に4000ドルのラップトップを追加購入してまで使い続けたという事実が、その革新性を物語っている。
告白と新たな開発ツールとの出会い
告白があります。過去2週間、私は完全にCursorの使用をやめ、Claude Codeもほとんど使っていません。その理由は、OpenAIが開発者向けにリリースしたばかりの新しいアプリです。その名はCodex。そう、また名前は微妙ですが、製品は本当に、本当に優れているんです。
私が期待していた以上に素晴らしいものでした。実際の作業をしながら複数のプロジェクトにわたってエージェントを管理する、これまでとは異なる方法を提供しています。開発者によって、開発者のために作られたもので、私がこれまで使ってきた類似ツールとは根本的に違う感覚があります。早期アクセスを持っている私の知り合い全員が同じように感じています。
これは正直、私たちの構築方法が根本的なレベルで変わる瞬間の一つだと感じます。最近こういう瞬間が多いのは分かっていますが、このアプリを使うのをやめられないんです。私はNDAの下にいましたが、使い続けたかった。だから、自分でも思ってもみなかったことをしました。2台目のラップトップを買ったんです。
そう、それほど良いんです。Cursorを開いていない自分になったことが、いまだに信じられません。そのラップトップにはインストールすらしませんでした。新しいCodexアプリで構築を続けているだけで、しかも彼らはこれを無料で提供しています。ちなみに、これについて言いたいことがたくさんあります。どのように機能するのか、なぜそんなに気に入っているのか、そしてその周辺で構築してきたクールなワークフローをお見せするのが待ちきれません。
完全に独立したレビューであること
皆さんご存知の通り、OpenAIは私に1セントも支払っていません。実際、早期テスト中の無料モデルアクセスすら提供しなくなりました。ここで行ったすべてのことに、私は自腹を切っています。そして、このアプリは私の投資先の多くと直接競合しています。つまり、想像できる限り最も偏見を持っているはずなのに、これから徹底的に絶賛しようとしているわけです。
ただ、皆さんには知っておいてほしいのですが、今日のスポンサー以外、誰も私にお金を払って何かを話させているわけではありません。見ての通り、最近はかなり多くのものを構築しています。単にコードをたくさん書いているだけでなく、そのコードをサーバー上で構築しているので、ビルドの完了を待たなければなりません。以前は長い時間待たなければなりませんでした、特にRustで構築を始めてからは。
そしてBlacksmithに移行したら、すべての苦痛が消えました。正直に言いますが、これはクールな製品だと思っていて、以前から喜んで推薦していました。でも、その後チームが移行して、つまりチームがセットアップしたんです。セットアップが難しかったわけではありません。GitHubにリンクして1行変更するだけです。
でも今はセットアップされているので、新しいプロジェクトを作ってCIを速くしたいときは、文字通りruns onに行ってubuntu-latestをblacksmithに変更するだけで、突然8倍から10倍速くなるんです。これは、私がRustで書いている新しいCLIアプリの実際のビルドです。ここでのビルドは2分から3分の間です。
運が良ければ、2分を少し切るものもありますが、基本的には2分から3分、時には6分以上かかります。そして今は47秒、46秒、48秒です。長いビルドはパブリッシュなので少し異なります。これは彼らのダッシュボードから見ると、ずっとかっこよく見えます。ちなみに、公式のGitHub Actionsの中で見たものよりも、アクションを追跡するのに格段に優れています。
ワークフローやジョブを簡単にチェックして、本当に素晴らしいUIで何が起こっているかを確認できるだけでなく、機能する検索があります。本当に素晴らしいです。異なるステップでの異なるアクションの成功率と失敗率まで確認できて、何が間違っているのかをデバッグするのがずっと簡単になります。ここでは、ジョブの長さがどのように分散しているかまで確認できます。
Blacksmithによる開発効率の劇的改善
T3 chatでは、ジョブの大半が30秒以内になり、最悪のものでも11分までです。そして、なぜそうなのか、どのステップにどれだけ時間がかかったのかを確認できます。これは本当に素晴らしい。本当に素晴らしいんです。CIについて多くのことを修正しました。開発者たちは格段に幸せになりました。私は大喜びしています。
一度試したら戻れないもののひとつで、だからこそ無料で始められることが驚きなんです。Blacksmithを使っていないなら、時間とお金を無駄にしています。今すぐ両方を修正してください。
それで、Codexとは一体何なのか。CLIです。コーディング用の一連のモデルです。リポジトリにPRを作成するために使用されるウェブアプリです。そして今は、すべての作業を管理するためにMacにインストールできるアプリケーションです。非常にはっきりさせておきたいのは、これはCLIが使用しているのと同じエージェントベースを使用しているということです。
実際、CLIの実行とアプリの実行の間で履歴を共有しています。だから、これらのディレクトリのいずれかでCLIで何かをすれば、アプリにも引き継がれます。設定も同様で、これは本当に便利です。CLIのUIのように感じられますが、日常的な使用、特に多くの異なるプロジェクトやブランチを立ち上げて、同時に複数の異なることに取り組む人にとって、はるかに優れたものにする多くの利便性も処理されています。
今日ほど並列で作業したことはありません。Codexアプリのおかげです。ただ、非常に明確にしておきたいことがあります。彼らが最初にこれをやったわけではありません。複数のプロジェクトで作業していることや、その中で進行中のスレッドを管理しやすくするCLIラッパーがいくつか登場しているのを見てきました。
類似ツールとの比較
Conductorのようなアプリは、主にClaude Codeを中心に構築されていますが、Codexでも動作し、特定のGitリポジトリを取得して、同時に複数のことに取り組むことを容易にします。Conductorは本当にクールですが、私にとってはパフォーマンスの問題がひどく、あまり使っていません。面白いことに、Codex Monitorというものもあります。これは、こういうことをやりたかったCodexのユーザーによって作られたもので、彼も早期テスターとして招かれました。
そして最後にもうひとつ振り返ると、Anti-gravityです。Anti-gravityが直接これをやっているわけではありません。やっていません。でも、実際にやったこと、そして私のビデオでも指摘したのは、エージェントマネージャーでした。これにより、同時に異なるプロジェクトで進行中の作業を追跡できました。
Anti-gravityで最初に遊んだとき、これは実際にかなりクールだと思った唯一のことでした。そして多くの人が、私が間違っていると言いました。特に、私のチャンネルマネージャーのBenが、これについて強く批判しました。そして今、彼も自分が間違っていたと認めています。
つまり、作業スレッドを管理するためのUIというこのオーケストレーションレイヤーは、かなり良いようです。そして、これを頻繁に使って転向しなかった人にまだ会ったことがありません。BenとJuliusを含む私のチーム自体も、このワークフローとこのUIへの移行を進めています。
そして、皆さんにその理由をお見せすべきです。このラップトップには、私のプロジェクトのほんの一部しか入っていません。それでも、ここで多くの本格的な作業をしたことが分かります。Lawnから始めましょう。これは私が取り組んできた10個ほどの新しいアプリのひとつです。これがLawnです。Frame.ioの安価でシンプルな代替品を目指しています。このアプリはもうすぐ完成に近づいています。
実際、来週か再来週にリリースするかもしれません。チームに必要で、望む人がいれば他の人にも提供できることを楽しみにしています。というのも、Frame.ioは最近少し厳しい状況だからです。動画をアップロードしてチームと動画レビューを行う簡単な方法で、多くの動画を扱う私たちには不可欠です。
Lawnアプリの開発プロセス
ご想像の通り、このアプリ全体をCodex内で構築しました。ホームページのようなUI作業については、Claude Codeにあちこち飛びました。そこで多くの追加作業を行いました。しかし、すべての配線、アプリの実際の骨組みの構築、機能の作成、そのすべてが、このアプリ内の多数のスレッドにわたって行われました。
はっきりさせておきますが、このコンピューターではなく、もう一台のラップトップでです。すぐに接続するかもしれませんが、ここで構築しているものの種類を見せたかっただけです。今、コメント内のタイムスタンプをクリックしても、その時点に移動しません。これを修正するように頼みます。ユーザーがコメント内のタイムスタンプをクリックしたら、ビデオプレーヤーは自動的に動画のその時点にスキップする必要があります。
送信すると、作業が始まります。そして、GPT-5モデルについて皆さんご存知の通り、これには少し時間がかかります。一方では、実際に遅いからです。TPSがそれほど高くありません。他方では、非常に徹底しているからです。このモデルは、コードベースをスキャンして、やろうとしていることに関連する可能性のあるすべてのものを見つけ、それをすべて行うための一貫性のある首尾一貫した計画を考え出すのが大好きです。
しかし、ここからが本当にクールなところです。時間がかかることは分かっています。だから、他のことをしに行きましょう。ブログに戻って、いくつかのことに取り組むかもしれません。現在、ブログ投稿の管理方法を見直しているところです。もっと書こうとしているからです。これは予想していなかった変更を加えることになりました。
探索するように頼んだのに、しませんでした。ただコードを書いただけです。でも、何を書いたか見たければ、VS Codeで開くボタンをクリックするだけです。ちなみに、使いたい可能性のあるほぼすべてのエディタに対応しています。コンピューターにインストールされていれば、おそらくここに表示されます。
VS Codeで開きます。開いていたすべてのブログ投稿が死んでいます。ブログの構成方法の構造を変更したからです。今は、すべてのブログ投稿用にactiveとarchivedフォルダーがあります。これは格段に管理しやすいです。実際、この変更にかなり興奮しています。良い変更です。では、これをコミットしたいとしましょう。ここに小さなボタンがあります、commit。
コミットとPR作成の効率化
コードの差分パネルボタンもあって、ここを見て実際に何が変わったかを確認できます。大丈夫です。あまり文句は言いませんが、正直なところ、エディターや他の場所で開く方がずっと好きなので、そこにいることはあまりありません。下部にターミナルもあって、ここで直接ターミナルを使いたい場合に使えます。これを本当に気に入っている人もいます。
個人的にはそうでもないんですが、素晴らしいユースケースもあって、すぐにお見せします。でも、これをコミットしたいので、commitをクリックします。そしてここに、私が彼らに追加するよう強く要求した機能があります。空白のままにすると、コミットメッセージを自動生成します。いいですね。だから、commit、commit and push、またはcommit and create PRができます。
commit and create PRが良さそうです。では、それを実行します。ここにいる間に、別の作業が完了したことに気づきました。これが魔法の一部です。異なるスレッド間を飛び回って、タスクがどこにあるかを確認しているだけです。これまで以上にマネージャーのように感じていますが、同時にこれまで以上に生産的だと感じています。
今、これらすべての変更のPRが同時にあります。ここにはLawnの更新があり、ビデオプレーヤーの変更があります。戻って、タイムスタンプのクリックが機能するか見てみましょう。見てください、OpenAIのおかげで。文字通り5分で、2つの実際のプロジェクトで2つの大きな変更を完了しました。
でも、同じプロジェクトで同時に2つのことに取り組みたい場合はどうなるのか。ここでワークツリーの出番です。そして、ワークツリーのやり方が興味深いとだけ言っておきます。ワークツリーについて誰も正しく理解していないと思います。ワークツリーには非常に多くのレイヤーがあるからです。
ワークツリーの概念と課題
ワークツリーに馴染みがない方のために説明すると、これはGit内の概念で、Gitリポジトリを取得し、新しいブランチを作成して、コンピューター上の別の場所に配置するものです。だから、同時に2つのことに取り組むことができます。これは長い間あまり重要ではなかった機能です。なぜなら、誰が同時に2つのことに取り組むのかって感じだったからです。はい、私です。今は同時に10個くらいのことに取り組んでいて、大変です。
だから、ワークツリーがこれをすべて解決する約束された解決策です。そして今、本当に深く取り組んできた結果、嘘をつかれてきたと言えます。ワークツリーは、コードがどこにあるかを把握するのを難しくすること以外、何かをする良い方法ではありません。根本的なレベルで非常に不満を持っています。間違ったプリミティブのように感じます。
同じブランチやコミットを2つの場所で同時にチェックアウトすることはできません。だから常にブランチを作成しなければなりませんが、それらを同期させ続けるのは大変です。だから、Codexでやっている方法は少し異なります。最初にワークツリーを作成すると、プロジェクトのコピーを作成して、どこか別のディレクトリに配置します。
従来のGitワークツリーではありませんが、実際のコピーで、その後、変更を同期して戻すことができます。では、Lawnでこれを素早く試してみましょう。私たちが取り組んでいる実際の再設計ブランチがあります。ワークツリーをクリックします。mainから切り替わりますが、これは私が求めているものではありません。私が取り組んでいるブランチではないからです。これは嫌いです。
私が文句を言ってきた多くのことのひとつです。願わくば修正されるでしょう。actual redesignに切り替えます。それが開始したい場所です。ユーザーが新しい動画をアップロードしたら、その動画用のサムネイルを作成する必要があります。これを行う最も簡単な方法は、アップロード時にクライアント側で行うことだと思います。
最初の静止画か、動画の早い段階からの何かを取得して、動画と一緒にアップロードすべきです。そうすれば、サムネイルとして使用できます。そして今、これはワークツリーで作業されています。ローカルと同期するか、何らかの方法でPRを作成するオプションがあります。実際にその部分をどうやるのか、まだ理解していません。
正直なところ、ワークツリーの実装が、これまで見てきた中で最も考え抜かれたワークツリー実装のひとつであると同時に、最も役に立たないもののひとつであることが分かりました。Codex内でワークツリーをあまり楽しんでいません。将来的に、もう少し使い心地を良くする方法を見つけてくれることを願っています。ローカルに同期してからプッシュしなければならないというのは、あまり良い感じがしません。
クラウド環境の活用
今、ブランチのブランチにいます。それをマージするPRを作成できるか、この作業を最初にプルバックせずにアップする他の方法があるべきです。そのため、驚くほど便利だと感じている別のワークフローがあります。右側にもうひとつボタンがあります、cloud。クラウド環境は、同じUIの中に入っているだけで、はるかに苦痛が少ないことが分かりました。
同じプロンプトを貼り付けます。クラウド環境を選択する必要があります。クラウドでどのように使用するかを知る必要があるからです。最も面倒なことのひとつです。コンピューター上のランダムなフォルダーを使用することはできません。Codex内のすべてはGitリポジトリでなければなりません。クラウドを使用している場合は、GitHubにあり、すでに同期されている必要があります。
そのため、これを行わなければなりません。今、Lawnは作成できる新しい環境です。これらすべてのことに煩わされるつもりはありません。実際にインターネットアクセスを必要としたり、何かをしたりする必要はありません。考えてみれば、インターネットアクセスを与えるべきです。検索などができるように。でも、はい、いつものように、それを元に戻します。
エージェントに無制限のアクセス権があります。しかし、これらすべてを設定し、環境変数を管理し、どのコンテナにいるかなどを把握しなければならないという事実、これは私の意見では非常に未解決の領域です。クラウドの設定が少し面倒でなくなる未来を夢見ています。
しかし、これらの変更を加えたので、Lawnが利用可能になりました。mainから始めています。mainから始めるべきではありません。redesignから始めます。そして、実行します。そして今、私のコンピューター上で同じプロジェクトで2つの別々のタスクが進行しています。どちらも、プロジェクトが実際に存在するフォルダー内のコードには触れていません。
これはクラウドで実行され、最終的にプルリクエストを提案します。これは私のマシン上で実行されていますが、ワークツリー内なので、後でメインブランチに引き戻すことができます。そして、これらすべてが進行している間に、現在開発中のT3 chatアプリのネイティブクローンや、構築したファイルシステムなど、他のプロジェクトに飛び込むことができます。
はい、オーケー。本当のファイルシステムではありません。マシン間でファイルを同期する代替方法で、これもほぼ完全にCodex内で構築しました。あるいはT3 chat自体、待って、1か月前?このアプリを1か月持っているんですか?いいえ。これが機能する方法は、プロジェクトと同期しているということです。私のコンピューター上のどこにあるかを知っているからです。
だから、私のマシン上でCodexで行ったさまざまなことの履歴と、私のマシン上でCodex Cloudで行ったことの履歴があります。そして、ここでは、長いスレッドのパフォーマンス改善や圧縮の全面的な見直しなど、できるかどうか興味があっただけの大胆なことをやらせたような、より重いものが見られます。
複数プロジェクト間の柔軟な作業管理
そしてすべてがここにあります。同時に、メインスレッドが進行しています。飛び回るのがとても簡単で、ブラウザ、コードエディター、その他のサーフェス間など、他に飛び回らなければならないものについて、より不満を感じるようになりました。特に、開発環境を立ち上げたり、環境変数を管理したりしなければならない場合は面倒です。
ワークツリーを作成したときに環境が引き継がれるようにする方法をまだ理解していません。驚くほど多くの設定が利用可能です。やりたいことや異なる方法で行いたいことについて、私たちが持つ提案に対して、彼らはかなりオープンでした。ここでは、設定の多くがconfig tomlの下に配置されていることが分かります。
しかし、できることは他にもたくさんあります。カスタム指示を与えることができます。スレッドで得られる情報の詳細度を変更できます。デフォルトでは、実際にはコード出力を表示しません。コードコマンドを含むステップのみを表示します。なぜなら、これはまた非常に異なる構築方法だからです。もはやAIを介してコードエディターにコマンドを送っているのではありません。
今は、より良いUIで私たちのためにコードを制御するエージェントをオーケストレーションしています。そして、これにより、実際のコード作業のためのターミナルベースのUIへの興味を完全に失いました。でも、前に言っていたように、環境のセットアップ方法が本当に分かりません。環境には名前があります。セットアップスクリプトとプラットフォームのオーバーライドもあります。これは興味深いです。今のところMac専用アプリだからです。
明らかに、将来的には変わるでしょう。今のところ、Macだけです。だから、ここには環境変数を扱う方法を示すものが何もないようです。これはプロジェクトルートで実行されますが、どのパスに行くのかをどうやって知るのでしょうか。環境変数を管理する方法についての明確な方法がどこにもありません。これは、並行して別の場所でコードを書く以上のことが無意味に感じられます。
将来的に、これらのことを明確にして、より簡単にする方法を見つけてくれることを本当に願っています。少なくとも、ワークツリーで多くのことを行う方法を説明する既存のCursor設定をコピーするべきです。はい、いずれそこに到達するでしょう、きっと。MCPサーバーもあります。もちろんあります。かなりクールなスキルブラウザもあります。
スキルとオートメーション機能
私が持っているものすべてを見ることができます。はい、今ではかなりたくさんあります。スキルの人間になったことは分かっています。それはそれです。Cloudflareへのデプロイ、Atlasの管理など、ブラウザで何が起こっているかを確認できるように、おすすめのものもたくさんあります。アプリを通じてLinearの問題を制御します。
だから、問題について伝えて、それに対処すると、それに応じてステータスを更新できます。かなりクールです。組み込みの画像生成、これは本当にクールです。彼らが行ったデモのひとつは、エージェントが必要なものの画像を生成し、進行中にAtlasを使用して確認できる、1つのプロンプトでフルゲームを作成するというものでした。
そして私のお気に入りは、yeetです。これはステージング、コミット、PRのオープンを行います。準備ができたと思ったら、yeetするように伝えるだけで、スキルを使って理解します。バカバカしいですが、便利です。私自身はまだセットアップしていません。いつものスキルだけです。でも、それを使うことになると思います。実際、良くて、有用で、趣味の良いものです。
ご想像の通り、これを構築しているチームは、これを使って構築しています。だから、彼らはここに深く入り込んで、たくさんの変更を加えています。報告したときに物事が修正される速度は非常識です。これは、彼らが半端にしか投資しないランダムなサイドプロジェクトではありません。彼らが望み、使用し、成功を本当に見たいと思っているもののように感じられます。
彼らがどれだけの努力を注いでいるかに驚いています。私にどれだけ強く押し付けているかという意味ではありません。実際にはそれほどでもありません。テストグループの中で最も興奮している人間のようですが、私たち全員がこれをたくさん使っていて、本当に良いです。でも、今残された疑問は、私が毎日何を使うかということです。
以前、Claude Codeをさまざまなランダムなことに使い続けていると述べましたが、それらは何でしょうか。Claude Codeの使用のほとんどは、一般的なコンピューターのこと、Gitリポジトリに深く結びつく必要のないことです。だから、ディレクトリから実行できるスクリプトを簡単に作成して、グローバルになるようにセットアップしようとしていました。それをやりました。
Claude CodeとCodexの使い分け
zshell設定への多くの変更をClaude Code経由で行っています。ファイルを見つけます。一回限りのタスクを行うスクリプトを書きます。ウェブサイトをスクレイピングします。情報を取得します。コンピューターを使うように、Claude Codeを使っています。
しかし、Codexが実際の構築方法です。現時点での考え方は、これをコミットしてプッシュする意図があれば、おそらくCodex内で行っているということです。コンピューター上で物事を変更したり、一回限りのスクリプトを書いたり、1つの本当のユースケース、つまりUIのパスや時には完全なUIの刷新を行っている場合は、Claude Codeを使います。
このアプリへのアクセスを得てから行ってきた他のすべてのことは、Codex内で行ってきました。Codexで抱えていた最大の問題を本当に解決しているように感じられます。それは、モデルが遅く、その結果使用するのが不快で、どの端末タブでどの実行が進行しているのかを見失うだけだったということです。
Codexモデルは、これらの大きくて重いタスクに対して一般的にヒット率と成功率が高いため、すでにそれらと並行して作業していることに気づきました。時間がかかることが分かっているものをCodexで実行し、手動でワークツリーを立ち上げて、Claude Codeで遊んで、Codexの実行が完了するのを待っている間にどのように感じるかを確認するところまで来ていました。
そして今、このユースケースに合わせて作られたUIがあります。本当に素晴らしい。本当に素晴らしいんです。物事を行えるUIがあるのは本当に素晴らしいです。そして、クレイジーなことに、スクリーンショットを貼り付けてUIで見ることができることを知っています。これらの端末で時間を費やしすぎていて、今はほとんど時間を費やしていないので、しばらくぶりです。物事がどれだけ速く変化するか、クレイジーです。
VS Codeを8年間使い、Cursorを1年半使い、Claude Codeを2か月使い、これに至りました。そして、きっと変わり続けるでしょう。風景の変化、申し訳ありません。オートメーションについて話すのを忘れていました。本当にクールで、お見せする前にいくつかのことを片付ける必要がありました。セットアップされていると画面が消えてしまうんです。本当に面倒です。
オートメーション機能の可能性
オートメーションは、コンピューター上でエージェントができるすべてのこと、ファイル、フォルダーなどへのアクセス権を持つプロンプト付きのcronジョブのようなものです。まだあまり遊んでいませんが、少しだけ試したところ、すぐに追加したいと思うほどクールでした。例はすべてかなり基本的なものですが、どのように役立つかが分かります。
変更ログの自動作成、CI失敗の要約、最近のコミットのスキャン、バグの検索など。これにしましょう。最後の48時間に変更します。ここで、プロジェクトを選びます。T3 chatにしましょう。最新を引っ張るようにします。最近の変更を確認しています。72時間。
これは週末で、週の間にあまり出荷していないと思います。いつ実行するかを選択できます。だから、これは平日の毎日午前9時になります。これを実行して、バグかもしれないものを探します。一度に複数の異なるプロジェクトを追加することもできます。これは本当に本当にクールです。だから、これら2つのプロジェクトを行います。セットアップします。
テストして、どのように見えるか確認しましょう。確かに潜在的な懸念はありますが、ああ、見てください。実際にここでスレッドとして生成されます。かっこいい。異なるプロジェクトに行くと、要求したことを行うために作成したワークツリーを持つスレッドが表示されます。本当にクールです。
自動スレッド作成のようなものです。Open Routerに追加されたときに新しいモデルを自動的に追加するようにセットアップすることもできます。ああ、大変。繰り返しますが、このアプリで遊ぶと、物事を思いつきます。脳を異なる方法で使える異なる構築方法です。明らかに、ターミナルのようなものは同じようなもので、特定のパスでClaude Codeを使ってターミナルでcronをセットアップすることで、これを自分でセットアップできたでしょう。
でも、このように目の前にあると違う感じがして、それをキャプチャしたかったんです。そして、ここを見てください。実行可能なバグはありませんが、スキャンしたものがいくつかあります。ええ、これは本当にクールです。ちなみに、もう一台のラップトップに切り替えたので、構築してきたもっと多くのものを見ることができます。そこにはもっと見るがあるほどです。
Vibe Fasterプロジェクトへの情熱
でも、Vibe Fasterというプロジェクトをお見せしたいんです。このアプリで持っていたワークフローに非常に興奮していたので、当時抱えていたパフォーマンスの問題が本当に本当にイライラしました。メモリとバッテリーを食っていた一時期があって、本当に本当にイライラしました。
でも、このワークフローに非常にハマっていたので、拒否する気にはなれませんでした。だから、充電器を差し込んで、ネイティブの代替品の構築を始めました。はい、本当です。SwiftとAppKitでゼロからフルのデスクトップアプリを構築しました。SwiftUIではありません。SwiftUIのパフォーマンスはひどいからです。
これは、より良いバッテリー寿命を得られるように、Codexアプリで大好きだったものをネイティブビルドで再構築する試みです。バッテリーの消耗を見てタスクが完了する前にバッテリーが切れないことを願いながら、それほど悪い気分にならないようにできます。そして、彼らはこれらすべての問題を修正しました。そして今、できる限り幸せです。
数日前にこの投稿をしました。明らかに、テストしていたものに触発されました。これらすべてのエージェントコーディングTUIは一時的なもので、短命に終わるでしょう。ほとんどの開発者は数か月でGUIとIDEに戻るでしょう。GUIとIDEと言ったことに注目してください。意図的でした。CodexはIDEではありませんが、それを開くことへの興味を完全に殺してしまったからです。
もう気にしません。そこでコードを編集したくありません。すべての行を見渡したくありません。エージェントが何をしているのか、なぜそうしているのかを理解し、それで素晴らしいものを構築したいだけです。そして、これはまさにそれを行うための素晴らしいツールでした。
ストリーミングで使用しているコンピューターとは別に、この作業を行えるようにするためだけに購入した、目の前にある4,000ドルの巨大なラップトップを後悔すらしていません。お分かりの通り、これについて話せない2週間は大変でした。そして、ようやく皆さんと共有できることに大興奮しています。
このチャンネルで多くの異なるものに興奮していることは分かっています。それが私のスタイルです。新しいものを試すのが大好きです。でも、これほど長い間、日々の仕事をこれほど変えたものはありません。そして、皆さんも自分で遊べることに大興奮しています。
これについては以上です。構築に戻ります。なぜなら、子供の頃のように完全に中毒になっているからです。本当に心から楽しくて、戻って続けるのが待ちきれません。それではまた、ピースナード。
コメント