DeepSeek V4 Pro 0813

コーディング

0813は、指示がはっきりしていれば比較的すぐに修正へ入ります。

「ここを確認したほうがいい」「この部分を見直せる」といった提案だけで終わらず、そのままコードを触ることが多いです。

古いコードベースでは、この動き方が助かります。

実際のバグは、一つのファイルだけで完結しないことがよくあります。型を変えれば呼び出し側にも影響しますし、インターフェースを変えればテストやエラー処理まで直す必要が出てきます。

0813は、今出ているエラーだけを見るというより、その周辺まで追っていく傾向があります。

ただし、技術的な幻覚は残っています。

実際に、サードパーティ製ライブラリのAPIを別のものに置き換えたことがありました。名前も自然で、引数もそれらしく、コードだけを見ると問題なさそうでした。

ところが実行すると、そのAPI自体が存在しませんでした。

こういう間違いは、分かりやすい構文エラーより厄介です。

そのため、今でも diffは自分で確認し、テストも必ず回す ようにしています。

長いタスク

個人的には、ここが0813で一番使いやすくなった部分です。

作業が長くなると、コード、ログ、仕様、テスト結果、途中で修正したファイル、新しく追加された条件などが一気に増えてきます。

以前は、こうしたタスクをあらかじめ細かく分けて渡すことが多くありました。

能力が足りないというより、途中まで進んだあとで「なぜこの修正を入れたのか」が抜けることがあったからです。

すでに除外した方法をもう一度試したり、互換性のために残した処理を後から消したりすることもありました。

0813では、そのあたりが少し安定しています。

前半で決めた条件を後半でも引き継ぎやすく、新しいエラーが出ても、すぐに方針を全部変えることは少なくなりました。

短いプロンプトだけでは分かりにくい部分です。

複数ファイルを直しながら何度かテストを回すと、違いが見えやすくなります。

Agentでの利用

Coding Agentとして使う場合、回答文のきれいさよりも、作業をどこまで自分で続けるかを見ています。

ファイルを読む、コードを直す、テストを実行する、エラーを見る。

この流れ自体は、今では珍しくありません。

0813で便利だと感じたのは、テスト後に別のエラーが出たとき、そのまま次の修正に進むことが比較的多い点です。

毎回こちらから「続けて」と言わなくても進むので、その分だけ手が止まりにくくなります。

ただ、Agentの出来はモデルだけで決まるものではありません。

ツールの定義が曖昧だったり、引数が分かりづらかったり、失敗時の情報が足りなかったりすると、当然うまく動きません。

最近はAgentが不安定なとき、モデルだけでなくツール側も先に確認するようになりました。

Preview版と比べると、短いタスクでは大きな差は感じませんでした。

チャットや小さなコード修正なら、体感はかなり近いです。

違いが出やすいのは、実際に修正を進める場面です。

Preview版は、問題の分析や修正箇所の指摘までは正しくても、そこで止まることがありました。

0813は、そのまま該当箇所を変更するケースが増えた印象です。

もう一つは、途中で方針を変える頻度です。

Preview版では、ある程度修正したあとに新しい問題が出ると、別の方法へ急に切り替えることがありました。

新しい方法が間違っているとは限りませんが、それまでの修正が扱いづらくなることがあります。

0813は、まず今の変更をそのまま使えるか確認してから別案へ移ることが多くなりました。

普通の会話ではほとんど気になりませんが、実際のプロジェクトではこちらのほうが扱いやすいです。

良い点

0813は、ある程度長い作業をそのまま渡しやすくなりました。

以前ほど細かくタスクを分けなくても、途中の流れを保ちながら進められることがあります。

また、分析だけで終わらず、実際の修正まで進みやすいのもCoding Agentでは使いやすい部分です。

気になる点

技術的な幻覚はまだ注意が必要です。

特にサードパーティ製ライブラリ、バージョンによる違い、あまり使われていないAPIは、そのまま信用しないほうがいいです。

文章生成については、技術説明なら特に困りません。

一方で、ブランド向けの文章や会話文、日本語の細かいニュアンスが重要な文章では、別のモデルも一緒に比較したくなります。

また、Agentにすべて任せられるわけでもありません。

データベース、決済、認証、権限、セキュリティ、主要な業務ロジックなどは、今まで通り人が確認する必要があります。

0813は、普段から既存プロジェクトを保守している人には試す価値があると思います。

特に、複数ファイルにまたがる修正、長いデバッグ、移行作業、コードとログを一緒に扱う仕事とは相性がいいです。

Coding Agentを作っているチームにも向いています。

ただし、ファイル操作、ターミナル、テスト、エラー出力などのツール周りがある程度整理されていることが前提です。

すでにAPIベースのワークフローがあるなら、ベンチマークを見るより、実際のタスクをいくつか流してみたほうが判断しやすいです。

逆に、用途がチャット、要約、短い文章作成が中心なら、0813を選ぶ理由はそれほど強くありません。

最初の回答だけで「世代が変わった」と感じるタイプでもないです。

自分の中では、0813は最初から目立つモデルというより、

少し面倒な仕事を長く任せたときに、前より扱いやすくなったと感じるモデルです。

コードを完全に任せて確認しなくていい段階ではありません。

任せる範囲は広げられますが、最後の確認はまだ必要です。