Evidence and validation
ABSORB is a proposed framework. This page shows what it rests on, how each figure was checked, and what would count against it.
Figures used in the framework
Each figure was traced to its source and checked against the page itself where it could be opened (2 November 2026). Most come from vendors or company self-reports; only the METR trial is a controlled study.
| Claim | Source | Type | How checked |
|---|---|---|---|
| Merges rose from about 2,500 a day (May 2026) to over 30,000 (September); the bottleneck became infrastructure built for human scale | Anthropic, Redesigning source control | Company self-report | Opened; quoted |
| Claude Code repositories merge with at most one human in the loop, with no increase in reverts or incidents | How the Claude Code team does code review | Company self-report | Opened |
| Agentic PRs wait 5.3× longer for pickup; AI-generated PR acceptance 32.7% vs 84.4% | LinearB, 2026 Benchmarks Report | Vendor report | Opened the report page |
| PRs merged without any review up 31.3%; incidents-to-PR ratio up 242.7% | Faros AI, The Acceleration Whiplash | Vendor report | Opened the vendor's summary |
| Weekly PRs per developer up 75.5%; 105% longer first-review wait at the highest-AI organizations | DX, State of AI Impact in Engineering: Q3 | Vendor report | Opened; quoted |
| Coding is roughly 20 to 30% of lead time | Unblocked, Why the gains disappear | Vendor blog, an estimate | Opened; the estimate is the author's |
| Experienced developers 19% slower with early-2025 AI tools, while believing they were faster | Becker et al. (METR), arXiv 2507.09089 | Randomized controlled trial | Abstract read |
The full table, including the sources for the laws on the concept page, is in SPEC.md.
How ABSORB could be wrong
The validation plan states each claim as a hypothesis with a threshold, written before any data is collected. Failures are published, and threshold changes go through a dated calibration log.
| # | Claim | It fails if |
|---|---|---|
| H1 | The stage the assessment names as the constraint is the stage with the longest measured wait | They agree in fewer than 60% of teams |
| H2 | The whole-path speedup estimate lands near the measured change in lead time | Median absolute error exceeds 50% of the measured change |
| H3 | A lower autonomy floor goes with more reverts and incidents | No negative relationship, or a positive one |
| H4 | After the constraint is fixed, a different stage becomes the longest within 90 days | The same stage stays longest in most cases |
| H5 | Two people scoring the same team land within 0.5 points per dimension | Mean difference above 0.5, or weighted kappa below 0.4 |
| H6 | A dimension's three statements move together more than with other dimensions | Statements do not cluster by dimension |
| H7 | At similar AI usage, higher levels go with shorter lead time | No ordering, or the reverse |
| H8 | Waits rise steeply when arrivals approach a gate's clearing capacity | Candidate only, not yet in the spec |
Status: all untested. No field results exist yet.
The assessment page collects data for two of these directly: the comparison reports the H5 statistics, and the decision record shows whether the constraint moved (H4).
How to help
The most useful contribution is a case study, including one where ABSORB got it wrong. Use the case study template or open an issue on GitHub with what you applied it to, what scored wrongly, and what would change your mind.