A metadata-only scan of cline/cline measuring how much of the code any currently-active human has genuinely written or engaged with, and where comprehension debt is concentrating.
50% of its changed lines belong to contributors quiet past the 90-day window; priced on the recency curve, 70% of it still counts as living knowledge, and just 2 of them hold a tenth or more each. It absorbed 1,252 commits in the last 180 days. The rawest risk numbers sit in proto/ at 91% inactive and hosts/ at 100% inactive, but those are translation catalogues and generated definitions, which this engine deliberately discounts and which no engineer is expected to carry in their head. The finding that should travel is the one in the living code. On this framework, sustained change without living commit-authorship is a leading risk indicator for incident cost and onboarding drag. It is an indicator, not a verdict on any contributor.
Modules ranked by comprehension risk: how much of the module lacks a living author, amplified when the code is still changing (heat) and thinly held (bus factor). The green meter is the share written by currently-active humans.
| Module | Risk | Living knowledge | AI-attr. | Inactive | Bus factor | Heat (commits/180d) |
|---|---|---|---|---|---|---|
| proto | WARN 49 | 49% |
2% | 91% | 0 | 42 |
| hosts | WARN 47 | 38% |
0% | 100% | 0 | 0 |
| locales | WARN 42 | 44% |
0% | 60% | 3 | 30 |
| .changeset | OK 38 | 62% |
1% | 57% | 1 | 94 |
| .github | OK 37 | 63% |
2% | 51% | 1 | 146 |
| evals | OK 36 | 64% |
3% | 54% | 1 | 129 |
| standalone | OK 35 | 53% |
0% | 78% | 1 | 2 |
| scripts | OK 35 | 64% |
4% | 62% | 1 | 43 |
| eslint-rules | OK 34 | 54% |
0% | 83% | 1 | 0 |
| docs | OK 31 | 69% |
11% | 56% | 1 | 500 |
| .clinerules | OK 30 | 64% |
8% | 74% | 2 | 29 |
| src | OK 28 | 70% |
1% | 50% | 2 | 1252 |
Modules under 200 changed lines in the window are omitted from this table; the score above them is computed over every line either way. Work is counted as lines changed, additions plus deletions. Living knowledge and the AI minimum overlap by design: an active human who ships attributed agent-assisted work counts in both.
API-sampled signals joining PR timing with diff sizes from git history: 439 merged PRs timed, with review detail on a size-stratified sample of 34 deliberately weighted toward the largest merges. These figures describe that sample rather than all PRs, and they describe process patterns, not the diligence of any individual contributor.
Largest fast merge in the sample: PR #11862, at 2,077 lines touching apps/ and sdk/, merged 24 minutes after opening. Baseline latencies scale sanely with size (median 34 min for ≤50-line PRs, 31 hours for 1,000+ lines), which makes the exceptions the signal, not the norm. Note that legitimate workflows produce these patterns too: pre-coordinated changes, pairing, generated files, release automation, and review conducted outside GitHub's review feature are all invisible to this record.
The same engine run on pallets/flask (16 years old, pre-AI era, 3,812 commits) shows the Index distinguishes different kinds of knowledge risk rather than flattering old code or damning new code.
| cline/cline (AI-era, 2 yrs) | pallets/flask (pre-AI, 16 yrs) | |
|---|---|---|
| Living knowledge (weighted) | 79.2% | 83.8% |
| AI-attributed minimum | 5.0% | 0.1% |
| Active humans (90d) | 35 of 322 ever | 1 of 866 ever |
| Worst module | evals (2% living, hot) | src/flask (51% living, quiet) |
| Dominant risk shape | Comprehension debt: fast-growing code with no living author, where sampled merges often show comment-free or AI-only recorded review | Concentration risk: knowledge is alive but every module is bus-factor 1; a single active contributor holds the dominant commit share |
Flask's headline numbers look healthier, until you see that its living knowledge is concentrated in a single active contributor. The two repos carry risk in opposite shapes, and a velocity dashboard would flag neither.
The same engine run across 22 public repositories in five groups: AI-era agents and apps, AI vendor SDKs, modern human-led projects, and pre-AI controls. Sorted darkest first by living knowledge.
| Repository | Group | Living knowledge | AI-attr. minimum | Inactive | Squashed | Active / all-time humans |
|---|---|---|---|---|---|---|
| openai/openai-python | AI SDK | 19% |
86.8% | 25% | 44% | 6 / 179 |
| anthropics/anthropic-sdk-python | AI SDK | 22% |
77.4% | 8% | 46% | 12 / 65 |
| langchain-ai/langchain | AI-era app | 48% |
1.6% | 62% | 97% | 42 / 4,547 |
| gin-gonic/gin | pre-AI control | 49% |
1.1% | 58% | 99% | 15 / 565 |
| expressjs/express | pre-AI control | 56% |
0.0% | 60% | 71% | 10 / 386 |
| RooCodeInc/Roo-Code | AI-era agent | 57% |
13.2% | 62% | 57% | 3 / 352 |
| flask | pre-AI control | 62% |
0.0% | 22% | 2% | 1 / 846 |
| continuedev/continue | AI-era agent | 69% |
2.6% | 52% | 7% | 4 / 539 |
| django/django | pre-AI control | 70% |
0.0% | 35% | 0% | 55 / 3,244 |
| psf/requests | pre-AI control | 71% |
0.1% | 19% | 39% | 11 / 781 |
| browser-use/browser-use | AI-era agent | 72% |
2.2% | 37% | 0% | 12 / 356 |
| tailwindlabs/tailwindcss | modern human-led | 76% |
0.4% | 31% | 88% | 18 / 415 |
| All-Hands-AI/OpenHands | AI-era agent | 78% |
45.1% | 23% | 100% | 59 / 620 |
| langgenius/dify | AI-era app | 78% |
32.5% | 30% | 100% | 201 / 1,749 |
| sst/opencode | AI-era agent | 79% |
14.9% | 8% | 38% | 162 / 1,095 |
| vercel/ai | AI SDK | 81% |
8.3% | 13% | 97% | 146 / 920 |
| fastapi/fastapi | modern human-led | 81% |
11.3% | 17% | 48% | 15 / 1,018 |
| cline | AI-era agent | 82% |
1.6% | 16% | 65% | 42 / 394 |
| crewAIInc/crewAI | AI-era agent | 85% |
8.0% | 12% | 55% | 27 / 343 |
| astral-sh/ruff | modern human-led | 88% |
0.4% | 10% | 97% | 118 / 963 |
| lobehub/lobe-chat | AI-era app | 90% |
21.8% | 3% | 58% | 53 / 405 |
| curl/curl | pre-AI control | 92% |
0.0% | 4% | 0% | 52 / 1,483 |
Squashed is the share of analysed commits that collapsed a whole pull request into one, which credits one author for everyone's work and usually strips the co-author trailers naming the rest. It is shown because it limits comparability between repositories, though across these 22 it correlates only weakly with the score (r = −0.28) and ranges from 0% to 99% inside the pre-AI controls alone.
Window coverage is the share of each repository's recorded work that the 3-year window contains; the score describes the window, and the excluded older work skews toward inactive authors. It sits under half for 7 of these 22, lowest in psf/requests (2%), expressjs/express (3%), django/django (6%), flask (9%), gin-gonic/gin (17%), tailwindlabs/tailwindcss (20%) and 1 more. Those scores read as statements about recent work rather than the whole tree; the survivorship view answers the whole-tree question.
Window coverage is the share of each repository's recorded work that the 3-year window contains; the score describes the window, and the excluded older work skews toward inactive authors. It sits under half for 7 of these 22, lowest in psf/requests (2%), expressjs/express (3%), django/django (6%), flask (9%), gin-gonic/gin (17%), tailwindlabs/tailwindcss (20%) and 1 more. Those scores read as statements about recent work rather than the whole tree; the survivorship view answers the whole-tree question.
Window coverage is the share of each repository's recorded work that the 3-year window contains; the score describes the window, and the excluded older work skews toward inactive authors. It sits under half for 7 of these 22, lowest in psf/requests (2%), expressjs/express (3%), django/django (6%), flask (9%), gin-gonic/gin (17%), tailwindlabs/tailwindcss (20%) and 1 more. Those scores read as statements about recent work rather than the whole tree; the survivorship view answers the whole-tree question.
Window coverage is the share of each repository's recorded work that the 3-year window contains; the score describes the window, and the excluded older work skews toward inactive authors. It sits under half for 7 of these 22, lowest in psf/requests (2%), expressjs/express (3%), django/django (6%), flask (9%), gin-gonic/gin (17%), tailwindlabs/tailwindcss (20%) and 1 more. Those scores read as statements about recent work rather than the whole tree; the survivorship view answers the whole-tree question.
Window coverage is the share of each repository's recorded work that the 3-year window contains; the score describes the window, and the excluded older work skews toward inactive authors. It sits under half for 7 of these 22, lowest in psf/requests (2%), expressjs/express (3%), django/django (6%), flask (9%), gin-gonic/gin (17%), tailwindlabs/tailwindcss (20%) and 1 more. Those scores read as statements about recent work rather than the whole tree; the survivorship view answers the whole-tree question.
Window coverage is the share of each repository's recorded work that the 3-year window contains; the score describes the window, and the excluded older work skews toward inactive authors. It sits under half for 7 of these 22, lowest in psf/requests (2%), expressjs/express (3%), django/django (6%), flask (9%), gin-gonic/gin (17%), tailwindlabs/tailwindcss (20%) and 1 more. Those scores read as statements about recent work rather than the whole tree; the survivorship view answers the whole-tree question.
What the 22 repos show. Group medians: modern human-led 77% · pre-AI controls 66% · AI-era agents 58% · AI-era apps 34% · AI SDK group 6% (two of its three members, the OpenAI and Anthropic Python SDKs, score 3% and 6%; the third, vercel/ai, is largely hand-written and scores 74%). An essential reading note on the SDK repos: both are produced by automated code-generation pipelines from API specifications, which is a deliberate, industry-standard engineering choice. Low living commit-authorship in a generated repo reflects that workflow; the relevant human comprehension plausibly resides in the generator and the API specification, which repository-level metrics structurally cannot observe. These scores describe public commit history only. They are not a claim that any organization's engineers do not understand their products, and not a claim about the quality, security, or fitness of any software. Elsewhere the pattern is starker: comprehension debt predates AI. Express, 15 years old and foundational to the npm ecosystem, shows 83% of its recent lines authored by contributors no longer active, while 25-year-old curl is the healthiest repository in the benchmark. Age determines nothing; living maintenance does.
The engine measures living knowledge two ways, and the two proxies err in opposite directions, which is why both are run. Line-weighting (this report) weights authorship by lines added: it matches "what fraction of the code by volume has a living author," but lets verbose authorship (especially generated code) dominate. Touch-weighting weights each file-touching commit equally: it better matches how comprehension actually forms (repeated engagement, not text volume), but counts a 3,000-line generated commit the same as a one-line fix. Scores are comparable only within a mode, and every Grasp report states which mode produced it. The full benchmark was computed in both modes, and the findings hold in both: the codegen SDK repos score 3–6% line-weighted and 1–4% touch-weighted; curl scores 94% and 95%; the group-by-group gradient is unchanged. When two differently-biased instruments agree, the conclusion is stronger than either alone.
All data in this report derives from publicly available repository metadata (commit history and pull-request records) analyzed with the disclosed method. Every metric is a defined proxy computed from that record; living commit-authorship is an indicator of comprehension risk, not a measurement of any person's or organization's understanding. Nothing here asserts misconduct, negligence, or lack of competence by any contributor, maintainer, or company, and nothing here is a claim about the quality, security, or fitness for purpose of any software. Repository and project names identify public data sources; all trademarks belong to their owners, and no affiliation or endorsement is implied. Believe a number is wrong? Verified errors are corrected and this report is versioned. Find one? Contact support@graspscore.com.