おお…その通りな気がします。

人間もランダムに選ぶのは得意ではありません。パターンがあってはいけないのに、パターンを意図的に避けること自体もパターンと見なせるからです。

実際のトークン使用量を単一の作業について測定した結果はなく、単に magpie を使えば再試行がこの程度減るだろうという推測ですね。

Compilation Time の比較はおかしいですね。なぜ ms/token を比較するのでしょうか？

関連する内容については、時系列の整理が必要そうです。OpenAIは契約交渉が進行中だったという話もありますが？

いつも楽しく拝見しています。ありがとうございます。

Xがクローリングしにくくなっていて、そのようなケースがあるようです。改善してみます

「内容なし」という要約エラーは初めてですね..

私が働いている分野もそこまで極端な分野ではありませんが、AI分野で研究開発をしています。
一般的によく使われるフレームワーク以外にも、実際にモデルをデプロイするターゲット環境が学習していた環境と異なる場合もあります。
特定のオペレーションがサポートされていなかったりして、カスタムオペレーションをプラットフォームごとに作らなければならない場合もあります。この場合、開発した環境でそのままテストできないことも多いです。
モデルを直接設計することもありますが、特定のデータを使ってテストコードを書くことはできても、データセットによって確率的に値が変化したり、特定の時点で値が発散したりする現象は、テストコードでカバーするのが難しいんですよね。
おそらく私よりもさらにテストが難しい環境はかなりあるのではないかと思います。

SQLiteのアプローチは本当に印象的ですね。コードの590倍にもなるテストスイートを非公開のままにしているというのは、結局のところ「ソフトウェアの本当の価値は動作仕様にある」ということですから。

実際、最近のAIコーディングツールでプロジェクトを作ってみると、既存プロジェクトのREADME、APIドキュメント、そしてテストコードさえあれば、コア機能を驚くほど速く複製できます。自分で7つのプロジェクトを運営しながら感じたことですが、テストがしっかりしているプロジェクトほど、逆説的に複製もしやすいんですよね。

ただ、Cloudflare vs Vercelの事例で見落とされている点があって、「複製」と「運用」はまったく別の問題です。Next.jsのエッジケース、プラグインのエコシステム、コミュニティへの依存性まで再現しようとすると、テストコードだけでは足りません。結局、モートはテストコード + コミュニティ + 運用ノウハウの組み合わせなのではないかと思います。

Wow

このプロジェクトは、GCが問題になるほどではないでしょう。「近年の大半のプロジェクト」では、実際のところプログラミング言語の採用は特定言語の長所や限界というより好みの領域であることが多いと思いますが、それでも汎用プログラミング言語としてRustがGoに対して持つ比較優位は何かと問われれば、私はRustが提供する抽象化の水準と、コンパイル時にさまざまなエラーを検出できる点だと答えると思います。もちろんGoにも、Rustに対して非同期プログラミングのしやすさ、コンパイル時間の速さ、簡潔な文法といった長所があります。

同じレベルの契約であっても、信頼度やイメージがずいぶん違って感じられますね。
GPTのサブスクも解約したほうがよさそうですね。

気分悪い、すまん

うわぁ、素晴らしいですね。RustPythonのおかげで対象になられたのでしょうね。良い結果になることを願っています！

Rustはコンパイル時にエラーを捕まえられる割合が大きいので、むしろコンパイル失敗のほうがAIが正しい方向に進むのを助けてくれる感覚がありました

申し込んでみました

まあ、推測ではありますが、Rust への参入障壁がなくなったからではないかと思います。
最大の難しさは、コードを書いてもコンパイルが失敗し続けることですが、それをAIが代わりにやってくれますからね。

Jokeテストだったようですね

DIY、メイカー運動、インディー、パンク、オープンソースはすべて産業化、資本主義、消費主義への反論なのに、その限界を乗り越える方法が消費主義を受け入れることだなんて。