翻訳しておいてリンクを載せていませんでした。

• Jazzband終了のお知らせ
• Jazzband 10年

また参加することになりますね！

https://code.claude.com/docs/ko/model-config#opusplan-モデル設定

私もClaudeのopusplanでモデル設定して使っています

agent が GPT-5.1-Codex-Mini モデルだけを使う状態で、
Codex App の Custom instructions に
以下のプロンプトを追加すると、GPT-5.3-Codex-Spark で agent が動作しますね。

"- when it spawns agents, use models "GPT-5.3-Codex-Spark" or higher."

あるいは agent を作成するときにモデルを指定するのもなかなか楽しく、
Codex App で下位フォルダ構造で表示してくれるのも良いです。

コードを手で書く過程では、開発者は自然に企画もし、設計もし、探索もし、理解もし、テストもし、セルフレビューもし、問題が発生したときの事後対応までを暗黙的かつ並行的に進めながら、各側面を自然に調整しているものです。だからこそ、テストやレビューが多少不足していても、ある程度は回っていたのだと思います。
しかし手で書く過程をなくしてしまうと、暗黙的に存在していたプロセスに明示的な境界を設けなければなりません。コードを書いた主体とレビューする主体がさらに分離されるため、コミュニケーションの非効率も増します。コード作成主体への信頼もより低くなるので、レビューコストもまた増加します。
doorman's fallacy という概念に近いのではないかと思います。

auditlog を便利に使っていたので、悲しいですね…。

些細なことではあるけれど、パッケージマネージャーの名前が pkg であることからして優雅で、UNIXツールのネーミング哲学に合っている感じがする

CLIをサーバーで動かせば同じではないでしょうか？

GPTが今や経営まで一緒にやるんですね
https://replaceyourboss.ai/
導入が急務に見えます

20年あまり前、Webエディタや量産型ブログの流行で誰にも見られないホームページや投稿が大量に生み出されたように、AI時代を迎えた今も似たような様相はあるが、カスタムアプリを作り、そのプロセスやルーティンを共有することは間違いなく素晴らしく大きな資産だと思う。個人的には、今の時代はAIで金になるアプリやサービスを作ることではなく、自分に必要なカスタムツールを手軽に作って生産性を高めることだと考えている。

Oh my opencode の基本設定では、計画は opus が行い、実装はより軽量なモデルが担当します

はい、本文も読まずにコメントしたことを告白します;;

ナムウィキにも関連する文書がありますね（笑）
https://namu.wiki/w/…**

言語モデルなので、高価なモデルが計画を立てるのが適切です。

私の周りでは、Sonnetで計画立案や設計をして、GLM-5でコードを書いているようです..

ブラウザでしか動かしていなかったものをサーバーで直接動かすようになったので、避けられない流れだった気がします

quotio のようにプロキシまでしてくれればすぐ使えるのに……そういう機能はなさそうですね

逆に、推論のほうがむしろ利益が出る商売だという分析もあったようですが...

実際の問題は、トレーニングループにRLのための推論コンピューティングまで追加されて、複雑性が増したことだそうです.

残念ですね、またイベントはやらないんでしょうか（泣）

今クレジットを湯水のように使ってやるのは、たぶん今だけな気がします。