DeepSeek-V4-Pro, Kimi K2.6、GLM-5.1：3つのLLMがバイブコーディングロングコンテキストに挑戦

Kimi との最初のセッション。タスク：メソッドを実装する`resolveActiveKey()中に`codebase.kt— APIキー解決関数にCLIフォールバック付き。コンテキストは30Kトークンで、Kimiは素早く推論し、キーの有効期限管理を含むクリーンなコードを生成します。

コードはコンパイルされます。7つのテストケースがパスします。私は楽観的です。

2番目のセッション。コンテキストは交換とともに~90Kトークンに増加します。Kimiに、書き込む前にシークレットを匿名化するAsciiDocスナップショットメカニズムを追加するよう依頼します。

ここでそれが脱線する。Kimiは存在しないクラスを考案し始める。彼は私に提案する`AnonymizedObjectMapper`— 架空のクラス。 彼は混同する`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. 彼は私にインポートすることを提案します。com.fasterxml.jackson.anonymize.*— 存在したことのないパッケージ。

もっと悪いことに：彼の思考の段階で、彼が誤った前提に基づいて論理を構築しているのがわかります。彼は「思い出す」が`GitConfig`畑を持っている`anonymizedToken`— いいえ、それは`resolvedToken(). 彼は…に帰する`SiteYmlAnonymizer`方法`maskSupabaseCredentials()— 存在しない。

_ それはバグではなかった。それは一貫性の段階的な崩壊だった。まるで、コンテキストに追加される各トークンが、最初の30,000の記憶を少しずつ薄めていくかのように。 _

Kimiを2セッション後に停止する。診断は明らかだ：MLAはKVキャッシュをうまく圧縮するが、細粒度のスパース選択メカニズムがないと、注意は60Kトークン以上で機械的に薄まる。各トークンは「見る」遠いコンテキストをますますうまくできなくなり — そして、ノイズで穴を埋め始める。

違いは根本的です。Kimiが歴史を単一の潜在空間に圧縮し（その結果、関連情報を識別する能力を徐々に失うのに対し）、GLMは事後トレーニングのインデクサを接ぎ木し、明示的なスパース選択を行います。

技術レポートは明示的に述べている：DSAは "lossless by construction" — それに対して、SWA（パターンサーチ）、Gated DeltaNet、SimpleGDNなどの代替手段はRULER@128Kで最大5.69ポイント損失する。

GLM-5.1は距離を保つのが得意です。セッション11（約60Kトークン）では、一貫性を保っています。それは…​を生成します。`SnapshotManager`機能的で、4つの匿名化ツールの管理が正しく行われている。

しかし、遅延は問題です。DSAの思考フェーズは純粋なMLAよりも重く — インデクサは各ステップで履歴を再スキャンする必要があります。Kimiで8秒かかった回答が、GLMでは15秒になります。30メッセージのセッションでは、これがはっきりと感じられます。

そしてそこに微妙な誤りがあります。GLMはKimiのように妄想をしないが、*命名*の間違いを犯す。彼は呼ぶ`toAnonymizedYaml()呼び出すべきメソッド`anonymize(). 彼は逆転する`loadReadmeConfiguration()` et loadCodebaseConfiguration()`の 中`renderFileSection(). これは幻覚ではなく、表面的な混同です — ただし本番環境では、表面的な混同がビルドを壊すことがあります。

GLMと3回のセッションを行った。それはKimiよりも間違いなく優れている。しかし、命名の詳細に関する手動修正を3回行うのは疲れる。

2レベルの圧縮、2段階の注意の粒度：

結果: 1Mトークンあたり、DeepSeek-V4-Proは消費するのは～だけ27%の推論FLOPs et 10% の KV キャッシュのサイズDeepSeek-V3.2 と比較した場合の、以前のモデル。

特に、技術レポート（図9）は発表しています： `Retrieval performance remains highly stable within a 128K context window.

私はDeepSeek-V4-Proとともに8回のセッションを過ごしました`codebase-gradle`. 8回のセッションで、幻覚ひとつもなく、でっち上げたクラスひとつもなく、命名の混乱ひとつもなく。

セッション 1 : 実装`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350行のKotlin、インラインテスト、すべてコンパイル。セッション4：追加`SnapshotManager`ツリービュー, ファイルの収集, ファイルごとのAsciiDocレンダリング。 279行、ゼロエラー。 セッション7: デバッグの`renderFileSection()`4種類の異なる匿名化ツールを解決における曖昧さなく管理しなければならなかった。3つのメッセージで解決した。

レイテンシはよりも高い Kimi — 思考モードでの1回の回答あたり約10〜12秒。ただし、修正率はほぼゼロ。私はエージェントのミスを直すために時間を費やしていません。私は彼と とともに コードを書いています。

セッション8では、累積コンテキストが100Kトークンを超えます。私は重いリファクタリングを要求します：インライン検証の4つのタスクを抽出するの`build.gradle.kts`JUnit5テストファイルへ向かって`buildSrc/src/test/`.

エージェントは、3段階の計画を提案しています：

プランは正しい。実行はきれいだ。さらに私が見逃していたエッジケースも特定している：Jackson の依存関係が重複している部分の間で`buildscript {}` et `buildSrc/build.gradle.kts`移行中に統一しなければならないもの

100K トークンのコンテキスト、そしてエージェントは思い出すが`CodebaseYmlAnonymizer.TOKEN_MASK`です`"*"`, が`GitConfig.resolvedToken()は 拡張関数 が 定義されている`readme.kt、そしてそれが`SnapshotManager.PRUNED_DIRS`除外する`build`, .gradle et .git。

それが違いです。

支援されたソフトウェア開発は、長文脈注意のための*極端*なユースケースです。必要なもの： - ローカルな精度 (このクラスは何を継承しているのか？このメソッドはどこで定義されているのか？) →放送監視委員会 - 全体像（このモジュールはなぜ存在するのか？四つの匿名化ツールはどのように連携するのか？） →HCA

Kimi と MLA だけは局所的な精度を管理するが、60K を超えると全体像を見失う。GLM と DSA は全体像を改善するが、単一レベルのままである。DeepSeek は両方を明示的に組み合わせる。

私のガバナンスシステムは起動時に約30Kトークンのルールとバックログを読み込みます。128Kまでの安定したウィンドウがあるため、DeepSeekはセッションの交換に約100Kトークンの余裕があります。これは、Kimiが劣化なく処理できる量の3〜4倍です。

__ 128Kの完璧な安定性ウィンドウは、私のニーズに正確に合っています：EAGERが30K＋交換が70K＝20〜30メッセージの生産的なセッションで、決してグリーンゾーンから外れません。 (empty)

はい、DeepSeek-V4-ProはKimiより遅いです（11s vs 8s）。しかし、total タスクの時間はずっと短いです。なぜなら、エージェントの幻覚を修正するために20分を費やさないからです。

開発者は回答のレイテンシを測定しない。開発者は「質問を投げる」のと「コードが自分のリポジトリにあり動作する」の間の時間を測定する。この指標では、DeepSeek-V4-Proが3つの中で最も速い。