CodeDelta's measurement approach is written up in two open technical papers, intended to be read and independently verified. No marketing language — just the algorithms, their assumptions, and their limitations.
In the public npm/cli release v10.9.0 → v11.0.0, 80.1% of all measured churn came from a single generated file — package-lock.json, which no developer edits. One file outweighed the other 144 changed files by four to one. This paper defines authored versus generated churn, measures it on public code you can re-run, and shows why an unfiltered churn figure cannot answer the questions managers actually ask: where is unexpected activity, and how much are mission-critical files really changing.
A 35-line file dissected through every counting tier: 35 lines, 25 source lines, 6 statements, 5 statements of working code. Then one ordinary commit — a reformat, a table refresh, one behavioural change — and the line counter reports 12 lines of churn where the truth is one changed statement. Every figure is real engine output you can reproduce by hand. Includes the provenance: statement-level churn was first demanded by an avionics organisation whose line counter couldn't tell them what changed.
Read the paper → · Download PDF ↓Seven windows of Erlang/OTP — the platform originally developed at Ericsson — measured statement by statement at 93% stated file coverage: 2 million logical statements of churn, and a 2026 finding no line count contains (REWORK 22.6%, the platform's deepest repair regime in the series). cloc 2.10 runs alongside on identical hashes as the reference for what conventional tooling sees: three windows failed, changed-files-only universe, reformat noise counted as change. Includes the withdrawn 55.6%-coverage first scan as an exhibit of why coverage must be stated.
Read the report → · Download PDF ↓A one-statement discrepancy during release verification led through 220KB single statements in OTP's JIT tables to GPU firmware committed as 3MB lines of C — and 28.4% of NVIDIA's open driver tree turning out to be data, not code. The result is a measurement nothing else provides: churn split into working code and data, element-level churn inside the tables, working-code REWORK, and whole-tree data composition. First finding included: OTP's 2026 repair regime survives the data filter — it is real engineering. Shipping in CodeDelta 1.8.8.
Read the report → · Download PDF ↓The calibration study Paper C calls for. 1,437 repository-year measurements across 136 of the largest publicly accessible codebases, 2010 to July 2026 — 393 million logical statements of churn measured, every figure reproducible from public commit hashes with one command. The finding is a stratified baseline, not a single number: established mid-size projects (curl, PostgreSQL) hold their in-place editing share near 17% across growth and maintenance alike; mega-projects (WebKit, the Linux kernel, FreeBSD, Chromium) run 5–10%, a stratum effect of vendored and generated bulk; intensively agent-built codebases fall below 1%. A low REWORK value can now be read against the right yardstick rather than in a vacuum.
Read paper D → · Download PDF ↓A measurement instrument is only as good as its proof of correctness. This paper is that proof, four ways. Value preservation: the study subjects reproduce bit-identically across engine revisions, and a 43.5-million-line Chromium window reproduces bit-identically across independent runs. Quantified error: the corpus campaign surfaced latent defects in long-lineage parsing code, all fixed — the worst measured effect on any result was one statement-level count in 46,146 (0.002%). Coverage: after the fixes, every previously-failing window measures cleanly, so the corpus has no silent holes. Accuracy at scale: a synthetic two-million-line single file with planted churn was measured exactly. The instrument does not merely survive scale — it stays correct across it.
Read paper E → · Download PDF ↓One calendar year of Chromium development, measured statement by statement in a single command on an 8 GB laptop: 43.5 million lines of code, 326,948 files, 4.53 million logical statements of churn, REWORK 9.1%. Full composition, the mega-project stratum comparison, the reproduction hashes, and the timing on consumer hardware. A worked demonstration of the instrument's range — witnessed, not claimed.
Read the report → · Download PDF ↓AI-assisted development barely edits code in place — it replaces it, measurably. This paper defines the deterministic, ML-free churn-shape metric pair REP_CHURN = (ADD + DEL) / CRN and REWORK = CHG / CRN, and reports measurements across nine codebases plus boundary probes: established hand-maintained projects (Express, curl, PostgreSQL) edit one statement in six (REWORK 17%) whether growing or in bug-fix-only maintenance; pre-AI hypergrowth projects (deno, esbuild, vite, Kubernetes) collapse to 1.6–7%; an intensively agent-assisted codebase edits one in five hundred (0.19%) — below every human value measured, tracking independent AI-attribution ground truth throughout. Every figure was produced by applying the CodeDelta engine to the repositories' public git history, one command per measurement. Failure modes are stated plainly — bulk moves, vendoring and greenfield growth also score high — and every figure is reproducible with git and arithmetic.
Read paper C → · Download PDF ↓How CodeDelta aligns two snapshots of a codebase and classifies every line as added, deleted, changed, or unchanged — across both physical lines (SLOC) and logical statements (LLOC). Covers the two-pass sequence-alignment algorithm, the similarity threshold for pairing deletions with additions into modifications, and the cases where the method is and isn't reliable.
Read paper A → · Download PDF ↓The basis for CodeDelta's Agent Scan: how to find where code invokes AI — agent-SDK imports, model endpoints, exec-on-model-output and prompt-injection patterns — and inventory it as an AI Bill of Materials for security and AI-governance review: data-sovereignty and egress to foreign-hosted models, runaway-cost patterns, and exec-on-model-output risk. It also surveys AI-generated-code (authorship) detection — and, importantly, the limits of each method class. Written for auditors and security managers, to set honest expectations rather than overstate certainty.
Read paper B → · Download PDF ↓Motivated by the 2024–2026 incident record — malware that queries a language model at runtime (LameHug/PROMPTSTEAL, PromptLock), AI-orchestrated intrusion, and the xz-utils backdoor. Surveys the in-code signals (model egress, dynamic execution, exec-on-model-output) and their evasion limits, why snapshot review structurally fails against a competent insider, and a complementary signal class computed from the shape of change against a historical baseline. Pointers for a reviewer, never verdicts.
Read paper F →