Як оцінювати coding agents: власний benchmark для репозиторію

Щоб оцінити coding agent, зберіть версійований набір закритих задач із відомим стартовим commit, відновіть кожну в ізольованому середовищі й дайте агенту лише issue contract, repository instructions та дозволені tools. Після run незалежно повторіть checks, проведіть blind review diff і рахуйте не написані рядки, а частку прийнятих змін, reviewer time, regressions, policy violations і повну вартість прийнятого патча.

Публічний benchmark корисний як зовнішній сигнал, але не відповідає на локальні питання: чи агент розуміє ваш monorepo, приватні APIs, migration policy, нестабільні tests і definition of done. Тому вибір інструмента починається з replay власних задач. Leaderboard не є дозволом на production access, а красивий self-report агента не замінює clean-room verification.

Зафіксуйте рішення, яке підтримує eval: вибір coding agent, дозвіл нового task class або promotion з suggestion-only до PR-only. Для кожного slice визначте owner, risk, max runtime, model/tool versions, дозволені files і network, acceptance commands та hard failures. Critical secret exposure або спроба вимкнути required check має блокувати promotion незалежно від середнього task-success score.

Розділіть три об'єкти оцінювання. Outcome показує, чи правильний final repository state. Process фіксує scope discipline, tool errors, retries та спроби обійти controls. Operations вимірює latency, compute, tokens, reviewer minutes і reruns. Один aggregate score змішує ці причини й приховує ситуацію, коли агент проходить tests, але створює неприйнятний maintenance або security risk.

• Decision → який вибір або promotion дозволить результат.
• Fixture → pinned commit, issue, setup і hidden acceptance evidence.
• Authority → filesystem, commands, network, secrets і write scope.
• Graders → deterministic checks, security policy та blind human review.
• Gate → thresholds за task/risk slices і безумовні critical failures.

Почніть із 20–40 закритих задач, достатньо малих для незалежної перевірки, але різних за формою: локальний bug, cross-file change, regression test, refactor без зміни поведінки, dependency update, документація та no-change-needed issue. Відновіть стан до людського fix і приберіть merge commit, готовий patch та discussion, які розкривають відповідь. Не використовуйте production secrets або персональні дані у fixture.

Додайте negative controls: суперечливий issue, відсутня dependency, flaky test, stale base, malicious instruction у repository, canary secret, заборонений каталог і задача, що потребує зовнішнього write. Очікуваним результатом іноді є abstain або evidence gap, а не patch. Розділіть development і holdout набори; якщо prompt, instructions або agent tuning бачили holdout answers, результат уже не є чесною оцінкою узагальнення.

Кожний run стартує з того самого base SHA у disposable container, VM або worktree з pinned toolchain. Версіонуйте setup script, dependency cache policy, environment variables і repository instructions. Видавайте лише synthetic або task-scoped credentials, вимикайте непотрібний network і записуйте model, client, policy, commands, exit codes та artifacts без секретів.

Кандидати повинні мати порівнюваний time, token/compute і tool budget. Якщо один агент отримав web, інший — ні, ви порівнюєте системи з різним контекстом, а не моделі. Повторіть stochastic runs для вибраної підмножини й окремо рахуйте variance: один вдалий run не доводить надійності, а безкінечні retries штучно покращують pass rate коштом latency та вартості.

Спочатку clean-room runner застосовує patch до pinned state й виконує formatter, typecheck, unit/integration tests, security scans та hidden tests. Перевіряйте не лише нові tests агента: він може послабити assertion або змінити fixture, щоб зробити власний diff зеленим. Policy grader блокує зміни required workflows, protected configuration, generated snapshots і dependency sources поза contract.

Потім blind reviewer без назви продукту оцінює root-cause fidelity, мінімальність scope, readability, backward compatibility, test quality та невирішені ризики. Для неоднозначної задачі кілька patches можуть бути коректними, тому людський gold diff не повинен бути exact-match еталоном. Model grader можна використовувати для triage, але лише після calibration проти людської розмітки й не як єдиний суддя consequential change.

Основні показники — accepted-task rate, first-run acceptance, regression і critical-policy violation rate, median time to reviewable patch, reviewer minutes, human edit distance, rerun rate та cost per accepted task. Сегментуйте їх за мовою, repository, task type і risk. Pass@k відповідає на питання, чи хоча б один із кількох запусків успішний, але для щоденного workflow важливі також first-run reliability і ціна всіх невдалих спроб.

Не прирівнюйте public SWE-bench score до внутрішнього acceptance rate: dataset, harness, agent scaffold, budget і contamination controls можуть відрізнятися. Не вигадуйте ROI з кількості generated lines або elapsed agent time. Business case потребує baseline людського процесу та повної вартості: setup, inference, sandbox/CI, review, rework, incidents і підтримка eval harness.

Після offline replay проведіть shadow evaluation на нових, уже вирішених задачах, далі suggestion-only pilot і PR-only роботу на low-risk slice. До кожного promotion зафіксуйте thresholds, repository owners і заборонені task classes. Merge, deploy, production incident action, secret rotation та irreversible migration лишаються за людиною або незалежним policy gate.

Після model, client, sandbox, permission або repository-stack change запускайте regression suite знову. Rollback означає pin попереднього перевіреного system bundle або вимкнення agent path для affected slice; незлиті branches закриваються, credentials відкликаються. Production escape очищується від sensitive data й стає новим permanent regression case, щоб наступна версія довела виправлення на тому самому failure mode.