AI コーディングエージェントが実際のリポジトリ評価を行う方法: タスクセット、合格率、コスト、回帰ベースライン

米国では過去 1 週間、「AI コーディング」が今回の 5 つの比較語の中で最も人気があり、27 語でした。

公開リストはモデルの機能を理解するのに適していますが、特定のエージェントがリポジトリに適しているかどうかには答えられません。

まず実際の購入の結果を定義します

誰かが小さなバグをすぐに修正する必要があります。

誰かがサービス全体をリファクタリングする必要があります。

プライバシー、コスト、監査可能性を重視する人もいます。

最終的に単に「賢く見える」ことを避けるために、これらの目標を重みとして書きます。

履歴の作業指示書からタスクを抽出する

解決済みで検証可能な回答があるチケットを選択します。

4 種類の難易度をカバーします。

単一ファイルの明示的な修正。
ファイル間の動作の変更。
プロジェクトを実行して場所を特定する必要がある問題。
要件があいまいなタスクであり、最初に質問する必要があります。

モデルのトレーニング資料に含まれる可能性のある、公開されている注目の問題だけを選択しないでください。

各タスクの固定開始点を作成する

リポジトリのコミット、依存関係ロックファイル、およびテストデータのバージョンを保存します。

スタンドアロンの Git ワークツリーを使用します。

1

git worktree add ../eval-task-01 <base-commit>

コンテナイメージはフローティング latest の代わりにダイジェストを使用します。

外部 API を使用して、応答やテスト環境を記録します。

機械が決定可能な合格条件を書き込む

単体テストに合格することは、最初の層にすぎません。

また、レガシーテスト、型チェック、lint、ビルドもチェックしてください。

データベースタスクは、スキーマがデータと互換性があることを確認します。

スクリーンショットまたはアクセシビリティアサーションをフロントエンドタスクに追加します。

セキュリティタスクにネガティブテストを追加します。

エージェントが審判を変更できないようにする

非表示のテストは、書き込み可能な作業ツリーには配置されません。

テストランナーは読み取り専用でマウントされます。

エージェントが既存のテストを削除、スキップ、または弱体化したかどうかを確認します。

テスト数とカバレッジの変化を比較します。

ハードコードされたテスト入力による問題の「修正」を無効にします。

完全なランニング軌跡を記録します

少なくとも以下を保存してください:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


agent_version
model
task_id
base_commit
prompt_version
wall_time
input_tokens
output_tokens
tool_calls
human_interventions
final_cost

バージョンフィールドのない結果は、今後の回帰では使用できません。

機密性の高いログは、まず機密性が解除されてからアーカイブされます。

成功率は3段階に分かれています

一度合格: 手動による変更は必要なく、すべての承認に合格します。

合格の支援: 誰かが説明や小さな修正を行って合格します。

失敗: 未完了、他のアクションを破壊する、または結論が信じられない。

「大量のコードを生成する」ことを成功としてカウントしないでください。

エージェントによって報告された「修正済み」をテスト結果として受け取らないでください。

コストは成功したタスクに基づいて計算されます

リクエストあたりの平均コストは、失敗した再試行をマスクします。

さらに便利なのは次のとおりです。

1

每个一次通过任务成本 = 总成本 / 一次通过任务数

エンジニアのレビュー時間も記録します。

より安価なモデルの場合、手作業によるレビューに時間がかかる場合、総コストは低くならない可能性があります。

時間インジケーターは 3 つのセグメントに分割されています

最初の有効アクション時間。

エージェントの完了時間。

マージ時間までの手動レビュー。

並列エージェントは第 2 段階を短縮する可能性がありますが、第 3 段階の競合コストが増加します。

したがって、モデルの応答速度だけを見ることは意味がありません。

安定性を測定するための繰り返し実行

同じタスクを少なくとも 3 回実行します。

モデルのバージョン、温度、環境を修正しました。

3 回のうち 1 回のパスだけでは、信頼できる自動化とは見なされません。

障害の種類が一貫しているかどうかを確認してください。

適切な明確な質問を継続的に行うことも、利用可能なスキルです。

障害分類の作成

関連するファイルが見つかりません。
間違った要件を理解していました。
ツールまたは環境が失敗しました。
パッチは正しいですが、テストが不完全です。
変更は範囲外です。
偽の検証結果。
コストまたは時間が超過しました。

分類した後でのみ、モデル、プロンプト、ツール、または環境を変更するかどうかを決定できます。

アップグレード前に回帰を実行する

ベースラインとして 15 ～ 30 の代表的なタスクを保持します。

エージェント、モデル、ツールの権限、またはシステムプロンプトを変更すると、回帰が引き起こされます。

新しいバージョンは、少なくとも一か八かのミッションを後退させるべきではありません。

結果は、同じスコアリングスクリプトを使用して生成されました。

結果を確認した後、その場でウェイトを変更しないでください。

実際の結果表

エージェント	初回合格率	マン分/タスク	コスト/成功したタスク	境界越えの数
あ	テストで記入	記録でいっぱい	請求で満たされる	監査によって満たされる
B	テストで記入	記録でいっぱい	請求書で満たされています	監査によって満たされる

平均の概要だけを公開するのではなく、元のタスクレベルのデータを保持してください。

信頼できる結論を書く方法

リポジトリの言語、タスクの種類、モデルの日付、および権限の構成について説明します。

サンプルサイズと信頼限界について説明します。

事実のデータと主観的な経験を区別してください。

1 つのリポジトリ勝者をすべてのシナリオの勝者として宣伝しないでください。

本当に価値のあるレビューは、次のアップグレード時にそのまま再実行できるエンジニアリング資産です。

評価データソース

タスクリストはバージョン管理された YAML を使用します

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


id: api-017
base_commit: 8c18d4a
category: cross-file-bug
time_limit_minutes: 30
allowed_paths:
  - src/api/
  - tests/api/
required_checks:
  - python -m pytest tests/api
  - ruff check src/api tests/api
forbidden_changes:
  - tests/fixtures/golden.json

タスクの説明は、非表示のテストとは別に保存されます。 YAML は評価リポジトリに入り、非表示のテストはエージェントが読み取り権限を持たない実行環境に配置されます。

環境障害と機能障害を区別する

依存関係ソースの利用不能、コンテナーのプルの失敗、またはテストインフラストラクチャの障害は、モデルの障害として直接カウントされるべきではありません。まず、修正された事前チェックスクリプトによって環境の健全性が確認されます。

環境が正常になってからのみ計時を開始してください。エージェント自身による依存関係または構成の破壊によって引き起こされる障害はタスクの結果であり、インフラストラクチャの問題としてマークすることはできません。

手動介入をスコアリングする方法

介入をニーズの明確化、環境支援、技術的なヒント、直接的な回答に分割します。各カテゴリは個別にカウントされ、時間が計測されます。

エージェントは率先して必要な説明を行いますが、これは、個人が率先して鍵ファイルの場所を明らかにするのとは異なります。前者は良い行動である可能性がありますが、後者は単独で完了するには能力が不十分であることを示しています。

パッチの範囲を確認してください

1
2
3


git diff --name-only <base-commit>...HEAD
git diff --numstat <base-commit>...HEAD
git diff --check <base-commit>...HEAD

統計には、変更されたファイルの数、純追加と削除の数、タスクの許可範囲外のファイルの数が含まれます。大きなパッチについては自動的に減点されることはありませんが、無関係な変更は個別にマークする必要があります。

戦闘「テストは合格したが、動作が間違っている」

非表示のテストは、制限付き入力、エラー処理、従来の動作の互換性をカバーします。テストがスキップされていないか、過剰なモックがないか、実装がハードコードされた例かどうかを人間がレビューします。

フロントエンドタスクは主要なインタラクションを記録し、API タスクはステータスコードとエラー構造を比較し、パフォーマンスタスクは固定データセットとウォームアップルールを使用します。

評価コストにはインフラストラクチャが含まれます

モデルトークンの料金に加えて、コンテナー時間、ブラウザーの実行、データベースインスタンス、ログストレージも記録されます。エンタープライズ環境では、手動レビューのコストが追加されます。

同じエージェントが同時に実行される場合、共有サービスのコストはタスクごとに共有されます。無料トライアルクレジットを長期的な単位費用として考えないでください。

結果の変化の重要性

20 のタスクのうちあと 1 つを通過するのは、単なるランダムな変動かもしれません。タスクレベルのペアリングの結果、どの古いタスクが低下し、どの新しいタスクが改善されたかを確認します。

全体の平均だけを見るのではなく、主要なカテゴリの最低合格率を設定します。セキュリティ修正の後退は、ドキュメントタスクの改善によって相殺することはできません。

失敗した製品を保存する

失敗した実行には、最終的な差分、最後のテスト出力、ツールエラー、および停止理由が保持されます。資格情報を削除し、タスクと実行 ID で指定されたディレクトリに保存します。

レビューするときは、まず失敗のタイプを比較してから、長いダイアログを読みます。多くの問題は、繰り返しのツール呼び出し、不適切な作業ディレクトリ、または実行されていないテストから直接確認できます。

ベンチマークがトレーニングメモリによって汚染されるのを防ぐ

内部タスクの完全な説明と回答を公開しないでください。最近解決された作業指示書を定期的に補充し、漏れたタスクを排除します。

ローリングタスクで現在の実際の作業を測定しながら、傾向を比較するために一連の長期的なアンカーを保持します。 2 つのグループの結果は別々に報告されます。

主要なシナリオにおけるモデルの安定した失敗が要約スコアによって隠蔽されるのを避けるために、失敗したタスクのリストと停止理由を含む結果を公開します。

元のデータは十分な精度を保持しており、表示時に均一に丸められます。