Skip to main content

Leaderboard

Concepts

The Leaderboard combines an immediate adoption signal — the share of merged PRs with recorded AI assistance — with composite scores that help people improve how they use AI. Explore the same work through People, Teams, configured Projects, and Repositories.

Open Productivity → AI Effectiveness. Reports combine complexity-adjusted scores with fixed, configurable score bands. Old leaderboard bookmarks retain their People default and filters. Published outcomes is a separate, default-off view with explicit local targets, immutable reports, eligible competition positions, configurable bands, and calendar-day output rates. See Published comparisons for those definitions; they do not replace or reinterpret the legacy scores below. Neither view assigns business-value or innovation-quota points.

AI adoption and effectiveness​

AI PRs is an uncapped, unweighted percentage: distinct merged PRs with recorded AI assistance divided by eligible merged PRs. Linked AI sessions, self-declared AI markers, and recorded Copilot reviews qualify. A PR with several kinds of evidence counts once. Routine automation without AI attribution is excluded; AI-attributed agent PRs remain eligible.

The overview shows Composite score before AI PRs, with each cell on one line. The percentage appears alongside its count, such as 60% · 12/20 PRs, and its change in percentage points from the previous week. Hover for sample and comparison details. Small samples retain their actual percentage and count. 0% means PRs exist but no assistance was recorded; — means no merged PRs were recorded. Failed data requests show an error, never a zero. Missing history remains a gap.

AI adoption is displayed as counts and percentages without performance bands, including the read-only AI attribution view.

The composite is a separate assessment. Its AI-assisted work dimension currently uses session-linked or declared PRs; the adoption percentage also counts review-only assistance. The composite applies complexity normalization, peer comparisons, and sample adjustment, so its number is not interchangeable with the adoption percentage.

Projects reuse repository groups configured under Settings ▸ Projects. Team and project adoption uses PR counts directly, never averages of individual percentages. Filters intersect: a team plus a project means that team's work in the project's repositories. Current team membership and repository group configuration also apply to historical dates. Overlapping projects can contain the same PR; group rows should not be added to obtain an organization total. Unmapped repositories remain in Unassigned project, and configured projects with no work remain visible.

Teams, projects, and repositories receive composites calculated from their pooled PR facts. Review rounds, time to merge, quality, AI-assisted share, model fit, and resource discipline use the existing complexity adjustments and configured weights. Each group is compared with others of the same type. Individual scores are never averaged to produce a group score.

Cross-group filters scope both metrics: a team filter in Projects compares project work by that team; a project filter in Teams compares teams' work in that project. Selecting a particular team in Teams or project in Projects keeps the full comparison cohort. Search and pagination never change scores or bands. A repository report can lead to a contributor's adoption within that repository. Individual composites continue to use their saved all-project organization or team assessment, explicitly labeled in the report.

Group scoring needs at least two complexity-weighted PRs and comparable measurements from at least two eligible groups within a complexity band. Missing dimensions are omitted and available weights normalize to 100%. A lone project or repository group, or missing weighted measurements, remains unscored; the leaderboard explains that more comparable group activity is needed. Groups with sufficient comparable activity receive a composite even when some contributors cannot be scored individually. Bands use the same fixed score thresholds for every group size. Small samples still require cautious interpretation.

Group reports show measurements, comparison medians, contributing PRs, guidance, and eight weeks of history. History is recalculated from PR facts using current settings and membership. AI Practices remains individual-only because its telemetry cannot be reliably attributed to repository groups; its weight is omitted from group composites. Overlapping projects may share PR evidence, counted once within each project.

Bands, never ranks​

Effectiveness bands describe fixed score ranges rather than a position among peers. Administrators configure the inclusive minimum for Medium, High, and Elite in Settings → Productivity → AI Effectiveness. Defaults are:

BandScore range
Elite90 through 100
High75 to below 90
Medium50 to below 75
LowBelow 50
Not scoredInsufficient evidence or unavailable scoring; adoption remains visible

A score of 57.5 receives Medium under these defaults even if it is the highest score in the group. The same score and configured thresholds always produce the same band, independently of group size, search, or pagination. Overall and dimension bands share these thresholds. Changing them relabels live reports and history without recalculating numeric scores. Published reports remain unchanged.

The tables support sorting by name, score, or adoption. Equal scores sort alphabetically and unscored rows appear last. Reports still show comparison-group size because the numeric scoring model uses peer comparisons.

Complexity is the normalizer​

Every metric is normalized by a deterministic PR Complexity Score (0–100, banded trivial / low / medium / high) computed from the PR's size (log-scaled lines added), file count, module spread, language count, test-file share, and risk-path flags (schema migrations, API surfaces, dependency manifests, infrastructure, security-sensitive paths — the patterns are org-configurable).

Complexity is what keeps the model honest: eighteen trivial PRs do not outweigh two architectural ones, because per-PR comparisons happen within the same complexity band, and a developer's effective sample size (n_eff) is complexity-weighted. Splitting one change into many small PRs earns nothing — each trivial PR contributes almost no weight.

Dimensions, cohorts, and shrinkage​

Each developer is scored on independent dimensions (AI leverage, review efficiency, model fit, cycle efficiency, quality, resource discipline — see the dimension reference for exact formulas). Every dimension score is:

  1. a percentile against the cohort (the whole org, or a team of 4+ developers — smaller teams reuse org-relative scores rather than ranking two people against each other),
  2. compared only within the same complexity band, then weighted across bands by each band's sample,
  3. shrunk toward 50 for small samples (an empirical-Bayes pull of n_eff / (n_eff + k)), reducing the effect of sparse evidence without making a relative band a guarantee of performance.

The PR evidence label in effectiveness details reflects the complexity-weighted sample: Strong (≥ 10), Moderate (≥ 5), Limited (≥ 2). Sample adjustment still applies at Strong evidence, according to the configured smoothing value. This is separate from AI attribution coverage: many PRs can be available even when few have linked AI sessions.

The composite is a weighted blend of the dimension scores (weights are org-configurable); dimensions with no data are dropped and the weights renormalized — never imputed.

Every number has an evidence chain​

Clicking a name or adoption percentage opens the adoption report; clicking a composite opens Effectiveness and improvement. Clicking the row opens a quick preview. Adoption details show source evidence, a PR list with evidence filters, and project/repository/contributor breakdowns. Generic sessions and declarations do not identify whether assistance involved coding, design, or testing. Those activity types remain Not measured separately; Copilot reviews are reported explicitly. Design or exploration without a linked PR remains outside this percentage. Expand a dimension for its evidence: each dimension shows its score, sample, per-band percentile, and the specific pull requests the score was computed from. The same explainability chain backs the weekly history, so a score can always be traced to the work behind it.

What feeds it​

The leaderboard is built on AI delivery attribution: merged PRs ingested from the GitHub integration, joined to proxy-witnessed AI sessions (cost, tokens, models) and self-declared AI markers. Data appears once repositories are connected and PRs merge; scores recompute automatically as attribution improves, and an admin can rebuild all history after a configuration change.

The leaderboard view is admin-only. Read-only viewer accounts see no per-developer effectiveness data.

An overall score of 55/100 is neither 55% effective nor the 55th percentile. It blends adjusted dimension scores, and its band describes the configured score range. Missing dimensions do not lower it. Saved weights explain each historical score; older weeks lacking those snapshots require recomputation for a verified contribution breakdown.

Current coaching advice is dated and kept distinct from historical scores. An AI explanation uses the selected week's structured scores and saved contributions, and is withheld when stale. Practices with zero weight are reported separately from overall-score drivers.