5,235 文字
私たちはついにOpenAIからクラウドベースのコーディングエージェントを手に入れました。彼らはそれをCodexと呼んでいます。これによって、将来的な協働コーディングがどのようなものになるかの最初の手がかりが得られます。また、今こそコーディングを学び始めることがこれまで以上に重要になる理由でもあります。これは物議を醸す意見かもしれませんが、後ほど動画で説明します。
まず、OpenAIには大きな問題があります。それはこれらのシステムに名前を付けることです。サム・アルトマンはこうツイートしました。「今回は成功した場合に備えて、ChatGPTよりも良い名前を付けます」。しかし、彼らはうまくやれなかったと思います。ある人が指摘したように、「OpenAIはCodexをリリースしましたが、これはCodex Oneによって動作しており、o3の特殊バージョンです。2021年にリリースされたCodexモデルや、先月リリースされたCIツールのCodexと混同しないでください。」
冗談はさておき、これは非常に興味深い実装のようで、Cognition LabのDevonのような代替手段になる可能性があります。このシステムはクラウドベースで、Cognition LabがDevonの形で提供しているものと非常に似ています。そして、多数の並列タスクを実行できます。したがって、機能の面でもユーザーとシステムの対話方法の面でも、SerfやCursorのような他のIDEとは大きく異なります。
このレビューでは、このシステムがどのように機能するかを見ていきます。また、いくつかの強みと限界、そして人々がそれについて何と言っているかも見ていきます。意見は大きく分かれており、コーディングの未来についての私の考えもいくつか共有します。
まず、ブログ記事の中のいくつかの興味深い点を簡単に見てみましょう。一つは、このモデルがソフトウェアエンジニアリング向けにファインチューニングされた、あるいは最適化されたO3のバージョンだということです。つまり、完全に新しいモデルやシステム自体ではありません。
このシステムの目標は、開発者と協力するエージェントになることです。開発者はタスクを割り当て、エージェントがそれらのタスクを完了してから実装を持ち帰り、ユーザーはPRを提出する前にそれらの変更や機能実装を受け入れる必要があります。
彼らが指摘するように、タスクは1分から最大30分かかることがあり、ユーザーはCodexの進捗を監視する能力を持ちます。つまり、Devonと非常に似た機能です。
これがどのように機能するかというと、ここに示すように、ChatGPTインターフェイス内で利用可能になります。ただ、アクセス権を得るためにGitHubリポジトリやGitHubアカウントを接続する必要があります。現在はPro版とEnterprise版で利用可能で、Plus版には近日公開予定ですが、いつになるかはわかりません。
GitHubリポジトリを接続して、そのリポジトリ内にAgent.mdファイルを作成する必要があります。これには、CursorルールやSerfのルールと同様に、リポジトリの内容に関する一連の指示が含まれます。
モデルまたはエージェントはGitHubリポジトリを調査し、環境をセットアップしてから、OpenAIクラウドにサンドボックスを開きます。つまり、ローカルでは何も実行されず、すべてがクラウドで行われます。クラウドで実行されているため、並列タスクを開始できます。これは非常に優れた機能であり、質問したり、コードベースに新機能を実装するタスクを割り当てたり、コードベースにバグがないか確認したりできます。
必要なのは、タスクを説明するだけです。システムは新しいサンドボックスをセットアップし、何が起きているかの進捗をすべて表示し、ユーザーは完全にコントロールできます。それらの変更をPRの形式でマージする必要があります。これがエージェントがあなたのために作成します。
ここにagent-start.mdファイルの例があります。これらはモデルに実行してほしいことについての指示の集まりです。優れたプログラマーのように、ユニットテストを作成し、それらを実行し、テストに合格したら、レポートを作成し、潜在的にPRを作成します。そのPRをあなた自身またはチームがレビューしてマージできます。
では、この新しいCodexエージェントコーディングシステムはどれほど優れているのでしょうか？彼らはいくつかの異なるベンチマークを提供し、これらのベンチマークの問題点も示しています。
ここにSWBench-verifiedがあります。特定のタスクを解決する試みを1回だけに制限すると、O3のhigh設定よりも確かに優れています。しかし、CodexとO3 highが試行回数を増やすと、実際にパフォーマンスの差はそれほど大きくありません。特に4回の試行あたりで飽和するため、その差はわずかです。
そのため、OpenAIは独自の内部ソフトウェアエンジニアリングタスクベンチマークを持っています。このベンチマークでは、O3 highと比較してかなり大きな改善を示しています。3つのベンチマークでは、内部インフラストラクチャとCodex Oneで実行できなかった23のサンプルを破棄する必要があったと述べています。Codex Oneは最大コンテキスト長192,000トークンと中程度の推論努力でテストされました。これは今日誰もが利用できる設定です。
Xで誰かが指摘したように、SWbenchでのこのパフォーマンスはO3とそれほど違わないようです。OpenAIのエイデンはこう言っています。「SWbenchは本当に不完全なターゲットです。MMMLUで98点が95点より少し怖いのと同じです。なぜなら質問の一部が間違っていることを知っているからです」。SWBench-verifiedはOpenAIとの協力で作成されたことを覚えておいてください。それゆえ、これらのベンチマークが実際にどれほど優れているかという疑問が生じます。なぜ不完全だとわかっているベンチマークでテストするのでしょうか？
O3はすでに信じられないほど有能です。Codex Oneはより有用で優れた製品となり、ユーザーにとってより多くの価値を生み出すことを目的としています。では、どれだけ多くの価値を生み出すのでしょうか？それは誰に尋ねるかによって大きく異なります。
いくつかの例を挙げましょう。マットはこう言っています。「私はしばらくCodexへのアクセス権を持っていました。十分な時間を費やしていませんが、うまく機能するときは強力です。私の経験では、バックエンドタスクに最適です」。
私が気づいたのは、早期アクセスを持っていた多くの人々が「それがうまく機能するとき、本当に良い」と言っていることです。早期アクセスを持っていた別のユーザーもこう言っています。「うまく機能するとき、かなり魔法のような体験です。モデルがコードから持つ理解のレベルに驚いています」。
しかし、このような経験もあります。「Codexを試しています。インターネットにアクセスできない場合、どのように修正するのでしょうか？私のプロジェクトでNPMパッケージをインストールしたり、アップグレードしたりできません」。ユーザーは「Next.jsを最新バージョンにアップグレードして、すべてが正常に動作することを確認してください」と尋ねていました。しかしシステムは「インターネットアクセスがないため、Next.jsをアップグレードできません」と返答しました。プロジェクトを作成すると、もうインターネットアクセスがなくなると思われます。
彼らは実際にこの特定の機能をブログ記事で強調しています。「Codexエージェントは完全にクラウド内の安全で分離されたコンテナ内で動作します。タスク実行中はインターネットアクセスが無効化され、エージェントの対話はGitHubリポジトリを通じて明示的に提供されたコードのみに制限されます」。
これがシステムの主要な制限の一つだと思います。例えば、新機能を構築している場合、すべてのライブラリの最新バージョンが欲しいと思うでしょう。そして特に古いコードベースで作業している場合、おそらく古いバージョンのパッケージを持っています。
私が遭遇した例は、GoogleのGenerative AIパッケージです。Gemini APIで構築した古いプロジェクトのほとんどは、Gemini APIの古いバージョンを使用しています。しかし、現在は統合SDKがあるため、多くの問題に直面しています。
インターネットアクセスを無効にすると、ドキュメントを検索する必要があるため、最新バージョンを使用できなくなります。彼らの観点からすると、セキュリティ目的でこれを行いたいのですが、このようなエージェントシステムの使いやすさを本当に制限することになると思います。これはまだプレビュー版なので、おそらくその特定の機能を有効にする予定です。
彼らは「Codexを設計する際にセキュリティと透明性を優先しました。ユーザーはその出力を検証できます。これはAIモデルがより複雑なタスクを独立して処理し、安全性の考慮事項が進化するにつれて、ますます重要になるセーフガードです」と述べています。これは本当に重要な懸念だと思いますが、より多くの柔軟性も持ちたいと思うでしょう。
彼らはこれらのAI駆動のエージェントシステムを使用して構築される可能性のある悪意のあるアプリケーションに対して真剣に制限またはセーフガードを設けています。しかし彼らは「保護措置が、時にはマルウェア開発にも使用される技術を含む可能性のある正当で有益なアプリケーションを不当に妨げないことが重要です」と述べています。そしてシステムはそれを理解するのに十分賢いようです。
実世界での賢さという点では、このシステムがどれほど優れているかについてコミュニティからの意見を待って確認する必要があります。しかし、少なくともこれにより、これらのAIエージェントがより大きなオープンソースプロジェクトに貢献する可能性が開かれます。Devonもよく似た約束をしていました。これらのエージェントからより大きな貢献をまだ見ていませんが、これが現実になる地点に来ていると思います。
これらのコーディングエージェントがどんどん良くなるにつれて、プログラミングとコーディング全般についてどのように考え始めるべきでしょうか？そのためには、グレッグ・ブロックマンが何を言ったかを聞くことが非常に重要だと思います。
「私がCodexの機能について本当にワクワクすることの一つは、それが非常に人間とは異なる強みと弱みを持っていることです。そして、それは単に静的なツールとして使うのではなく、専門知識を構築せずに使用するだけではなく、本当に多くのことを得られることを意味します。
しかし、実際にコードベースをそれができることに最適化し始めると、正直なところ、Codexが恩恵を受けるほとんどのことは、モジュール式のコードベースと良いテストなどの点で、優れたソフトウェアエンジニアリングのプラクティスに過ぎません。そうすれば、本当に素早く進めることができ、OpenAIの多くの人々の間で内部的にそれが起こるのを見てきました」。
これは二つの異なる方法で捉えることができます。一つは、これらのシステムと協力してコーディングする全く新しいパラダイムを学ぶ必要があるということで、私はそれは間違っていると思います。考えるべき方法は、ソフトウェアエンジニアリングのベストプラクティスを学び始める必要があるということです。そして、これらのエージェントシステムを効果的に使用したいなら、実際にコーディングの原則を理解する必要があります。
これは、コーディングのバックグラウンドを持たず、アプリケーションを構築したい人にとって、モジュール式コードを実装する方法や最良のプラクティスについてこれらのシステムから学ぶ非常に良い機会になるはずです。それがこれらのコーディングエージェントを使ってより良いアプリケーションやシステムを構築できる唯一の方法です。
個人的には、これらのコーディングエージェントがプログラマーに取って代わるのではなく、効果的に彼らの生産性を新しいレベルに引き上げると思います。これはまだ初期段階であり、生き残るためには、あなたの技術を向上させる必要があります。あなたはどう思いますか？とにかく、この動画が役に立ったことを願っています。視聴いただきありがとうございます。いつものように、次回もお会いしましょう。
コメント