1 つのリポジトリ タスクに対する迅速な判定
この SWE-2 レビューは、私が独自に実稼働リポジトリを通じてモデルを実行したという主張ではありません。エンジニアリング チームが使用するものと同じリポジトリ、権限、デプロイメント条件を持つ Devin ワークスペースがありません。代わりに、コーディング モデルを実際のリポジトリ作業の準備ができているものとして扱う前に確認しておきたい、1 つのタスクのレビューを示します。
私はレナです。私の簡単な判断は単純です。SWE-2 は Devin で評価する価値があるように見えますが、コーディング ベンチマークは決定の始まりにすぎません。有益な質問は、モデルが妥当なパッチを生成できるかどうかではありません。なじみのないコードベースに侵入し、重要な制限を見つけ、最も小さな正しいことを変更し、変更を証明し、最初のパスが壊れたときに回復し、セッション全体を再構築することなく人間がレビューできるものを残すことができるかどうかです。
Cognition では、ベンダー実行結果が FrontierCode 1.1 Main で 50.0%、DeepSWE 1.1 で 73.0%、および Terminal-Bench 2.1 で 92.8% であると報告しているため、この違いは重要です。これらは 2026 年 9 月 10 日のバージョンに関するシグナルであり、チームのソフトウェアの成功率を独自に再現したものではありません。同じ SWE-2 の発売発表 には、デスクトップと CLI が利用可能になり、Web と Fusion が展開されたと記載されています。私はチームが使用する予定の正確な表面をテストします。
Devin で SWE-2 をテストする方法
実際のリポジトリ エージェント テストの場合は、合成プロンプトや広範な機能リクエストではなく、既存の重要な変更を 1 つ使用します。一度にレビューできるほど小さいものである必要がありますが、依存関係を見つけて確立されたパターンを尊重する必要があるほど十分に現実的である必要があります。適切な候補は、再現可能な不合格テストを伴うバグ、狭い範囲の検証変更、または解釈なしで受け入れ基準をチェックできる文書化された動作のギャップです。
開始する前に、Devin サーフェス、選択したモデル、表示されたエフォート設定、日付、コミット SHA、ブランチ ルール、ロックファイル、ツール、ネットワーク状態、および最初の成功または失敗したコマンドを記録します。また、時間を設定して予算を試行し、最初のタスクの後に人間によるプロンプトをすべて保存します。これにより、クリーンなデモが静かに別の実験になることを防ぎます。
リポジトリ、タスク、環境、および受け入れ基準
概要では、動作、影響を受ける領域、および最終ラインを指定する必要があります。指定されたバグを再現し、互換性のある最小限の変更を加え、回帰テストを追加または調整し、所定のチェックを実行し、レビュー可能な差分を返します。通常の譲受人が知らない限り、ファイルに名前を付けるべきではありません。私なら、アクセスの欠如をモデルの失敗と誤解するのではなく、必要なレジストリ、シークレット、またはブラウザのログインを事前に宣言します。
ベースラインは正直である必要があります。タスクの前にリポジトリが構築されない場合は、ログを保存して、その失敗をエージェントが作成した失敗と区別します。指定された受け入れコマンドが赤色のままの場合、緑色のサブセットはカウントされません。現地の指示やテストがモデルの指針となる場合もありますが、それらは記録に残ります。
SWE-2 は編集前にコードベースを理解できますか?
最終的なコードだけでなく、パスも検査します。強力なセッションでは、編集前に、実行パス、関連するテスト、構成境界、および近くの規則を特定します。それで終わりのない探索が報われるわけではありません。認識によれば、FrontierCode で実行される SWE-1.7 よりも前に編集された SWE-2 メディアが表示されます。速度が重要になるのは、スキップされた読み取りが無関係な場合のみです。
制約、依存関係、既存のパターンの検索
私は、パブリック API の動作、エラー処理、認可、データ形式、下位互換性、または同等の規約など、何を保持する必要があると考えているかを尋ねます。次に、その回答をリポジトリと比較します。実際の呼び出し元を見つけ、確立されたテスト ヘルパーを使用し、機能フラグ、生成されたアーティファクト、移行、またはパッケージ境界に気づきましたか?
実際のリポジトリ エージェント テストのこの部分では、自信があるように聞こえるためのスコアではなく、証拠を提示する必要があります。有用なアーティファクトは、検査されたファイル、名前が付けられた制約、およびスコープがそれらに一致する差分です。驚くほど短い探索も素晴らしい場合があります。長いものでは、パッチを安全でなくする依存関係を見逃す可能性があります。たとえテストが合格したとしても、要求された領域以外の説明のつかない編集はレビューの結果として扱います。
SWE-2 は検証済みの変更を提供できますか?
実装では、SWE-2 コーディング モデルが責任を負う必要があります。最小限のパッチ、それがないと失敗する回帰テスト、そして実際のリポジトリ環境からの出力を探します。インターフェイスやワークフローについては、ユニットのカバレッジがすべてを物語ると仮定するのではなく、簡単な手動チェックを 1 つ追加します。
実装、テスト、および最終的な引き継ぎ
ハンドオフには、何が変更されたのか、なぜ変更されたのか、何が実行されたのか、何が不確実なままなのかが記載されている必要があります。明確なプル リクエストの説明は証拠ではありません。新しいチェックアウトまたは CI ジョブから受け入れコマンドを再実行し、無関係なチャーンを検査し、ブランチ保護がまだ適用されていることを確認します。
私はどの貢献者にも同じ基準を求めます。つまり、発明された合格テストがないこと、実行されたときに利用できないサービスが主張されていないこと、自信のある概要に隠されたスキップされたコマンドがないことです。 NIST Generative AI Profile も同様に、一般的な機能ラベルではなく、コンテキストとリスクに基づいて評価を組み立てます。これは、Devin または SWE-2 の調達に関する評決ではありません。
人間の介入が依然として重要な場合
人間の介入は測定です。この実際のリポジトリ エージェント テストでは、コーディング エージェントの人間の介入を名前付きイベントとして扱います。つまり、人間が要件を明確にし、期待される許可を付与し、環境を修復し、規約を説明し、有効な製品動作のいずれかを選択するか、診断を修正します。それらを 1 つのカウントにまとめると、エージェントの見た目が悪くなるか、以前よりも自律的に見えるようになります。
明確化、失敗したテスト、およびリカバリ
最も明らかな瞬間は、編集後の最初のテストが失敗したときかもしれません。私は診断、証拠、回復、そして人間が新たな事実を提供したかどうかを保存します。コーディング エージェントの障害回復は、仮説を絞り込み、障害を検査し、パッチを修正し、チェックを再実行する場合に強力です。コードを繰り返し変更したり、差分を拡大したりすると弱いです。
セッションをドラマチックにするためだけに失敗をするつもりはありません。ただし、実際の依存関係、テスト、環境の問題によってタスクがブロックされる場合、それは結果に含まれます。コーディング エージェントにとって、リカバリ品質は配信品質の一部です。人間が作業をレビューしているのか、それとも黙ってエージェントのデバッガーになっているのかがわかります。
公開されたベンチマークでは証明できないこと
公開されたベンチマークは、モデルが指定されたハーネスの下で定義されたタスクを完了したことを示すことができます。これらは、それがあなたのアーキテクチャを理解していること、あなたの権限を持っていること、あなたのツールチェーンを起動していること、あなたのリリースプロセスを尊重していること、またはあなたのチケットの特定のあいまいさを回復することを確立するものではありません。また、SWE-2 と SWE-bench を互換性のあるものにするわけでもありません。SWE-2 は Cognition のモデル名であり、SWE-bench はベンチマーク ファミリです。
ベンダーの数値は正確であるため、特に読みすぎやすいです。常にソース、ベンチマークのバージョン、日付を含める必要があります。単一のスコアだけでは、実際のリポジトリの成功を予測することはできません。また、タスクにどの程度の介入が必要になるかをエンジニアリング リーダーに伝えることもできません。私なら、テストを放棄するのではなく、何をテストするかを選択するために数値を使用します。
この SWE-2 レビューの限界
これは文書化された評価計画であり、完了した独立した実行ではありません。特定のリポジトリの解決速度、コスト、実時間、または SWE-2 障害パターンをレポートすることはできません。結果は、選択した Devin 製品サーフェス、作業レベル、ワークスペースのスナップショット、リポジトリの指示、依存関係の可用性、ネットワーク アクセス、権限、タスク概要の品質によって異なります。
また、法律、セキュリティ、コンプライアンス、または購入についての主張も行いません。プライベート リポジトリに接続する前に、アカウント所有者に現在の製品ドキュメントと契約を確認してもらいます。特に、チームは、付与されている実際の権限、現在のデータ管理、保持言語、プランの資格、および目的の SWE-2 オプションが Devin 環境で表示されるかどうかを確認する必要があります。このレビューのいかなる部分も、EvoX または Evomap が SWE-2 を使用または統合していることを示唆しています。
よくある質問
SWE-2 は現在、Devin 製品のどこで入手できますか?
2026 年 9 月 10 日の発表で、Cognition は、SWE-2 が Devin Desktop および CLI で利用可能であり、Devin Web および Fusion に展開されると述べました。これはリリース時の声明であり、永続的な権利を約束するものではないため、特定のサーフェスに依存する前に、現在のモデル ピッカー、リリース ノート、および計画を確認します。
Devin チームは、SWE-2 がアクセスできるリポジトリを制限できますか?
GitHub 統合に関して、Cognition の現在のガイダンスでは、管理者は Devin にすべてのリポジトリまたは選択したリポジトリへのアクセスを許可でき、後でその範囲を変更できると記載されています。エンタープライズ展開では、リポジトリのアクセス許可も文書化されます。 Devin GitHub 統合ガイド には、関連する広範な読み取りおよび書き込み権限がリストされているため、「選択されたリポジトリ」は無害な切り替えとして扱うのではなく、意味のあるアクセス許可として引き続き検討する必要があります。
Cognition は SWE-2 に送信されたリポジトリ データをどのように処理しますか?
Cognition の公安文書は、顧客の同意とともに、この質問の現在の情報源として扱われる必要があります。現在の公開文言では、承認されたユーザーが積極的に提供するデータを Cognition が処理し、データ コントロールを通じて有効にしない限り、顧客データのモデル トレーニングはデフォルトでオフになっていると述べられています。エンタープライズ顧客データはモデルのトレーニングには使用されないと別途記載されています。また、保持データとフィードバック データ、またはユーザー インタラクション データについても異なる方法で説明します。これらはデータ処理条件であるため、この回答を法的またはコンプライアンスの結論に変えるのではなく、実際の文書と契約を確認します。
ユーザーはタスクごとに SWE-2 推論の取り組みを選択できますか?
Cognition の発表では、SWE-2 の中、高、最大を行動的に異なる努力レベルとして説明していますが、この発表だけでは、すべての Devin サーフェスですべてのユーザーがすべてのタスクに対してそれぞれの努力を選択できることを約束するものではありません。実際に選択可能な設定をテストで記録し、インターフェイスまたはプランで公開されていない場合は、その設定を使用不可としてマークします。複数の努力レベルをトレーニングすること自体は、タスクごとの普遍的な制御の証拠ではありません。
Cognition は SWE-2 重み付けまたはスタンドアロン API を提供しますか?
リリースの発表では、ダウンロード可能な重みやスタンドアロンの SWE-2 推論 API ではなく、Devin 製品を通じて SWE-2 について説明されています。 Devin にはプラットフォームとワークフロー インターフェイスがありますが、それは発表されたモデル重みリリースや一般的なモデル API とは異なります。この記事のために検討した公開資料に基づくと、どちらも想定されるべきではありません。どちらかを必要とするチームは、Cognition に直接問い合わせる必要があります。
以前の投稿:
- モデルの機能と実際のタスクの完了に関する別の固定リポジトリの比較として、Muse Spark 1.3 エージェント推論 では、長期的なコーディング作業における完了品質、人間の介入、回復、レイテンシー、および推論の労力を調べます。
- 1 つの制限されたリポジトリ タスクを通じてコーディング エージェントがどのように評価されるべきかを確認したい場合、T3 コード レビュー は、基になるエージェントとのインターフェイスを混同することなく、セットアップ、セッション制御、差分検査、およびハンドオフに従います。
- より広範な実際のソフトウェア開発の観点から、GPT-5.6 Sol ソフトウェア開発ケース スタディ では、コード生成を超えて、テスト、実装の証拠、展開の境界、人間によるレビューにまで目を向けています。
- SWE-2 ベンチマークの結果が依然として周囲の実行レイヤーに依存する理由を理解するために、DeepSeek ハーネス プラグイン アーキテクチャ は、モデルの機能をツール、セッション、権限、プラグイン、ランタイム制御から分離しています。
- 失敗したテスト、再試行、修正、および最終的なリポジトリ状態の背後にある証拠を保存するために、LLM エージェントの決定論的再生 では、タスク終了後にエージェントの実行を再現可能および監査可能に保つ方法について説明しています。
