マーケティングの言葉からは、質に自信がなくて量をアピールしたいみたいに感じるね。でも、俺も同じ立場だから、4500トークン/秒の使い捨ての回答を1時間かけてキュレーションするより、正しい答えを10トークン/秒で得られる方が嬉しいよ。ベンチマークのパフォーマンスは、遅延よりも100倍重要だと思う。もしこれらの「ホットテイク」がMorphの開発哲学にまで及ぶなら、ユーザーじゃなくてよかったと思う。

それは状況によると思う。開発者がフロー状態を保つために測るべき実際の要素があるからね。多くのエラーや遅延がこれを壊す。簡潔に言うと、はい、精度が最優先だよ。質は主に2つの方法で測定される：1) エンドツーエンド：ユーザーのクエリからタスクの解決まで。これは実際のタスク完了の質問に答えるスタイルのベンチマーク。2) 質の適用：構文の正確さ、文字の差異など。大きなモデルと速いモデルのエラー率は約2%だよ。もし非常に複雑なコード編集やマイナーな言語を扱っているなら、大きなモデルがより良い選択だね。タスクに最適なモデルにルーティングする自動オプションもあるよ。

推論が約50%速くなることは、単一桁の精度向上よりも、俺のワークフローにとってずっと価値があると感じてる。どうせ変更が正しいか確認しなきゃならないなら、より早く多くの反復を行える方が、段階的な精度向上よりもずっと良い気がする。ただし、明確な転換点はあるよ。精度の向上が高すぎて、作業をあまり注意深くチェックしなくても良くなるなら、推論速度の利点はほぼゼロになるね。

スローはスムーズで、スムーズは速い。

私の理解では、これは±300msじゃなくて、300ms対10秒みたいな感じだよ。それって大きな違いだよね。個人的には、こういう大きなモデルを待つ時間が制約になってると思う。これって、比較的簡単なタスクに対してリソースの無駄遣いかもしれないし。（LLMの一般的な機能近似と比べて）でも、正直言って、賢く編集を適用するタスクは伝統的なコーディングタスクの範疇に入ると思うんだけど、何がそんなに難しいの？賢いdiffアルゴリズムでできないの？

速いモデルを使った後に遅いモデルを使うのは耐えられないって認めざるを得ない。質と速度が線形に関係しているかはわからないけど。

コーディングにはOpusを使わないで、Sonnetの方が好きだな。多くのタスクは反復や監視があった方がうまくいくし、Sonnetがそれを可能にしてくれる。

レビュー時間がボトルネックになってるみたいだね。今、コーディングエージェントの出力をレビューするのをもっと速くするためのものに取り組んでるんだ。もし時間があれば、あなたのワークフローについてインタビューしたいな。ここに返信するか、プロフィールにある連絡先を見つけてね。-- ジミー・コッペル博士

完全に同意するよ。AIモデルから提案された変更セットを受け取ったら、まずは慎重にレビューするのが最初のステップだよね。大抵の場合、特定のトークンや文脈をスキップしちゃうから、コードが重複することが多いんだ。それをユーザーがプロンプトに含めなかった場合もあるし。変更を一括適用するのは、デバッグがさらに難しくなるコードを作るだけだし、そんな大量のコードインジェクションは、思ってるより早くコードを壊しちゃうよ。B、サム

現在リストされているv2モデルはmorph-v3-largeを指してるよ。v3-largeとv3-fastをリストするために彼らと協力してるところだ。