Read the articles →
A library of technical and research papers covering true code churn, massive code base scans, rogue ai agent detection, measured ai v human coding practices, changed SLOC v changed LLOC v moved LLOC and associated articles.
Fourteen real hijacked releases of popular npm and PyPI packages, each set beside the clean release before it. Scanning each whole package found almost nothing. Measuring what changed put the attack in a single file in 7 of the 12 pairs that could be compared: 230 added statements in the only source file of five widely used npm libraries, a new 545-statement file in a sixth, 11 added statements in a Python package’s start-up file in a seventh.
Read the paper →Two public datasets record, turn by turn, what coding agents ran while attempting real GitHub issues: 3,900 runs, six models, 43,000 shell commands. Read with Agent Tracer: deletions in up to 4.5% of runs, the network in 3.5 to 20%, sudo 86 times, one model searching Google from inside the sandbox 23 times, and the same command repeated three or more times in a third to three quarters of runs. Every figure reproducible from the datasets.
What exactly is AI up to inside your organisation? Your coding agent keeps a detailed diary – it tells you everything you need to know. Every coding agent writes a full record of what it ran, deleted, pushed and sent, and nobody reads it. Agent Tracer reads those records after the fact and produces one report, offline: what the agent did, which model did it, what the human refused, what each session was for, and what changed since last week. Why it exists, what it does, how a company of 1,250 developers would deploy it, and its limits.
Read the paper → · See a sample report →"Rework" means deployments redone in DORA, hours re-spent in an estimate, and lines recently modified on a dashboard; "churn" means lines, files, staff or customers. This paper fixes the metrics CodeDelta reports — LOC/SLOC/LLOC, code churn, REWORK, REP_CHURN, TRUE_CHURN, moved code, data churn, U_LOC — with the everyday meanings, the definition used here, the formula, what the figure tells you and what it does not, and one measured value each.
Read paper H →What an AI agent looks like in source code, the four signals a scan reads for, the rogue pattern — a launch within ten lines after a model call, rated CRITICAL without qualification — the three ways the 2025 incidents hid a model inside a program, coverage across 22 languages in three tiers, and a worked scan of the public demonstration repository: 74 files, 29 CRITICAL, 2 HIGH, 27 ELEVATED, 16 NORMAL, reproducible by anyone.
Read paper G →Sort an import block and git reports a deletion and an insertion; a churn tool built on the same arithmetic reports two statements of churn for a program that did not change. Add, delete and change have no pile for a statement that simply went somewhere else, and the gap overstates churn, punishes tidying and pushes reorganised code onto the replacement side of REP_CHURN. CodeDelta 2.0 counts a move as a move.
Read the paper →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 →