EN
Связаться
Глава 29

Измеряйте принятые изменения, а не количество ответов

Метрика агента должна отражать пользу разработчику и риск репозитория: принят ли patch, сколько потребовалось переделок, сохранился ли scope, прошли ли проверки и сколько человеческого времени ушло на приёмку.

Семь метрик и то, что каждая показывает, стоит держать вместе.

Метрика · Как считать · Что показывает

  • Acceptance rate - Tasks с принятым patch / завершенные tasks того же типа; Практическая пригодность результата
  • Rework turns - Число циклов исправления после первого review; Качество plan и контекста
  • Scope precision - Ожидаемые changed files против фактических; Дисциплина изменений
  • Verification completeness - Acceptance checks с artifact или exit code; Доказуемость результата
  • Engineer review time - Активное время до accept или reject; Реальная экономия внимания
  • Escalation quality - Остановки по корректной причине / все необходимые остановки; Насколько workflow управляет неопределенностью
  • Post-merge defects - Регрессии, связанные с accepted agent patch; Качество после локальных checks

Чтобы метрики опирались на факты, а не на память, каждый запуск сохраняет минимальный audit record.

JSON
{
  "taskId": "discount-142",
  "contractHash": "sha256:...",
  "product": "codex|claude-code|cursor",
  "surface": "cli|ide|app|cloud",
  "startRevision": "git-sha",
  "allowedWritePaths": [
    "src/discount.js"
  ],
  "commands": [
    {
      "argv": [
        "node",
        "--test",
        "tests/discount.test.js"
      ],
      "exitCode": 0,
      "timedOut": false
    }
  ],
  "changedFiles": [
    "src/discount.js"
  ],
  "independentReview": "pass",
  "accepted": true,
  "residualRisks": []
}

Провести сравнение честно помогает дисциплина: сгруппировать tasks по классу (bug fix, test writing, refactor, review), зафиксировать один environment и одинаковые acceptance checks, не смешивать evaluation с production secrets, сравнивать accepted outcomes, а не красоту final message, и разбирать failures по причине - context, plan, tool, environment, permission, model или oracle.

Productivity нельзя вывести из tokens. Token count и wall time полезны для cost и capacity, но не говорят, сэкономил ли агент время инженера и не создал ли риск. Связывайте usage с принятым, проверенным результатом, иначе метрика измеряет активность, а не пользу.

Метрики есть. Осталось собрать всё в порядок внедрения - автономность добавляют ступенями, а не одной настройкой.

Ссылки