A deterministic, ML-free churn-shape metric pair — REP_CHURN and its complement REWORK; measurements across nine codebases showing hand-maintained projects edit one statement in six while an agent-built codebase edits one in five hundred; their limits; and how to reproduce every figure with git and arithmetic.
Conventional churn analysis counts lines added, deleted, and changed between two snapshots of a codebase. This paper examines the shape of that churn rather than its volume. We define a complementary metric pair: REP_CHURN = (ADD + DEL) / CRN, the share of all change activity that was insertion and removal rather than in-place modification, and REWORK = CHG / CRN, the share spent editing statements that already existed. The hypothesis is that AI-assisted development exhibits a distinctive replacement-dominant signature — generated code is accepted or regenerated, rarely hand-edited — whereas human development characteristically includes a substantial component of in-place editing. Measurements across nine codebases support the hypothesis: three established hand-maintained projects with near-zero AI-agent commit attribution (a JavaScript framework est. 2010, a C networking tool est. 1998, a C relational database est. 1996) cluster tightly at REWORK 17% — one statement edited in place for every six churned — while an intensively agent-assisted codebase measures REWORK 0.19%: one in five hundred, a ninety-fold collapse in editing activity (REP_CHURN 0.83 versus 0.998). Two deliberate counter-probes bound the claim: bug-fix-only maintenance branches show the same ~17% band, but pre-AI hypergrowth windows (deno, esbuild, vite, Kubernetes, 2015–2021) measure REWORK 1.6–7% — rapid human growth also collapses the editing share, so the band characterises established projects and a low value alone is not evidence of AI involvement. Because REP_CHURN compresses large differences near the top of its bounded scale, all comparisons in this paper are quoted in REWORK terms. The metric is deterministic diff arithmetic — no machine learning, no stylistic inference — and every figure is reproducible from public history. We state its failure modes explicitly: bulk file moves, vendoring, and greenfield growth also produce high values, so REP_CHURN indicates a development process, not the authorship of any individual change. All measurements were made by applying CodeDelta (codedelta.app), the authors’ source-code change-analysis engine, across the repositories, branches, and historical windows above — every figure reproduces from public history with a single command.
We compared two versions of each project and sorted every changed statement into four piles: brand new, deleted, edited in place, or torn out and replaced. The finding: long-established projects maintained by people edit a lot of their code in place — roughly one changed statement in six. A working application written almost entirely by AI coding agents edited almost nothing in place — about one statement in five hundred. AI tools tend to regenerate code rather than repair it, and that difference shows up in plain arithmetic on the code history, with no AI or guesswork involved in the measurement itself. One important caution: fast-growing young projects also edit little (they are mostly adding new code), so a low number alone does not prove AI involvement — the strongest signal is watching a project against its own history. Every figure in this paper can be re-checked by anyone from public code history.
Given the standard two-snapshot churn quantities over logical statements (LLOC) — CHG (statements modified in place), DEL (statements removed), ADD (statements introduced), and total churn CRN = CHG + DEL + ADD — define:
REP_CHURN = (ADD + DEL) / CRN
Its complement is important enough to be named as a metric in its own right:
REWORK = CHG / CRN = 1 − REP_CHURN
REWORK is the fraction of all change activity spent editing statements that already existed. The two metrics carry identical information but serve different purposes, and the difference matters. REP_CHURN describes the shape of a change on a bounded 0–1 scale (1 = pure insertion and removal, 0 = pure in-place editing). But because most churn in any living project is the addition of new code, real values crowd the top of that scale, and comparisons made there mislead: 0.83 versus 0.998 reads as a small difference when the editing activity underneath differs by a factor of ninety. Comparisons should therefore always be quoted in REWORK terms, where a 90-fold difference looks like one: a rework rate of one statement in six versus one in five hundred. This paper states results both ways but draws every conclusion from REWORK. The classification of statements into CHG/DEL/ADD follows the two-pass sequence-alignment method described in Paper A; neither metric adds new measurement machinery, only ratios over quantities already computed.
Human work on source code characteristically includes a substantial component of editing: renaming, adjusting conditions, threading a parameter, tightening an expression. Each such act modifies existing statements in place and is classified as CHG. Development assisted by code-generating AI proceeds differently as a matter of workflow mechanics: the tool produces a block; the human accepts, rejects, or asks for regeneration. Unsatisfactory code tends to be replaced by a new generation rather than repaired line by line. At the diff level this produces DEL + ADD patterns rather than CHG, regardless of the style or quality of the generated text.
This suggests a process signature that is invisible to stylistic authorship detection but visible to plain churn accounting: as AI assistance increases, REWORK should collapse. Because the signature arises from the workflow rather than the text, it cannot be prompt-engineered away, and it does not degrade as generation quality improves — if anything, better generators make replacement cheaper and the signature stronger.
Nine codebases were measured. For eight public repositories, two snapshots were taken (1 January 2026 and 2 July 2026, the nearest default-branch commits preceding each date) and compared with a two-pass LLOC differ (Paper A). Express was additionally measured over a 3½-year window (1 January 2023 → 2 July 2026) to rule out small-window effects, since it churns little in any six-month period. The ninth subject is an AI-built reference application: a working commercial-grade codebase written almost entirely by AI coding agents (65.9% of its commits carry agent co-authorship trailers), measured over one month of active development (1 June – 3 July 2026) with full repository access, using the same engine in git-native mode. Two boundary probes complete the design, both reported with the results: PostgreSQL’s bug-fix-only stable branches (maintenance-phase human work), and pre-AI hypergrowth windows of deno, esbuild, vite and Kubernetes (2015–2021 — before AI coding assistance, hence human-only by construction).
Instrumentation. Every churn quantity in this paper was measured with CodeDelta, the authors’ source-code change-analysis engine, in its git-native mode: codedelta --git <old>..<new> snapshots two refs and computes the full CHG/DEL/ADD classification in one command. The runs behind this study span trees from a 165-file JavaScript framework to Kubernetes at its 2015 peak — 576,843 LLOC of churn in a single window — each measured in seconds to minutes on one laptop, across C, C++, Go, JavaScript/TypeScript, Python, Rust and the rest of the engine’s 43 languages. The engine’s measured scale ceiling is far above anything in this study: single-window scans of up to 6.96 million LLOC of churn (OpenJDK’s 2017 history-consolidation window) and 4.53 million (a year of Chromium — a 43.5-million-line, 326,948-file tree) have each completed in one command on consumer hardware; the full measurement campaign behind those figures is reported separately (Paper E, in preparation). The attribution ground truth uses the engine’s git-evidence module. The same engine serves a broader family of code-analysis tasks — longitudinal trend databases, per-file change classification, AI/agent-usage scanning, CI merge gates — of which this study exercises the churn and git-evidence components.
As independent ground truth for the degree of AI involvement, each repository’s commit history was scanned for machine-readable AI co-authorship attributions — Co-Authored-By trailers and equivalent markers left by named AI coding agents (GitHub Copilot’s agent, Claude Code, Cursor, and eight others). Such attribution is voluntary and strippable, so measured rates are floors, not totals. Matching is exact-pattern against agent-specific strings; dependency bots and other scripted automation cannot match.
First, what each project is — the scale and make-up of the measured codebases (new-version totals):
| Codebase | Total SLOC | Total LLOC | Comment lines | Comments per 100 SLOC |
|---|---|---|---|---|
| Express | 16,095 | 4,660 | 1,787 | 11.1 |
| curl | 237,769 | 117,774 | 70,710 | 29.7 |
| PostgreSQL | 1,341,727 | 635,543 | 569,824 | 42.5 |
| LangChain | 307,342 | 137,721 | 17,381 | 5.7 |
| FastAPI | 96,707 | 32,634 | 1,637 | 1.7 |
| Redis | 267,585 | 151,424 | 79,180 | 29.6 |
| CrewAI | 234,011 | 133,813 | 3,696 | 1.6 |
| GitHub CLI * | 235,882 | 82,805 | 9,830 | 4.2 |
| Reference app (AI-built) | 205,859 | 109,190 | 112,881 | 54.8 |
Sizes span two orders of magnitude — Express is a deliberately small anchor (16k source lines); PostgreSQL is eighty times larger. Python-family projects show few comment lines because docstrings are string literals, not comments. The measurements below are therefore rates and shares, never raw-size comparisons.
All public repositories below are measured over the same six-month window — snapshots at 1 January and 2 July 2026. The reference application is measured over one month; the per-month column normalises the comparison.
| Codebase | Character | Agent-signed commits | Window | Churn (CRN LLOC) | Churn / month | REWORK (CHG/CRN) | REP_CHURN |
|---|---|---|---|---|---|---|---|
| Express | JavaScript framework, est. 2010, hand-maintained | 0.02% | 6 mo | 138 | 23 | 16.7% | 0.83 |
| curl | C networking tool, est. 1998, hand-maintained | 0 of 39,185 | 6 mo | 43,694 | 7,282 | 16.7% | 0.83 |
| PostgreSQL | C relational database, est. 1996, hand-maintained | 0 of 64,728 | 6 mo | 62,702 | 10,450 | 17.1% | 0.83 |
| LangChain | AI-infrastructure library | 0.3% | 6 mo | 35,387 | 5,898 | 10.3% | 0.90 |
| FastAPI | Python web framework | 0.03% | 6 mo | 14,817 | 2,470 | 8.6% | 0.91 |
| Redis | C database, est. 2009 | 0.1% | 6 mo | 17,262 | 2,877 | 6.6% | 0.93 |
| CrewAI | AI-native agents library | 4.0% | 6 mo | 90,674 | 15,112 | 2.7% | 0.97 |
| GitHub CLI * | Go tool; 249 Copilot-co-authored commits in the period | 2.2% | 6 mo | 73,374 | 12,229 | 0.9% | 0.99 * |
| Reference app (AI-built) | working application written almost entirely by AI coding agents | 65.9% | 1 mo | 99,450 | 99,450 | 0.19% | 0.998 |
Express barely moves in any six-month window (138 LLOC of churn — reported here because the volume column keeps every denominator honest). Measured over 3½ years (January 2023 → July 2026, CRN 2,103), its REWORK is 18.3% and REP_CHURN 0.82 — the same value, so the six-month figure is not a small-window artifact.
The same measurements, decomposed — because the ratios above are driven almost entirely by how each project’s change splits between growth, removal, and editing, the composition is presented in full for the reader’s own judgement:
| Codebase | Added (LLOC) | Deleted | Edited in place | Added % | Deleted % | Edited % | Add : Delete | Comment churn (CHG/DEL/ADD) |
|---|---|---|---|---|---|---|---|---|
| Express | 86 | 29 | 23 | 62.3% | 21.0% | 16.7% | 3.0 | 9 / 2 / 3 |
| curl | 20,688 | 15,704 | 7,302 | 47.3% | 35.9% | 16.7% | 1.3 | 2,581 / 3,584 / 2,780 |
| PostgreSQL | 38,979 | 12,977 | 10,746 | 62.2% | 20.7% | 17.1% | 3.0 | 5,890 / 3,771 / 13,439 |
| LangChain | 28,058 | 3,679 | 3,650 | 79.3% | 10.4% | 10.3% | 7.6 | 210 / 422 / 1,717 |
| FastAPI | 7,962 | 5,577 | 1,278 | 53.7% | 37.6% | 8.6% | 1.4 | 29 / 43 / 216 |
| Redis | 14,183 | 1,943 | 1,136 | 82.2% | 11.3% | 6.6% | 7.3 | 406 / 332 / 3,118 |
| CrewAI | 75,847 | 12,393 | 2,434 | 83.6% | 13.7% | 2.7% | 6.1 | 284 / 2,658 / 450 |
| GitHub CLI * | 17,832 | 54,891 | 651 | 24.3% | 74.8% | 0.9% | 0.3 | 71 / 82 / 837 |
| Reference app (AI-built) | 92,224 | 7,039 | 187 | 92.7% | 7.1% | 0.2% | 13.1 | 91 / 29 / 703 |
Three regimes are visible. Normal development: between 1.3 and 7.6 statements added per statement deleted — living projects grow, at different rates. Lifecycle events: an add-to-delete ratio below 1 marks cleanups and restructures (GitHub CLI’s repository reorganisation; Express, measured over 3½ years, spends a long code-shedding era at 0.3). And through all of it, the edited-in-place share of the established projects barely moves — 16.7–17.1% whether the project was growing three-to-one or shrinking one-to-three — while the AI-built application, the most addition-dominant profile in the table, edits 0.2%. The measurements are what they are; readers are invited to draw their own conclusions and to re-run any row from the snapshots in §06.
Finally, the same measurement at scale. The figures below are advance results from a larger campaign — over one hundred of the largest publicly accessible codebases, measured year by year from 2010 to July 2026 (to be reported in full separately) — included here so the instrument’s range is witnessed in this paper rather than claimed:
| Codebase | Window | Churn (CRN LLOC) | REWORK |
|---|---|---|---|
| Chromium | 2024 | 4,534,768 | 9.1% |
| WebKit | 2026 H1 | 4,166,219 | 10.4% |
| WebKit | 2022 | 3,743,648 | 4.6% |
| Linux kernel | 2024 | 1,436,681 | 9.3% |
| FreeBSD | 2015 | 1,362,937 | 7.0% |
| IntelliJ Community | 2020 | 886,482 | 7.6% |
| Godot | 2025 | 624,317 | 4.9% |
| OpenJDK | 2017 † | 6,964,754 | 0.0% † |
† OpenJDK’s 2017 window is its repository history-consolidation — an import event, not development — and is included as the largest single scan performed (6.96 million logical statements of churn in one command) and as a worked example of the lifecycle-event regime: near-zero editing at enormous churn marks bulk repository operations, not generate-and-replace development. Note also that the very largest projects rework at 5–10%, below the mid-size established band of ~17% — scale itself shapes the editing share; the full size-stratified treatment is Paper D’s subject. Snapshot pairs for all eight rows are in §06.
The REWORK column tells the story most plainly. The three hand-maintained projects — different languages, different eras, churn volumes spanning three orders of magnitude — cluster within half a percentage point of one another: roughly 17% of all churn spent editing what exists, one statement in six. The agent-assisted end edits one statement in five hundred — thirty times below the lowest hand-maintained value, ninety times below the cluster. The gradient tracks the independent attribution ground truth throughout — with one instructive exception, marked *, discussed below. In absolute terms, the agent-assisted subject also produced churn at roughly six times the monthly rate of the fastest-moving public repository in the sample — replacement-dominant development is fast as well as differently shaped.
The tightness of the hand-maintained cluster was not anticipated and should be read cautiously — three repositories establish a coincidence worth investigating, not a constant. But it is consistent with the rationale in §02: whatever humans are maintaining, a stable fraction of the work is repair-in-place, and that fraction does not survive the switch to generate-and-replace development.
One obvious objection was probed directly: perhaps the cluster is an artifact of growth-phase development, and maintenance-phase human work — mostly fixing what exists — would show a much higher editing share. PostgreSQL’s stable release branches accept only bug fixes, no feature work: pure maintenance-phase human effort. Measured over the same window, REL_17_STABLE gives REWORK 17.6% (CRN 3,741) and REL_16_STABLE 18.0% (CRN 3,335) — the same value as the growth-phase cluster. Even bug-fix-only human work turns out to be add-dominant, because fixes bring their guard code and regression tests with them. Six human measurements — three growth-phase projects, one 3½-year window, two maintenance-only branches — fall between REWORK 16.7% and 18.3%.
The opposite probe tests the band’s other boundary: young projects in hypergrowth, measured in windows that predate AI coding assistance and are therefore human-only by construction. Deno in the half-year around its 1.0 release (H1 2020) measures REWORK 4.0% (CRN 48,999); esbuild in its largely single-author hypergrowth (H2 2020), 1.6% (CRN 44,263); vite in its v2 spring (H1 2021), 7.2% (CRN 3,953); Kubernetes in its post-1.0 explosion (H2 2015), 3.3% with vendored dependencies excluded (CRN 260,036; 2.5% including them). Rapid human growth also collapses the editing share — to within an order of magnitude of the agent-built value. The ~17% band therefore characterises established projects, not human behaviour as such, and a low REWORK value alone is not evidence of AI involvement. Every human measurement, including the hypergrowth floor, still sits above the agent-built subject (1.6% versus 0.19%, an 8× gap) — but with a single agent-built subject measured, that margin should be treated as an observation, not a threshold. The robust inference is longitudinal: an established codebase whose REWORK falls out of its own historical band has changed how it is developed.
* The GitHub CLI figure includes a large repository restructure in the measurement window: bulk file moves classify as DEL + ADD and inflate REP_CHURN. This is the metric’s principal failure mode, and the reason the value carries an asterisk rather than a conclusion.
The defensible claim, stated once and precisely: a collapsed REWORK rate — equivalently, replacement-dominant churn — is characteristic of AI-assisted development; it is not proof of it.
Why organisations should measure this continuously. Three independent lines of published evidence argue that the shape of change deserves standing, strict monitoring rather than occasional inspection. GitClear’s longitudinal analysis of hundreds of millions of changed lines (2020–2024) — a different instrument, on a different corpus — reports the same direction of travel measured here: refactored (“moved”) lines collapsed from 24.1% to 9.5%, code revised within two weeks of landing nearly doubled (3.1% → 5.7%), and 2024 was the first year on record in which copy-pasted code exceeded refactored code [4]. Veracode’s testing of code from more than 100 generative models across 80 tasks found 45% of it failed security analysis, including OWASP Top-10-class flaws [5] — defects that compile, run, and pass casual review. And the July 2025 Replit incident — an autonomous coding agent that deleted a production database during a declared code freeze, fabricated roughly 4,000 user records and fake test results, and misreported that rollback was impossible [6] — demonstrates that an agent’s own account of its actions cannot serve as the control. Together these point to the practical conclusion of this paper: the development process should be monitored from the artifact itself — deterministic measurement of what changed and how, made continuously and compared against the codebase’s own history — rather than taken on trust from tools, vendors, or self-reports.
Every figure above can be reproduced without specialised tooling:
git rev-list -1 --before=<date> HEAD, then git worktree add).codedelta --git <old>..<new> produces all quantities in one command. Alternatively, any differ implementing the method of Paper A will produce closely comparable ratios.git log scan for agent co-author trailers.The exact snapshot commits used for every figure in §04 (old → new, default branch):
expressjs/express c2fb76e99f73 → 18e5985b8a9d
express (wide window) 442fd4679929 → 18e5985b8a9d
curl/curl 1ca678472fb5 → 84ecfb3ecc79
postgres/postgres 85d5bd308bf5 → 53e6f51eef55
pg REL_17_STABLE 174bbc06775c → c768637d6c29
pg REL_16_STABLE 130b001c1523 → d569ccd40858
langchain-ai/langchain a7aad6098958 → 0501325e6c53
fastapi/fastapi 53d2453d1a77 → cecd96d9c6c3
redis/redis 174307530bd3 → 5b22a0991874
crewAIInc/crewAI f3c17a249b5a → 2b90117e887e
cli/cli 5761a1e66965 → b300f2ec7ec9
denoland/deno (2020) 4258ed262f6e → 851344f2ed58
evanw/esbuild (2020) 57d6f87e089f → bacc752022db
vitejs/vite (2021) 15ccf24ec827 → fa6380206496
kubernetes (2015) d5035a15e08a → eafb4c9687c6
WebKit (2026H1) 00f21fd71a27 → a942e1e61628
WebKit (2022) dc7de1da919a → 4f8c032ce380
torvalds/linux (2024) 610a9b8f49fb → cc0331e29fce
chromium/src (2024) 502dd46098ac → 2fc24fd052f0 (chromium.googlesource.com)
freebsd-src (2015) 7951040f8ada → 43a57fd1601b
intellij-community (2020) 8718df4f50ab → 0c989d58e64e
openjdk/jdk (2017) 608537a21843 → 2b6b6bb31d6b
godot (2025) 482531c4b83d → c8c0aa929740The AI-built reference application is a private repository, so its snapshot pair cannot be published for public re-running; its commit hashes and full measurement record are retained by the authors. Every public-repository figure above is independently re-runnable.
The proposed next study is longitudinal: the same repositories sliced year by year, 2019–2026, testing whether REWORK exhibits an inflection as AI coding assistance became widespread. The method above applies unchanged.