Challenge me to a codebase scan
What a scan tells you
Not lines counted — what development actually did. The engine (CodeDelta, my creation) diffs two snapshots of a codebase and classifies every logical statement as changed in place, deleted, or added. From that you get numbers a line counter can’t produce: how much of the year’s work was new code versus repair of existing code (REWORK ), which parts of the tree took the change, and how the project’s development “shape” compares to a corpus of 1,412 repo-year measurements across 135 repositories (2010–2026). It’s deterministic arithmetic — no sampling, no ML — so every published figure comes with the two commit hashes that reproduce it.
The addiction so far
Chromium, calendar 2024 — the codebase behind Chrome, Edge, Brave and Opera. Two New Year’s Eve snapshots, 43.5 million lines each:
4,534,768 logical statements churned — 12,390 per day, weekends included
143,396 files touched — 44% of the entire 326,948-file tree in one year
2.4M statements added, 1.7M deleted, and just 411,167 — 9.1% — edited in place
Scanned in 105 minutes on a MacBook with 8 GB of RAM , reading off a USB drive
That 9.1% is the interesting bit: mega-projects (WebKit, Linux kernel, FreeBSD, IntelliJ) all rework 5–10% of their churn, mid-size established projects like curl and PostgreSQL run ~17%, and intensively AI-agent-built codebases collapse below 1%. The fingerprint holds at every scale I’ve found. Full report with hashes: the Chromium paper.
Erlang/OTP, 2020–2026 — six and a half years, seven windows, and the discovery that in 2026 OTP is running its deepest maintenance regime of the series (REWORK 22.6%, double any earlier year). It also broke my engine once and cloc three times along the way — that story is here.
The challenge
Name a codebase. I’ll scan it and publish the results on this site — the same full treatment: size and composition, churn windows, REWORK against the corpus, per-language breakdown, and the commit hashes so you can reproduce every number. The rules, such as they are:
Public git repository — GitHub, GitLab, sourcehut, a public googlesource — anywhere I can clone from.
Some history to measure — a year or more is ideal (that’s one churn window); older projects are better, I can cut yearly windows back through a decade.
Any size. Chromium-class monsters welcome — the engine has done 43.5M-line snapshots on 8 GB of RAM. If you can name something bigger, please do; I want the record broken.
Any language mix. Polyglot monorepos, vendored trees, generated code — the scan states its file coverage on every run and names what it didn’t measure, so hostile trees are the fun ones.
Nothing is executed — the engine reads source text. I never need to build your suggestion, which is lucky, because nobody can build Chromium on an 8 GB laptop.
Suggest in the thread, or email [email protected] if you want to be told when your scan is up. I’ll work through the most interesting suggestions and publish each one at codedelta.app/papers with its reproduction hashes. If your suggestion turns out to break the engine — Erlang/OTP managed it — that gets written up too. Fair’s fair.
And if you’d rather run the scans yourself: CodeDelta is free to try until the end of August. Try it and tell me what you think.