Built on data, not opinions

Then: count the output. Now: measure the steering.

Legacy metrics count what the machine produced - lines, coverage, rule hits. AgenticReview complements these historic measures with what the humans did with it: guardrails set before the agent starts, plans written before it builds, review and correction after it delivers.

How the model works

34 signals from git history become eight meters, scored on levels 1-5. The meters combine into four composite indices - Capacity, Composable, Craftsmanship and Cooperation - and the indices into one total from 0 to 10. Each pillar is shown on the same 0-10 scale, and the total is their average, weighted by how many of each pillar's meters could be measured - so a pillar with missing data counts for less.

Levels are set against the reference cohort, not against a fixed rulebook: a level says where a team stands relative to organisations building software today. Volume is measured per active contributor, so a small team is not marked down for being small, and teams are compared with organisations of their own size wherever size is part of what is measured.

From 34 signals to one scoreA funnel that narrows from left to right: Reference cohort in 7 regions, 34 signals from git history, 8 meters on levels 1 to 5, 4 composite indices and 1 total score from 0 to 10. A dashed side branch from the signals shows Stance, which is mapped but never scored. Calibration anchors are versioned and recalibrated as the benchmark grows.Cohortreference · 7regions34signals · git history8meters · levels 1-54composite indices1total · 0 to 10Stancemapped, never scoredCALIBRATIONCalibration anchors, versioned - recalibrated as the benchmark grows.
From 34 signals to one scoreA funnel that narrows from left to right: Reference cohort in 7 regions, 34 signals from git history, 8 meters on levels 1 to 5, 4 composite indices and 1 total score from 0 to 10. A dashed side branch from the signals shows Stance, which is mapped but never scored. Calibration anchors are versioned and recalibrated as the benchmark grows.Cohortreference · 7 regions34signals · git history8meters · levels 1-54composite indices1total · 0 to 10Stancemapped,neverscoredCALIBRATIONCalibration anchors, versioned - recalibrated asthe benchmark grows.

How to measure technical debt in AI-written code

Technical debt rarely shows in today's code - it shows when a change suddenly costs more than it should. AgenticReview reads it from the history: rules and components copied instead of shared (Composable), dependencies left to age and missing tests (Craftsmanship), and work that only one person can carry (Cooperation). Each is compared with the reference cohort, so you see whether your debt grows faster than in comparable organisations.

What is technical debt - and why AI makes it grow faster

Technical debt is the extra cost every future change carries because of shortcuts taken today - tech debt, code debt, the same idea. AI makes it grow faster: agents produce working code quickly, and the same rule copied into five places looks fine until it has to change. The earlier it is measured, the cheaper it is.

Maintainability and code quality: what we score

Maintainability is how easily someone - person or agent - can change the code tomorrow. AgenticReview scores it from the history: one definition per business rule, components shared rather than copied, dependencies kept current and tests that guard the work. Code quality in the classic sense is part of it; the structure behind it is the rest.

DORA metrics and AI: delivery speed is not steering

DORA metrics show how fast and safely a team delivers - deployment frequency, lead time, failure rate and recovery. With agents, delivery speed is cheap; what decides is whether the work is steered. AgenticReview complements DORA: it measures the steering and the structure that keep the delivery numbers good once AI writes most of the code.

Quality scored, stance mapped

Only what no competent architect would argue against is scored - dead code, duplicated rules, missing tests. Strategic choices where both sides have defenders, such as strict vs flexible schema, are mapped, never scored.

The reference cohort

The benchmark is built on public GitHub data from thousands of organisations whose repositories are open, analysed with the same method as every customer review, balanced across seven regions and compared within size bands. Public organisations work somewhat differently from teams that build in private repositories - review and handover habits in open source follow their own patterns - so any difference shows mainly in Cooperation and much less in the other dimensions. Most comparable benchmarks rely on repository metadata or self-reported surveys; this one is measured in the code and its history.

Teams, never individuals

Results are reported for each product and for the company as a whole. Contributors are counted to normalise volume, but no per-person score is calculated, stored or shown.

Analysis written from the numbers

Every report includes a written analysis: where the product stands, what drives the score, how it has developed and which changes would move it most. The text is generated from the measured values alone, and every figure in it is checked against the measurement before it is shown. No source code is used to write it.

Versioned and recalibrated

Anchors are recalibrated as the benchmark grows. Every report states its model and threshold version, so results stay comparable over time, and a change of version is never mixed into the same trend line.

Your code never leaves GitHub

Reviews run on GitHub's own runners with read-only access. Code is analysed in memory and discarded; only derived metrics leave GitHub, stored in the EU.

Not a compliance certification - an evidence base for one

AgenticReview shows how software development is steered and handed over, over time and against the market. It does not certify compliance with any regulation, but it gives boards, auditors and acquirers an independent record to build on.