dev-ai-coding-metrics（开发 AI 编码指标）

AI Coding Agent Metrics for Engineering Teams

Measure what matters when adopting AI coding tools. This skill provides metrics frameworks, measurement methodology, ROI models, and reporting templates for engineering managers, VPs of Engineering, and CTOs evaluating or scaling AI coding agents.

When to Use This Skill

• Evaluating AI coding tool ROI before or after purchase
• Building a metrics program for AI-assisted development
• Reporting AI tool impact to leadership or board
• Designing controlled experiments to measure AI effectiveness
• Comparing productivity across AI-equipped and traditional teams
• Tracking adoption health and identifying stall patterns
• Assessing quality impact of AI-generated code
• Running developer experience surveys for AI tools

Quick Reference

Core Metrics Taxonomy

Five measurement categories. Start with Adoption (you can't optimize what people aren't using), then layer in the others.

1. Adoption Metrics

Track whether and how developers use AI tools.

Deep dive: references/adoption-metrics.md — 8 additional metrics, adoption curve phases, tool-specific tracking, stall patterns.

2. Velocity Metrics

Measure speed and throughput changes.

Deep dive: references/productivity-metrics.md — DORA adaptations, SPACE framework, cycle time decomposition, confounding variables.

3. Quality Metrics

Track whether AI helps or hurts code quality.

Critical warning: Early studies show mixed quality results. AI can increase velocity while *also* increasing bug density if guardrails are missing. Monitor both.

Deep dive: references/quality-metrics.md — complexity tracking, security metrics, technical debt, quality guardrails.

4. Economic Metrics

Calculate costs, benefits, and ROI.

Caveat: Most published ROI figures come from tool vendors. Independent studies show lower but still positive returns. Always triangulate.

Deep dive: references/roi-framework.md — cost model, value model, formulas, executive reporting, benchmarks with caveats.

5. Experience Metrics

Measure developer satisfaction and cognitive impact.

Deep dive: references/developer-experience-metrics.md — survey design, cognitive load measurement, friction indicators, trust metrics.

Measurement Maturity Model

Where is your organization in measuring AI coding impact?

L0 → L1 Quick Start (2 hours)

1. Pull license utilization from admin console
2. Run the adoption survey (assets/adoption-survey-template.md)
3. Calculate basic ROI estimate (assets/roi-calculator-template.md)
4. Present 1-page summary to leadership (assets/executive-report-template.md)

L1 → L2 (2-4 weeks)

1. Establish DORA metric baselines (references/productivity-metrics.md)
2. Set up quality tracking (references/quality-metrics.md)
3. Build three-tier dashboard (assets/metric-dashboard-template.md)
4. Schedule quarterly developer experience surveys

L2 → L3 (1-3 months)

1. Design first controlled experiment (assets/experiment-design-template.md)
2. Apply statistical rigor (references/benchmarking-methodology.md)
3. Create executive reporting cadence (assets/executive-report-template.md)
4. Cross-reference with dev-context-engineering maturity model for context quality impact

L3 → L4 (ongoing)

1. Automate data collection and dashboards
2. Build predictive models (adoption → productivity correlation)
3. Benchmark against industry data
4. Contribute findings to community (conference talks, blog posts)

Metric Selection Decision Tree

Not every org needs every metric. Start from what you're trying to prove.

WHAT ARE YOU TRYING TO PROVE?
  │
  ├─ "Should we buy AI coding tools?"
  │   └─ START: roi-framework.md → roi-calculator-template.md
  │       Metrics: cost per seat, estimated hours saved, break-even adoption rate
  │
  ├─ "Are developers actually using the tools?"
  │   └─ START: adoption-metrics.md → adoption-survey-template.md
  │       Metrics: DAU/WAU, acceptance rate, feature breadth, organic usage
  │
  ├─ "Are we shipping faster?"
  │   └─ START: productivity-metrics.md → metric-dashboard-template.md
  │       Metrics: DORA metrics, cycle time, PR throughput
  │
  ├─ "Is code quality suffering?"
  │   └─ START: quality-metrics.md → metric-dashboard-template.md
  │       Metrics: bug density, defect escape rate, rework rate, vulnerability rate
  │
  ├─ "Are developers happy with AI tools?"
  │   └─ START: developer-experience-metrics.md → adoption-survey-template.md
  │       Metrics: satisfaction, NPS, cognitive load, give-up rate
  │
  ├─ "How do we compare to industry?"
  │   └─ START: benchmarking-methodology.md → experiment-design-template.md
  │       Metrics: DORA benchmarks, adoption curves, ROI ranges
  │
  └─ "Should we expand or cut the program?"
      └─ COMBINE: roi-framework.md + adoption-metrics.md + executive-report-template.md
          Metrics: ROI trend, adoption trajectory, satisfaction trend, quality delta

Dashboard Design Principles

Three-Tier Hierarchy

Design Rules

1. Lead with outcomes, not activity — show deploy frequency, not lines of code
2. Always show trend lines — a single number is meaningless without direction
3. Include confidence indicators — mark metrics with low sample sizes or high variance
4. Never rank individuals — aggregate to team level minimum (team size ≥5)
5. Pair speed with quality — never show velocity without adjacent quality metrics
6. Show cost alongside benefit — ROI is a ratio, not a cherry-picked benefit number

See: assets/metric-dashboard-template.md for full layout.

Anti-Patterns

Cross-References

Do / Avoid

Do:

• Start with adoption metrics — you can't optimize what people aren't using
• Establish baselines *before* rolling out AI tools (8-week minimum)
• Use the balanced scorecard approach (adoption + velocity + quality + experience)
• Run quarterly developer experience surveys
• Report with confidence intervals, not point estimates
• Cross-reference with context maturity (dev-context-engineering) — structured repos get more AI benefit

Avoid:

• Don't track individual developer productivity with AI tools
• Don't use lines of code as a metric for anything
• Don't measure impact in the first 4 weeks (adoption curve)
• Don't rely on vendor-published benchmarks without independent validation
• Don't survey developers without acting on the results
• Don't compare teams without controlling for confounding variables
• Don't present ROI without showing the cost model assumptions

Web Verification

55 curated sources in data/sources.json across 7 categories:

Verify current data before final answers. Priority areas:

• DORA State of DevOps report updates (annual)
• GitHub Copilot Metrics API changes
• New independent productivity studies (academic, not vendor)
• ETH Zurich context effectiveness research updates
• METR evaluation methodology updates

Fact-Checking

• Use web search/web fetch to verify current external facts, versions, pricing, tool features, or published benchmarks before final answers.
• Prefer independent/academic sources over vendor marketing; report source links and dates.
• If web access is unavailable, state the limitation and mark guidance as unverified.

Navigation

References

Assets (Copy-Ready Templates)