「オープンモデルは GPT-5.4 Codex を超えられるのか？」とは少し違う問いを試したかった。
その問いは：
自宅のハードウェア上で動く、ローカルモデルの組み合わせ、スキャフォールド（足場）、修復ループ、ルーティング方針によって、私の実際の作業負荷においてフロンティアのコーディングモデルに十分近づけるのか？
要するに：はい、驚くほどでした。私が最初に厳選した 10 タスクの Go の評価セットでは、ルーティングしたローカル処理が 10 件中 9 件のテストに通りました。
リンク：
- little-coder: https://github.com/itayinbarr/little-coder
- この実験のきっかけになった書き物：https://open.substack.com/pub/itayinbarr/p/honey-i-shrunk-the-coding-agent
- GPT-5.4 best-of ベースライン 10/10
- ルーティングしたローカル処理 9/10
- Qwen3.6 + little-coder 8/10
- Qwen30 + little-coder 5/10
- 元のローカル Gandalf ハーネス 3/10
これは公開ベンチマークではありません。私自身の Go リポジトリから取り出した 10 個の実タスクで、ライブリポジトリに触れないようにワークスペースをコピーして使いました。タスクには、CLI の変更、依存関係の強制、埋め込み版数ファイル、クロックの抽象化、エラー分類、SQLite のプリミティブ、マイグレーション、ベースラインのスキーマ作業が含まれます。
## ハードウェア
ローカル構成：
- RTX 5090 32GB：Frodo で Ollama を実行
- RTX Pro 6000 96GB：より大きいローカルの修復／編集役として Gandalf として利用可能
- 5090 上の Qwen3.6 35B A3B Q4_K_M
- Qwen3-Coder 30B もローカルで利用可能
- Gandalf 上の Qwen3-Coder-Next 80B：vLLM/OpenAI 互換エンドポイント経由
5090 上で Qwen3.6 をロードすると VRAM は約 27GB 使用され、埋め込みサービスを稼働させる余裕が残りました。
## 重要だったのはスキャフォールド
最大の改善は、単にモデルを入れ替えただけでは得られませんでした。
それ以前は、Gandalf 周りにより基本的なローカルの Aider 風ハーネスを使っていました。これは同種のタスクで 10/3 しか取れませんでした。役に立たないわけではありませんが、フロンティアのコーディングエージェントと比べて競争力がないのは明らかでした。
その後、ローカルのコーディングモデルは、多くの場合それに十分合っていないスキャフォールドの中でテストされている、という主張を見て、Qwen3.6 35B と little-coder を試しました。
結果は大きく変わりました。
Qwen3.6 + little-coder 単体で 10/8 に通りました。失敗は：
- - 1 つの決定論的なダミークロック／タイマー／ティッカーのタスク
- - 1 つの SQLite タスク（ある実行では失敗したが、再実行では通った）
ルーティングしたローカル処理は、次の組み合わせで 9/10 まで到達しました：
- - デフォルトのローカル実装として Qwen3.6 + little-coder
- - ダミークロック／タイマー／ティッカーの形をしたタスクには Qwen30 + little-coder
- - `goimports`、`gofmt`、`go mod tidy`、`go test -timeout` のような決定論的なハーネス側の修正
- - 狭いコンパイル／インポート／スキーマの失敗には Gandalf による直接のファイル修復
現在のルーティング結果：
little-coder-routed-local: 4.60/5 avg | 9/10 tests pass | $0.00 | 1489s
タスクごと：
001 pass
002 pass
003 pass
004 pass
005 pass
006 fail
007 pass
008 pass
009 pass
010 pass
残っていた 1 つの失敗は、決定論的なダミークロックのタスクでした。タイマー、ティッカー、スケジュールされた締め切り、ゴルーチンの起床、そしてリーク挙動を、まったく正確に合わせる必要があります。ローカルモデルは、デッドロックするか、ティックを間違ったタイミングで届けるかのいずれかになる、もっともらしい実装を作り続けました。
## 驚いたこと
Qwen3.6 は、モジュール規模の Go タスクにおいて Qwen30 より大幅に優れていました。特に Qwen30 が苦労した store／マイグレーション／スキーマのタスクに通りました。
ただし Qwen3.6 が常に厳密にどこでも上というわけではありません。Qwen30 はある実行でダミークロックのタスクを解けていましたが、Qwen3.6 はそれに失敗しました。完全なルーティング実行では、Qwen30 ですらそのタスクは分散のせいで失敗しました。
これで、正しい抽象化は「最良のモデルを選ぶこと」ではないと確信しました。正しい抽象化は「タスクの形状と失敗モードによってルーティングすること」です。
ローカルシステムは次のような判断をするべきです：
一般的な Go モジュール作業 -> Qwen3.6 + little-coder
SQL／ストア／マイグレーション作業 -> Qwen3.6 + little-coder
狭いコンパイル／インポート失敗 -> ローカル Gandalf による修復
タイマー／ティッカー／並行性バグ -> 専用プレイブックまたはフロンティアへのエスカレーション
私は交通整理（トラフィックコントローラ）を手動でやりたくありません。ハーネスがタスクの形状、モデルの選択、結果、修復回数、経過時間を集めて、それを自動ルータに投入すべきです。
## ハーネスで変えたこと
いくつかの実用的な細部が、かなり重要でした：
- 評価はコピーされたワークスペースのみで実行する。エージェントがライブリポジトリに触れることは決して許さない。
- `go test` のタイムアウトを強制する。ダミークロックのバグは、放っておくと永遠にハングし得る。
- 決定論的なクリーンアップをモデルの外で実行する：`goimports`、`gofmt`、`go mod tidy`。
- 修復の編集を機械が解釈可能にする。私は、自由形式のチャットによる修復ではなく、Gandalf には直接の JSON ファイル修復パスを使った。
- テストと testdata は読み取り専用のままにするが、`.sql` や `VERSION` のような Go 以外の実装成果物は許可する。
- 各実行をディスクに記録する：ステータス JSON、テストログ、差分（diff）、そしてレポート。
そして `go test -timeout` のラッパーが特に重要でした。それ以前は、1 つのダミークロック実装の失敗だけで、評価サイクル全体が消費されてしまうことがありました。
## 注意点
これは「Qwen3.6 が GPT-5.4 Codex を上回る」という主張ではありません。
GPT-5.4 はこの切り出し部分で 10/10 でした。ローカルのルーティング処理は 9/10 です。
また、これは 1 つの Go リポジトリからの 10 タスクだけです。私にとっては実際の作業負荷なので役に立ちますが、幅広いコーディングベンチマークではありません。
私が気にしている結果は、より狭いものです：
私の Go の作業負荷において、ローカルでスキャフォールドしてルーティングしたプロセスは、日常的な作業のデフォルト経路になれるほど十分に近づきました。難しいタスクや既知の失敗クラスにはフロンティアモデルを予約します。
これはコストとレート制限にとって大きな意味があります。
## 現在の結論
モデルは重要だが、思っていた以上にスキャフォールドの方が重要でした。
Qwen3.6 35B はローカルで有用なだけの強さがありますが、本当に面白くなったのは次と組み合わせたときです：
- - little-coder
- - タスク固有のルーティング
- - 決定論的な Go 側の修正
- - ローカル修復
- - 実タスクでの評価フィードバック
次のステップは、ルータを賢くすることです：
- - デフォルトで Qwen3.6 を実行
- - ローカルで狭い失敗を修復
- - ダミークロック／並行性／時間意味論はフロンティアまたは専用プレイブックへエスカレーション
- - ログで結果を残し、ルーティング方針が時間とともに改善するようにする
これが現実的な前進ルートだと感じます。Codex を真似ようとする「1 つのローカルモデル」ではなく、それぞれのモデルをいつ、どう使うべきかを知っているローカルなコーディングシステムです。
（私が執筆。codex 5.4 によってより良く書き直されました）
[link] [comments]
