Cursor vs Codex

ソフトウェア開発・プログラミング
この記事は約42分で読めます。

本動画は、AI開発者による最新のコーディングツールの比較検証である。主にCursor、OpenAIのCodex、GoogleのJewelsという3つの異なるアプローチを持つ開発支援ツールを実際のロボティクスプロジェクト（タトゥーロボット「Tapbot」）で試用し、それぞれの性能と使い勝手を評価している。ライブコーディング形式で進行し、実際の開発現場での実用性を重視した検証内容となっている。

ライブ配信開始

よし、配信が始まったと思います。今日は短時間の配信にしなければなりません。色々と用事が入ってしまったのですが、キャンセルしようかとも思ったのですが、やはりキャンセルせずに何かしら配信しようと思いました。たとえそれがあまり良い内容でなくても、たとえ時間がなくても、毎日少しでも作業をするよう心がけるべきです。少しでも作業しようとする試み自体に意味がありますからね。

調子はどうですか、Paul。

よし、始めましょう。実は家族が今寝ているので、大きなホーンの音で起こしたくないんです。なので私のアステカの死の笛を使って、とても静かにマイクに向かって吹いてみます。家族には聞こえないことを願って…

これがアステカの死の笛でした。

Hoopoライブ配信開始

皆さん、またのHoopoライブ配信へようこそ。今回のタイトルは「Cursor vs Codex」です。3時間聞いても何一つ理解できない準備はできていますか？実際にはそんなことはありません、Paul。今回はかなり理解しやすい内容になると思います。

基本的に最先端のコーディングツールを比較していきます。皆さんは私がCursorをよく使っているのを見たことがあると思いますが、この配信でも主にCursorを使い続けるつもりです。正直言って、これが私の日常的なメインツールです。とても良いツールですが、最近試してみたい新しいツールが2つあります。

一つはOpenAIのCodex、そしてもう一つはGoogleの同様のツールであるJewelsです。

これらはCursorとは全く異なる製品です。Cursorの動作方式は、基本的にあなたと一緒にファイルを編集するもので、GitHub Copilotの後継のようなものです。IDEに組み込まれたコパイロットやアシスタントのような概念ですね。

しかし、ここにあるCodexとJewelsは、実際に人間を置き換えることを意図した初の本格的なソフトウェアエージェントです。チーム環境で他の人間チームとコードに貢献する際に使用するものです。

Tapbotプロジェクトの紹介

この配信全体を通して、Tapbotでの作業を行います。Tapbotをご存じない方のために説明すると、これは私が多くの時間を費やして取り組んでいるプロジェクトで、基本的にタトゥーロボットです。ここにTapbotが小さなタトゥーを描いている様子があります。

チームでコードに貢献する際には、プルリクエストや設計文書といった正式な手順とプロセスがあります。プロダクトマネージャーのような非エンジニアも関わってきます。プルリクエストを作成し、他の誰かがそれをレビューしてマージするという流れです。

CodexとJewelsはまさにそのように動作します。まるでルーマニアからリモートで作業している作業者のように、プルリクエストを作成し、あなたがそれをマージするという形です。Cursorが直接編集するのと比べて少し冗長ですが、非同期で作業できるという利点があります。

では、この2つを直接対決させましょう。Google JewelsとOpenAI Codexを比較していきます。

April tagsについて

難しいのは、両方が同時に貢献するとマージコンフリクトが発生する可能性があることです。そこで、お互いの作業が干渉しないよう、新しいファイルを作成するタスクを与えようと思います。

このTapbotには、昨日ポイントクラウドで作業していたものがありますが、April tagsというものが見えます。これらはApril tagsと呼ばれるもので、現在このワークマットの位置は基本的にハードコーディングされています。正確にどこにあるかを知っているだけです。

しかし、最終的にはTapbotに搭載されている複数のRGBカメラを使いたいと考えています。これらはRGBカメラで、Power over EthernetのIPカメラです。すべて小さなLANボックスに接続され、Tapbotの異なる計算ノードにも接続されています。

April tag検出を1つまたは2つのカメラで実行したいと思います。すべてのカメラをApril tag検出に使う必要はなく、1つで十分だと思います。これにより、非常に良好な位置や姿勢を取得できるようになります。

プロンプトを考えてみましょう。これは同じプロンプトにするつもりです。なぜなら、これらを評価したいからです。

プロンプトの作成

少し考えを巡らせてみましょう。これについて少し思考を働かせる必要があります。

「ワークスペースマット上の3つのApril tagsを検出する新しいファイルapril_tag_gpt.pyを作成し、オーバーヘッドRealSenseのカラーカメラから検出を行い、それを使ってマットの姿勢を更新する」

「April tagコードを含むシンプルで新しいファイルを作成し、Visorを使って結果を可視化する」

どのApril tag依存関係を使用するかについては意図的に曖昧にします。これがプロジェクトの重要な部分だからです。

April tag用のPythonライブラリには様々なものがあります。多くの場合、人々はROS環境でApril tagsを使用するため、C++で書かれたかなり良いパッケージがあります。これがほぼ全員が使用しているものです。

しかし、私たちのプロジェクトはPythonベースなので、PythonベースのApril tagが必要です。いくつか候補があります。

これを見てみましょう。pupil-labsのapril tag、123スターというのはあまり良い兆候ではありません。まだプッシュしているのが見えますね。先月ここに、5年前とあります。つまり、これはかなり古いコードベースで、時々更新されているようです。これは候補の一つかもしれませんが、これは「no longer supported」と書かれているこちらから取られたものです。それは良くありません。

この一つはさらにスターが少ないので、さらに怪しいです。「april tag python」と入力してみましょう。

ああ、これがありますね。いえ、これは2021年に更新されたと書かれています。これらはどれも良くありません。すべてかなり怪しいです。Pure Python版のApril grid、2023年に更新。これも公開アーカイブです。これらはどれも良くありません。

libdt april tags、最後に誰かがコードをプッシュしたのは2年前です。これらはどれも良くありません。

何も言わずに、彼らがどれを選ぶか見てみましょう。

詳細なプロンプト内容

「April tagsを検出する新しいファイルを作成し、3つのApril tagsを検出する。オーバーヘッドRealSenseのカラーカメラからApril tagsを検出し、それを使ってマットの姿勢を更新する。tatbot.pyファイルとは独立してテストできるが、同様のスタイルに従う最小限のバージョンを作成する。あなたの思ったファイルでは、どのPythonベースのApril tag依存関係が最適かを調査し、必ずVisorを使って結果を可視化するようにする」

これがプロンプトになると思います。同じことをここでも行いますが、GPTではなくCodexと呼ぶことにしましょう。

よし、コードと入力して、「give me a plan」をクリックします。

両エージェントの作業開始

Codexでは、すぐにこのタスクの作成を開始したのが見えます。UIが非常に異なります。基本的にタスクがあるUIが見え、それらをクリックして、タスクの進行状況を確認できます。最初に行っているのは、コンテナ化された環境を作成し、すべてをその中で実行しています。

同様に、こちらもHoopoをクローンしています。基本的にDockerコンテナを作成し、すべてをDockerコンテナ内で実行しています。

これはこのプロジェクトには実際には機能しません。なぜなら、これはロボティクスプロジェクトなので、Dockerコンテナ内に仮想環境を作成してすべての依存関係をインストールしても、RealSenseカメラやロボットなどのハードウェアが接続されていないため、実際には実行できないからです。環境を再現することはできないでしょう。

では、どうなるか見てみましょう。

Jewelsはここで小さなプランを提示してくれました。「April tag検出とマップ姿勢推定を実装するためのプランを作成しました。プランをレビューして、フィードバックがあれば教えてください」

April tagを追加し、実装し、色々とやるつもりです。「Approve sounds good to me. Do your thing buddy」と伝えます。

この子はすでにファイルを読んでいるのが見えます。彼らに作業を任せましょう。

Cursorでの並行作業

さあ、Cursorに移って、これについて作業してみましょう。これは私たちがCursorで作業できると思ったものです。

Cursorにいて、私がやりたいことは、参照しやすいように小さなtodoをここに追加することです。

現在のTapbotの動作方式は、基本的に一度に1つのタトゥー、実際には1つのピクセルずつ処理しています。これをバッチ処理に変更したいと思います。IKもバッチで処理できるようにするためです。

プロセス：

  • 画像をパッチに分割
  • パッチの中心を使用し、その半径を定義
  • その半径内のすべての黒いピクセルをサンプリング
  • バッチ用のIKを計算

コピーして、Ctrl+Shift+Iを押します。「help me implement or upgrade the pixel target design to a batched pixel target design. here is the new flow」

あれ、停止しました。ペーストできませんでした。なぜ動作しないのでしょう？コピー。Ctrl+Shift+ペーストを使わなければならないと思います。

続行して元に戻します。ここで再開しましょう。

Cursorの作業プロセス

Cursorの動作方式が見えます。ファイルの修正を開始し、これがずっと速いと私が感じる理由です。

「pixel batch data class」を作成しました。私のすべてのデータクラスは、このjdc py tree data classを使用しています。これは基本的にPythonデータクラス上のJAXラッパーで、これらのオブジェクトをJet compiledされたJax関数内で使用できるようにします。

ここで多くの変更を行っているのが見えます。これらを確認する必要があります。

ここで新しいデータクラスを作成したのは気に入りません。これを修正するだけで良かったのですが、見てみましょう。pixel targetsのリスト、radius、center poseです。それは結構です。

batch radiusをメートルに変換、バッチのみを作成。ターゲットのすべての位置、配列内のすべての位置。バッチインデックスです。これには同意します。実際にそれを受け入れます。

current target indexをcurrent batch indexに変更しています。float current batch standoff。これは良いですね。standoffポジションはバッチセンターに対するものです。

standoff positionとは、基本的にタトゥーを行う際に、インクを付着させるために針が行きたい実際の位置がありますが、その上の位置、つまり皮膚の法線ベクトルに対して上の位置があります。基本的に私がstandoff positionと呼んでいるものがあり、これはIKが向かいたい位置です。

ここで正しいことを行い、基本的にバッチの中心からstandoff positionを作成するのが見えます。実際にここに行くと、JIT compiledと表示されているのが見えます。これは、Pythonでこれを初回実行する際に、JaxがこのPythonコードを取得し、効果的に小さなコード、GPUで実行される小さなカーネルに変換することを意味します。

その後、これを実行するたびに、うまくいけばかなり高速になります。しかし、ここで必ずしも行っていない多くの最適化があります。多くの場合、並列で多くのことを行っている場合にのみ高速になります。

現在、一度に1つのピクセルを計算しているため、実際にはそれが遅くなります。CPUとCPUに接続されているRAMのメモリからGPUにものを移動し、その後CPUに戻し、再びGPUに戻す必要があるためです。これはかなり遅くなる可能性があります。

このようにバッチで行うことで、実際にJaxを使用することが有用になります。

poke positionを計算していますが、これは間違っています。ここで見ると、current batch pixel targets current targetのみを行っています。それは正しくありません。

これを取って、チャットに追加し、「poke is a JIT function. we should be passing in all of the pixel targets at once in a batch and receive the…」または、これがすでに行っていることでしょうか？IKで受け取る、とりあえずそれをやってみましょう。何をするか見てみましょう。

Cursorのレスポンス

「はい、その通りです。Jaxのベクトリゼーション機能を使用して、ポーク関数をターゲットのバッチを一度に処理するように修正すべきです」

Cursorには少し冗長な問題があることに気づきました。あなたがいかに正しいかについて話すために、トークンを費やし無駄にするのが好きなようです。

単一ターゲットを新しいpoke batch関数に置き換えます。実際に行ったことが見えます。ここにVmapがあります。pixel positionsは正しいでしょうか？これができるかどうかわかりません。

私はこのJax typingを使用していますが、これができるかどうかわかりません。Jax typingを調べてみましょう。

複数の軸に一致できるように軸に前置すると言っています。これが欲しいもので、バッチサイズが何らかの形状だと言えるようにしたいです。

ここに例があります。nではなくbatchと呼ぶだけです。ここに来て、nと呼ぶ代わりに、ちょっとCtrl+Fで、Ctrl+Hでnをbatchに置き換えます。

これはもはや同じものではありません。これが今でも動作するかどうかわかりません。また、これらのコメントも気に入りません。本当に迷惑です。

すべて受け入れましょう。ここに戻りましょう。

batchが未定義であることが気に入りません。これは構文エラーでしょうか？これは実際に動作するでしょうか？これが正しいかどうかはわかりませんが、これは大丈夫だとは知っています。

チャットが失われました。戻りましょう。すべてを適用したようです。ここに戻りましょう。

batch radiusとbatch centersのグリッドサイズは設定の一部である必要があります。batch radiusは…それを行います。何を言うか見てみましょう。

設定の追加

追加しているのが見えます。ここの上部に行きます。batch radius、処理する各バッチのピクセル単位の半径。batch radiusはメートル単位である必要があります。ここで更新すべきでした。

batch radius meters、処理するピクセルの各バッチのメートル単位の半径。まだそれが気に入りません。batch radius pixel to meterはどこから取得しているのでしょうか？右ここから取得しています。

メートルをピクセルに変換、バッチ、center in radius pixel to image heightからbatch radius pixel 2まで、それが何なのかわかりません。必ずしも正しくないようです。centerをメートルに変換します。

この4重にネストされたforループが本当に気に入りません。悪く感じます。この全体をJIT関数内に置くべきだと感じます。それが正しいことのように思えます。

受け入れることを信頼していないと思います。ここですべて受け入れを押すだけです。コードを信頼します。

エージェントの作業完了確認

2人の仲間のところに戻りましょう。

両方の人が完了したのが見えます。Codexはapril_tag_codex.pyを作成し、pupil-april-tagsをpi projectに追加しました。表面的には問題なさそうです。

Jewelsはどうでしょうか？Jewelsはapril_tag_jewelsを作成し、pupil-april-tagsも追加しました。これは少し良く、バージョンを完全に固定するのではなく、バージョン範囲を提供しています。

実際にこのpupil-april-tagsを見つけて、実際にそのバージョンがあるかどうか確認してみましょう。

ここでPyPIにいます。これはPythonパッケージマネージャーで、ここでrelease historyに行くことができ、出された異なるバージョンを見ることができます。例えば、これを見ると、これは1.0.4までしか上がっていません。

すでにこれは、この「less than 2」というのは完全にでたらめです。pupil-april-tags 2.0は存在しないからです。これは正しくありません。バージョンがわからない場合は、このようにそのままにしておけば、後でピン留めできるので、実際にはこちらの方が良いです。

Jewelsのコード分析

ここがapril_tag_jewelsです。ロガーを設定し、rotation matrixからquaternionへの独自のカスタム関数を作成しており、少し不必要に思えます。これを見てください。このような小さなものを使用しました。すごい。ランダムなWebサイトを使用しました。これはとても関与しています。

通常はそれを行うパッケージを使用するでしょう。例えば、私たちのTapbotでは、この依存関係を使用しています。jaxlee、lee group algebraです。algebraかどうかはわかりませんが、基本的にすべてのSO2、SO3のような変換です。

ここでそれらの一つを見つけることができます。このような種類のものです。これがwxyz quaternionを回転行列に変換する方法です。jaxlie SO3がそこで使用するものです。

transformsにjaxlieを使用するように言います。ここで小さなフィードバックを与えます。

それ以外に、独自のreal senseオブジェクトを再び作成しています。ここで何をしているのか見てください。カメラの視野をこれから作成しています。これは、理由もなく一から多くのことを行っているだけです。

「assume a cv2 video capture from device equals zero」と言います。real senseを取り除きます。real senseが入ったことで、real senseカメラですべてのこのがらくたを行いたがったのだと思いますが、実際にはカメラについてはあまり気にしていません。

Codexのコード確認

戻りましょう。この人もreal senseの多くのことを行ったでしょうか？これは少し良いです。これは動作するようにも見えません。

「the most recent version of pupil april tags is 1.0.4 post 11」と伝えます。

フィードバックを与えて、彼らに作業を続けてもらいます。

これらの人たちとは少し待つ必要があります。時々彼らは質問を返してくることがあり、すぐに他のものにalt tabすると、実際にはそれらを見ることができません。

システムの仕組み

これは少し奇妙です。何か他のことを行うよう求めるたびに、全体のセットアップを再度通ります。コンテナを完成させているので、このDockerコンテナを再構築し、仮想環境を再作成しています。

これは理にかなっていると思います。なぜなら、考えてみると、OpenAIがクラウドのどこかで実行されているこのDockerコンテナに対して支払っているからです。この点に到達してプルリクエストを作成した後、もし私が一日の後半まで戻って来なかったら、彼らはクラウドで実行されているだけのこのマシンに対して支払いを続けることになります。

フィードバックが必要な時点になると、基本的に現在のコンテナを終了し、少しでもフィードバックを与えると、コンテナを再作成して再実行するのは理にかなっています。

チャットコメント対応

shcとkrishnam sさん、あなたのSAM 2ビデオを見て購読しました。それは古いビデオですが、おそらく現在でも最先端のセグメンテーションモデルだと思います。こんなに詳細なビデオを作ってくれてありがとうございます。これらのビデオは少し異なります。フォーマットを変更しようとしています。

このような質問があることを知っていました。これらの変更に対して新しいアプローチを作成したいですか？はい、それは結構です。続けてください。

Visorの可視化機能追加

ここに戻りましょう。このパッチラディウスで作業していました。visorの例で見た一つのことがあります。visorは私が使用している可視化フロントエンドの一種です。plotlyを見ました。

それを追加したいと思います。「I want to be able to visualize the current batch of targets in the gui image of the design. Look at this example in visor as a reference」と言います。

これは、Cursorでコーディングする際に多く行い始めたことの一つです。使用している依存関係が何であれ、visorやtruss and armやpyro keyなどです。pyro keyは基本的に運動学です。これらのモデルはそれらが何であるかを知りません。

pandasやnumpyのような依存関係では特に、長年にわたって多くの異なるバージョンがあったため、非常に混乱する可能性があります。

私が行うことは、使用している特定のバージョンをクローンすることです。これは実際に使用しているvisorバージョンです。examplesフォルダに入り、これらの例をドラッグインできます。そこに置くことができます。

基本的に何かを行うよう求め、visorリポジトリからの参考例を提供しています。これにより、構文を正確に見ることができ、これが一貫性を大幅に向上させることがわかりました。何かを一から行うよう求めて参考を与えないと、ほとんど常にガベージを返してきます。

aries machettiとabimmanu yadavとsidが「try claude code. i found it way better than codex」と言っています。Claude Codeは全く試したことがありません。anthropicにサブスクライブしていません。この時点で逃したものでした。しかし、Claude Codeは視覚的ではありませんよね？これのような実際のものではありません。

エージェントの作業完了

この人は完了したようです。見てみましょう。

今では与えた特定のバージョンをピン留めしているのが見えます。これもあまり良くありません。なぜなら、それが実際のバージョンなのか、私が言ったことを盲目的に行ったのかがわからないからです。正しいバージョンであることをインターネットで発見してほしいのです。私が正しいバージョンを与えたと信頼してほしくありません。

このCodexにブラウザツールがあるかどうかわかりません。実際にインターネットに行けるかどうかわかりません。

「Create this pull request」としましょう。この人がどこにいるか見てみましょう。この人はまだ作業中です。彼に小さな作業をさせましょう。

プルリクエストの確認

実際にリポジトリに行くと、小さなプルリクエストができているのが見えます。プルリクエストは実際にあなた自身のアカウントから来ています。

通常、チームソフトウェア環境のような種類では、自動化されたプルリクエストやそのようなものは、通常ボットアカウントを持っています。ボット専用に設定された別のGitHubアカウントがあります。

しかし、Google JewelsやOpenAI Codexのどちらの製品でも、誰かにボットアカウントを作成してからボットアカウントにリンクすることを期待するのは少し混乱しすぎます。基本的に彼らが行ったことは、あなたの個人アカウントにリンクして、あなたの代わりにプルリクエストを作成することを期待するということです。

この小さなプルリクエストを見てみましょう。ここで小さな要約を提供してくれました。「I tested this」と言っていますが、テストはありません。テストがないだけでなく、ロボットも接続されていないため、実際にこれをテストすることはできません。つまり、実際にはこれをテストしていません。これはちょっと雰囲気です。

ここに小さなファイル、小さなものがあります。

「Ready for review」、この人は少しイライラします。GPTは直接プルリクエストを作成するのが見えます。このブランチを作成したのが見えます。codeexブランチを作成し、ブランチから自動的にプルリクエストを作成しました。

しかし、Jewelsはそれを行いません。実際にブランチを作成しますが、その後、自分でそのブランチをプルする必要があります。基本的にブランチに行き、ここに来て、自分でプルリクエストを作成する必要があります。実際にここで他のクラップを記入することはありません。

完全なプルリクエストの作成を好みます。

プルリクエストのマージ

今では2つの小さなプルリクエストがあります。ここのコメントさえ、「changed three files」のようなガベージです。なぜ3つのファイルがあるのでしょうか？2つ作成しました。OpenCVのものを作成し、古いものも作成しました。古いものを取り除くことはありませんでした。別のものを作成しただけです。理想的ではありません。

とにかく、対処しましょう。Merge、Confirm merge、Merge、Confirm merge。

これが将来かもしれません。将来のエンジニアリングやソフトウェアエンジニアリングは、基本的にここに座ってマージリクエストを確認することかもしれません。

この人がマージコンフリクトを作成したのが見えます。なぜなら、最初のものを他のものより前にマージしたからです。ここで今、それは混乱しています。「oh wait a second, which one of these is it」という感じです。

実際にこれを行います。「Mark as resolved」します。基本的にOpenCVとpupil april tagsを持つことになります。

OpenCV Pythonについて、どれが欲しいか実際に見てみましょう。ここに入って、release historyを見ます。

4.11は1月16日にリリースされました。そのバージョン4.11.0.86を試してみましょう。「Mark as resolved」します。

sidが「claude code is cli integrated just like open source local codex but you can install it on cursor just an advice that pro plan exhausts way faster」について話しています。現在Gemini 2.5 Proにしていると思います。

Gemini 2.5 Proは私にとって最高のコーディングモデルのようです。GPTには本当に良くなる可能性がありますが、時々使用できないほど怠惰です。すべてのような怠惰で手抜きなことを行い、使えないことがあります。

Gemini 2.5 Proでは、OpenAIが行ったような後トレーニングステップがあったようです。基本的に、作成されるトークンが多すぎることを嫌がっているようです。多くの顧客の問題があり、すべてのこの推論に対して支払う必要があるため、OpenAIには任意のクエリに対して生成されるトークンの量を基本的に最小化するインセンティブがたくさんあります。

おそらく基本的に長い思考の連鎖を嫌がるRLHFやこの時点でRLを導入する後トレーニングステップを導入したと思います。コードのようなものがある場合は、「oh fill in the rest of your code here」と言って要約しようとし、ちょっと使用できなくなります。

Gemini 2.5 Proには、それがないようです。GoogleはTPUがたくさんあるため、気にしません。とにかくすべてを基本的に補助しているので、怠惰ではなく、コーディングに問題がありません。現在、これが最高だと思います。

パーソナルアカウントとLLMエージェントの問題

「Mixing personal accounts with LLM agent PR seems like a great way to make a mess」について、すでに混乱しています。だからこそ、私の実際のコードを編集してほしくなかったので、別々のファイルで行うよう求めました。

ariesが「The future of dev is a tedious conveyor belt monitoring service」と言っています。かなりその通りです。基本的にここに来て、異なるエージェントからのプルリクエストをレビューするだけに時間を費やすことになりそうです。

バッチ可視化の確認

「Notice it too. Gemini 2 tends to create new files and editing old ones. Can you just tell it to remove the old file? Save tokens 50% waste tokens」

ここに戻りましょう。取得しました。実際にこのことを求めました。バッチのものを可視化しようとしていました。実際に何を行ったか見てみましょう。

この「visualize batch」を作成しました。この、このスタイルが本当に嫌いです。このように何でもコメントでばらまいているのが。なんて汚いんでしょう。とてもひどいデザインです。

design imageです。それは正しいです。ここで更新すべきです。配列をコピーするのは気に入りません。理想的ではありません。CV2を依存関係として使うのも気に入りません。本当に重い依存関係です。文字通り円のためだけに使用しています。

CV2をインストールすることになると思います。

Git管理とマージの課題

ここで問題は、ここでローカルに変更を加えましたが、マージした2つのプルリクエストがあることです。実際にこれを行う最も簡単な方法は、「git stash」を行うことです。

git stashは基本的にここでローカルに行ったすべての変更を取得し、小さなstashに置きます。その後、「git pull」を行い、2つのコーディングエージェントから行った変更をプルします。その後、「git stash apply」を行い、変更を再適用します。

これを行った理由は、マージコンフリクトを作成したくなかったからです。これが本当にイライラすることになると想像できるのは、あなたのために働いている複数のエージェントがいる将来を考えることです。基本的に行って自分のことを行っています。とても面倒になるでしょう。

人間の間でさえ、とても面倒になることがあります。同じコードベースで複数の人が作業していると、常にこの種のマージコンフリクトに終わり、PRを入れようとしていて誰か他の人もPRを入れようとしているマージ戦争のようなものに終わります。あなたのPRを最初に入れたい場合、あなたが最初にPRを入れれば、彼らがマージコンフリクトに対処しなければならなくなるからです。本当に面倒で迅速になることがあります。

すでにそこで、これは基本的にコーディングがどのようなものかのプレビューです。10の異なるエージェントが同時にコードをプッシュしている際に対処しなければならないもののいくつかで、これらの本当にイライラするマージコンフリクトです。

新しい依存関係のインストール

最初に行わなければならないことは、これらの新しい依存関係をインストールすることです。

ここに来て、これを行います。新しい仮想環境を作成します。この新しい仮想環境をsourceします。これで、この仮想環境を作成したのが見えます。pi projectからインストールします。ここで「-r」が必要だと思います。

覚えているなら、基本的にこれら2つをここに追加しました。これは本当に高速です。依存関係マネージャーとしてのUVが大好きな理由です。とても高速です。

これらの依存関係をインストールしたので、Tapbotを実行できるか見てみましょう。おそらく実行されないでしょう。エラーがあるでしょうが：

「uv run python tapbot」

うまく初回で動作しました。Cursorが良い仕事をしています。

ここに行きましょう。リフレッシュします。ここで見ることができます。これはGPUを使用している場所です。失敗しました。何かが起こりました。間違ったポートにいるだけです。

Windows環境での作業

現在、Windowsコンピューターにいます。本当に必要ではありませんが、ストリーミングセットアップがあるコンピューターです。このCursorは実際にLinuxボックスで実行されています。3090が入ったLinuxボックスがあり、visor（ビューワー）は実際にLinuxボックスで実行されています。

Cursorは自動的にポートを転送するため、8080をWindowsコンピューターに転送します。Windowsコンピューターでブラウザを開いて、森の真ん中に浮かんでいるロボットを見ることができます。森のHDRIを少し追加しました。ロボットが森の真ん中に浮かんでいるのはかっこいいと思うからです。

ここで見ることができます。今は「batch index」と呼ばれています。少し大きくしてこのUIを見えるようにしましょう。バッチを選択できます。1つにしてみましょう。

円を作成するかどうか見るためにここを見ています。ワークモードに行ってみましょう。見てください！実際に行いました！

とても良いです。これが正しいかどうか実際にはわかりませんが、見てください。画像をパッチごとに進んでいるのが見えます。各個別ピクセルに行って個別にIKを計算する代わりに、特定の領域、特定の半径を持つ領域に行き、その領域のすべてのピクセルでバッチを作成し、その全体のバッチを一度に行っています。

これにより効果的にGPUを使用し、はるかに良くなります。それがすぐに動作したことに本当に驚いています。全く動作せず、多くのものをデバッグしなければならないと期待していましたが、文字通り初回で動作しました。これはちょっと驚くべきことです。

モデル設定の確認

hampusからの質問：「auto is not the same as gemini 2.5 pro is it」について、設定しているかどうか見てみましょう。

model、cursor model settings、disable fallback models usage。pricing modelを見せてください。メニューがあるのですが、メニューが何と呼ばれるか忘れてしまいます。本当にイライラします。

ここに行ってみましょう。cursor settings、model settings。見てください！

基本的にすべてを選択解除し、これだけを使用するよう指示しました。autoと言うときは、選択できる唯一のものであるため、基本的にGemini 2.5 Proのみを持つべきです。

「what model are you」と尋ねてみましょう。それを教えたがりません。これはおそらくシステムプロンプトにあります。

autoを選択解除し、今では自動的にGemini 2.5 Proに行きます。hampusさん、正しいかもしれません。「you didn’t get a thinking stream it was gemini 2」について、この全体の時間、garboのcursorモデルを使用していただけで、それでも動作します。

2.5 Proを本当に気に入りません。これは嫌悪感を催すほどです。

Visorコードの修正

「Make this less verbose, less lines and remove comments」について、この関数はPTSDを与えます。

今、より短いバージョンを作成しました。元のバージョンが不必要に長く汚かったため、これは良いです。

おそらくここでこのコードを再確認すべきです。これを取り除きましょう。

別のマシンに行かなければなりません。host 97に接続します。これはmirkatです。

97はこのマシン、mirkat miniで、実際にreal senseカメラに接続されているマシンです。2つのコーディングエージェントが作成したApril tagコードを確認するために、それにSSHする必要があります。

パスワードを再度求められるでしょう。自動的にポートを転送し、これは8081になります。

April tagコードのテスト

Tapbotに行きましょう。pullします。多くの変更があります。deactivateして、現在の仮想環境を削除します。ロックファイルも削除します。ロックファイルは基本的に、インストールしている特定のバージョンがここにあることを示しています。

新しい仮想環境を作成し、仮想環境をsourceし、「uv pip install -r pi project」を実行します。これは少し長くかかるかもしれません。実際にはかなり高速でした。OpenCVを何度もインストールしているため、すでに準備ができていました。

この2つのうち、どちらを最初に試しますか？april tag codexを試しますか？最初にそれを試してみましょう。

「python april_tag_codex.py」

これは8081で、空のシーンです。それは問題ありません。「more than one new minima found」。

ここに何も見えません。何かが起こったでしょうか？

「python april_tag_jewels.py」を試してみましょう。

「no module named april tag」。Jewelsはここで依存関係を作成しただけです。「import april tag」。どのapril tag検出オプション？april tag依存関係を作成しただけです。

maybe「import pupil_april_tags as april_tag」を試してみましょう。動作するかもしれません。

「visor server has no object attribute get_url. do you mean get_port?」

これはすでに非常に悪くなり始めています。基本的にAPIを作成しているのが見えます。

「can’t open camera by index. attempting to open camera device ls /dev/video」。dev video zeroがあるはずです。そこに見えます。「rs-enumerate-devices」も行えると思います。2つのreal sensesがここにあります。

この依存関係を行い、それからこのことを間違えたという事実だけで、私は本当に心配になります。これが実際に正しいとは思いません。

これは正しいでしょうか？「add_camera_frustum」があるでしょうか？実際のvisorドキュメントに行ってみましょう。これは実際の関数でしょうか？それは実際の関数です。

これについてはどうでしょうか？これは実際の関数でしょうか？いいえ、見てください。これも作成しました。

Cursorがこれを修正できるか見てみましょう。

「Can you fix the visor code in this file? I know for a fact that tapbot works」

チャットコメントへの対応

shivamが「where did the paper sessions go」について、論文セッションが終わったと感じているのです。これらのものに論文を投入できるようになったため、論文読書をする意味がもはやないと感じているからです。論文についてもっと学びたい場合は、これらのモデルに論文について尋ねることが最良の方法です。

また、この新しい種類のコーディング形式に切り替えている別の理由は、論文がある程度準備が必要だったからです。また、最終的には研究者ではないということもありました。若い頃はそうでしたが、今日では、論文を読んで考えてよりアカデミックになるよりも、構築しようとするアイデアに取り組もうとしています。より建設者になろうとしています。

ストリーミングに使用する予定だった時間を取って、論文を読んで話すのではなく、プロジェクトで作業するために使用できるなら、私にとってはより有用だと感じます。

論文ストリームではなくコーディングストリームを行うことには少し利己的な要素があり、学んでペーパーを読むよりも、これらのコーディングツールを使って作業に時間を費やす方が私にとって有益だと感じるからです。

同じではないことはわかります。コーディングストリームは一般的にペーパーストリームと同じ魅力を持っていないことは知っています。しかし、それでも構いません。とにかくこれでそれほど多くのお金を稼ぐわけではありません。

「Great ASMR in the background」について、より良いASMR音声で作業する必要があります。

Visorコードの問題

これを見てください。何だこれは？「transformation from camera optical frame」？すごい、そんなものは必要ありません。すべて拒否します。

april tag codexに戻りましょう。すでに初期の段階で、これは必ずしも正しくありません。

これを行いましょう。「add a gui image of the color frame」と言って、例を与えます。visorの例に行き、全体のexampleフォルダを与えます。適切なものを見つけることができることを願っています。

「I’ll start by raising the image example」。guiイメージハンドルカラーイメージを追加するつもりです。受け入れましょう。「add image got an unexpected keyword argument image_format」を追加します。

選択してチャットに追加し、Enterを押します。これがvibeコーディングの方法です。自分の問題を解決するだけです。

「Confirm search. How about auto search」。これは私が望んでいたことです。インターネットに行って実際のドキュメントを見つけて検索してほしかったのです。JewelsもCodexもどちらも行わなかったようです。Jewelsは基本的に完全に多くのクラップを作成しただけです。

「Web search confirmed that server.gui is the correct API」。どのような変更をしたいですか？それを取り除きたいだけです。受け入れます。

「run got an unexpected keyword argument max_width: ’40vw’」。それは何ですか？どこから来たのですか？「image」と意味したのでしょうか？

ここで手動編集を行います。時間がかかりすぎていたからです。

「initializing real sense」。開いています。見てみましょう。カラーイメージはただの黒い四角です。

「set image」に戻りたいです。相棒、それをしてエラーが出ます。

今、エラーをチャットに追加します。どのように自信を持って間違っていたかが見えます。「double check with the examples」と言って、visorのexampleフォルダを再度与えます。

これが私が言及していたことです。これらの小さなモデルは、特に本当に理解していない多くの依存関係で、長年にわたって100万のバージョンがあるため、非常に自信を持って間違っていることがあります。変化し続けるので、常に混乱します。

ここに依存関係を準備しておくことで、フォルダをドラッグアンドドロップできるようにすることで、少し良くなると感じています。

example 2で答えを見つけたのが見えます。

これはまだ完全にクラップです。カラーイメージはただ黒いです。

「camera poses」がありませんか？何らかのカメラビューワーのようなものはありませんか？巨大な潜在的問題のようです。

まだ黒い四角です。「check the data types. sometimes」について、これがuint8であることが見えます。real senseカラーチャネルから出てくるものがvisorが期待するものと異なる可能性があります。

実際にこれは別のトリックです。「add a bunch of debug logs so we can verify」と言えます。エージェントに基本的にたくさんのログをあらゆる場所に置くよう指示できます。これを実行すると、基本的に今度はログがあり、それを与えることができます。

自分の問題を解決する方法がわからない場合、ここでたくさんのログを作成させます。実際に全体のクソ画像を出力しているのが見えますが、このようにして、今それをチャットに追加できます。今それを持っています。ログがあります。

人間としてログがあればデバッグが簡単になるのと同じで、これらのコーディングエージェントにとっても同じ状況です。

今、ここで何らかの500 IQ理論を思いついているのが見えます。問題を解決しましょう、相棒。何をしたか見てみましょう。

このクラップをすべて見てください。宇宙の秘密を発見しているようです。はい。たくさんのクラップを行いました。さらにたくさんのクラップを行いました。受け入れます。

見てください！解決しました。全体の画像を印刷するこのプリントはどこですか？それが欲しくありません。ログを汚染します。「gui image handle after create」、これだと思います。ログを汚染するこれらの値を取り除きましょう。

いいえ、そのものではありません。これらの値で汚染するログを取り除きます。それを理解してもらうことができます。受け入れます。

見てください！取得しました、皆さん。私の腕が見えるはずです。なぜ私の腕を見ていないのでしょう？これがApril tagです。そこのApril tagをキャッチできるはずです。

あと15分ありますか？

April tag検出の問題解決

「remove the verbose camera logging. the image seems fine now and add logging around the detections so we can debug that」。april tag jewelsとapril tag jaxleyも取り除きましょう。それを削除します。

今、その周りにログを追加したのが見えます。実行してみましょう。何も検出していません。

最初にできることは、カメラを下向きにすることです。より良いビューを得ることができると思います。このオーバーヘッドreal senseを変更します。そこの小さな銀色のものです。基本的に下向きにして、April tagを見ることができるようにします。

下向きにしたので、このものは反対側でまだ爆発しています。ここに戻りましょう。実行します。より良いビューが必要です。

今、3つのApril tagsの非常に明確なビューがありますが、検出していません。間違っている可能性のある一つは、April tagsにはApril tagsの異なるバージョンがあることです。

ここで「families tag36h11」と書かれているのが見えます。これは正しいApril tagファミリーではないかもしれません。実際にどれなのか覚えていませんが、これらのモデルの一つに行ってもらうことができるかどうか見てみましょう。

これをスクリーンショットして、ここのGPTに入れて、クレイジーなことを試してみます。スクリーンショットしてコピーして、ここに置きます。

「what april tag family is this」。Grockでも試してみましょう。Geminiでも。どのモデルがそれを取得するか見てみましょう。コピーしてそこに貼り付けます。そこに貼り付けます。

これらのフロンティアモデルの一つがApril tagファミリーが何かを理解できるなら、とてもクレイジーでしょう。基本的にApril tagファミリーが何かを判別できるはずです。

「Think」にしてみましょう。「deep search」にしてみましょう。これらのうちの一つがこのApril tagファミリーが何かを理解できるかどうか見てみましょう。

「41h12 sounds like a hallucination」。それは41h12ではありません。これらは36h11でもないと思います。16h5だと思います。これらは16h5だと思います。

それが答えです。GPTは基本的に幻覚的な答えをくれました。Geminiは36h11をくれました。これは理にかなっています。モデルが仮定したのは、おそらく最も一般的なタイプのApril tagだからです。

より多くのピクセルをここのApril tagに持つほど、より多くを持つことができます。例えば、図のロボットキャリブレーションで使用されるのを見たことがあるかもしれません。彼らのビデオの一つで、ヘッドの製造プロセスを示し、ある時点でヘッドがApril tagsで満たされた壁を指しているのを見せました。

April tagsの壁がある場合、例えば36h11のようなApril tagファミリーが必要です。587の固有のApril tagsを持つことができます。しかし、このTapbotプロジェクトでは、587の固有のApril tagsは必要ありません。最大で3つか4つしか使用しません。

より少ないピクセルを持つほど、検出が簡単になります。このようなピクセルが少ないということは、より遠くから検出が簡単になり、検出も高速になることを意味します。

OpenAIは幻覚的な答えをくれました。Geminiも幻覚的でしたが、少し良い答えでした。これはおそらく統計的に最も一般的なタイプのApril tagだからです。Grockが何を言ったか見てみましょう。

Grockはまだ考えています。Grockは少し良い答えをくれました。「tag25h9」を予測しました。しかし、これはtag16h5だと思います。

実行してみましょう。皆さん、いくつかの検出が来ました！見てください！完璧です。それが私を幸せにします。

カメラフレームの作成

「create a different frame for the camera and each of the detections. there should be three april tags」について。

Hampusさん、私が正しいモデルを使用していなかったことを教えてくれて本当に良かったです。この全体の時間、おそらくGemini 2.5 Proを使用していると思って、このgarboのcursorモデルを使用して一日を費やしたでしょう。

ゴミと呼んでいるのは理由がないのかもしれません。tatbotのバッチ可視化を作成することができたからです。

「Gemini loves to talk」について、これが私が言っていることです。とても冗長です。小さなyapperのようです。話して話して話すのが好きです。お金とTPUがたくさんあるので、気にしません。

「Create three frames, create 3D」。提案された変更があります。それを行ってください。約5分で行かなければなりません。

受け入れます。実行します。接続しています。

理想的ではありません。異なるIDを取得しているのが見えます。これをカバーします。これはそうすべきではありません。カメラfirst roomが好きですが、これらの検出で何が起こっているのでしょう？あらゆる場所にあります。

配信のまとめ

とにかく行かなければなりませんが、楽しかったです。今日やったことの小さな要約をしてみましょう。

今日は、cursor vs codexというタイトルで、素敵で居心地の良い配信を行いました。基本的に、いくつかの異なる最先端のコーディングツールを試していました。

明らかにCursorを使用し、かなりうまく使用しました。実際に、このバッチされたピクセルターゲットを基本的に初回で実装できたのは、かなり印象的でした。

また、人間の代替スタイルの2つの異なる種類のコーディングエージェントを試しました。OpenAIのCodexとGoogleのJewelsを試しました。

この2つは、良くても中程度、悪ければ貧弱だと言えるでしょう。Googleのものはインターネットにアクセスできないのかわかりませんが、基本的に多くのガベージ依存関係を使用していました。基本的にAPIを作成していました。

また、外部依存関係を使用する代わりに、一からこの全体のようなことを行っていました。それはかなり悪かったです。他のことを行うよう求めると、元のファイルを修正するのではなく、2番目のファイルを作成しました。Jewelsには良くありません。

また、1日に5つのタスクという日次タスク制限があるのが見えます。悪いだけでなく、レート制限もあります。Jewelsについてはわかりません、皆さん。

OpenAI Codexはまあまあでした。与えてくれたコードは実際には動作せず、基本的にCursorに修正してもらう必要がありました。しかし、完全なプルリクエストを作成したのは良かったです。

Jewelsはブランチを作成しただけで、そのためのプルリクエストを作成する必要がありました。しかし、Codexは実際に行って、すべての小さなコメントやすべてのものと一緒に完全なプルリクエストを作成しました。

現在、最高の最先端コーディングツールをランク付けするなら、Cursor、次にCodex、次にJewelsと言うでしょう。

Claude Codeをテストしていないことは知っています。それもかなり人気があると思います。皆さんもそれを知っています。次の配信でそれを設定するかもしれません。

皆さん、それはほとんどです。行かなければなりませんが、良い金曜日を、その後素敵な週末をお過ごしください。Hampus、Spyrel、Siobhan、Vu、Zoro、Aries、Sid、SHC、Paul、Majettiさん、皆さんお疲れ様でした。

ありがとうございます、Mirage。このアステカの死の笛をもう一度とても静かに吹きます。

コメント

タイトルとURLをコピーしました