Article · Foundations

Beautiful apps, rotten foundations

23 August 2026 · figures from the True Churn paper and the sources below

Nobody photographs the scaffolding. The castle gets the postcard — white stone, blue spires, gold rail — and the timber it stands on gets looked at once, on the day it was put up, and never again. Then one morning the ground is mud and the beams are full of grubs, and everyone is surprised.

An application is the same shape. The part you wrote, the part that is demonstrated and screenshotted and praised, stands on things nobody looks at: the libraries pulled in by a line in a manifest, the lockfile a tool regenerated, the bindings a generator emitted, the three files an agent wrote at three in the morning that nobody has read since. That is the timber. It carries the whole weight, and it is the part that rots.

We are not going to tell you how to build bug-free foundations, because nobody can and the people who claim to are selling something. We are going to tell you how to look at them, which is the part that is actually missing. Most teams cannot tell you how much of last quarter’s change landed in code a person wrote versus code a tool wrote, because the instruments they use do not know the difference. A line is a line.

We measure this for a living, so we measured it.

Take two releases of a real project and classify every changed statement by where it came from. Call the statements a developer typed authored churn, and the statements that tooling produced — lockfiles, generated bindings, compiled-in data — generated churn. Subtract the second from the first and you have what we call TRUE_CHURN*: the movement in the building, with the tremor of the scaffolding taken out.

npm/cli, v10.9.0 to v11.0.0: 80.1% of all measured churn came from one generated file.

* TRUE_CHURN, defined: the statement churn (added, deleted, changed in place) that remains after files matched by the generated-content rules — lockfiles, generated bindings and the like — are set aside; each excluded file is named, with the rule that caught it, so the subtraction is checkable. Method, the npm/cli measurement and the per-file evidence: the True Churn paper.

Four fifths. The castle gained a turret and the timber took four fifths of the movement, and a tool that counts lines will report the release as enormous and tell you nothing about which. That is not a rounding error in your metric; it is your metric measuring the wrong thing. Any number you put on a dashboard without making that separation first is a number about the scaffolding.

Now the grubs. The bugs that hurt most in the last decade were not in anyone’s castle. Log4Shell was a logging library — scaffolding, by any definition — and it put a remote-code-execution hole under a very large share of the Java on earth in December 2021. The xz-utils backdoor of March 2024 was a compression library sitting under SSH on Linux systems, placed there patiently over years by someone who understood exactly how little anyone looks at the timber. And in March 2016 an eleven-line package called left-pad was removed from a registry and builds across the industry stopped, because nobody knew it was holding anything up until it wasn’t. None of those three was the beautiful part. All three were load-bearing.

The objection writes itself: you cannot audit every dependency, every generated file, every line an agent wrote. Correct. You also cannot inspect every beam of a scaffold every morning. What you can do is see the structure — which beams carry which load, which were replaced last month, which ones nobody has touched since they went in — and look hardest where the load is. That is an instrument problem, and it is solvable.

So here is what we built, and you can judge whether it looks at the timber. Point CodeDelta at a project and open the Code Browser†. You get the whole tree, every file with its size and its language; which files include which, drawn as a map with the arrows pointing out of your directories into everything you did not write; every class or namespace with its methods, and the classes its code mentions, each mention cited to a file and line so you can check it; and, for a comparison of two releases, what changed in every one of them, with the generated files named and set aside. We ran it on a copy of redis at commit 78432ed: 1,842 files, 450,267 source lines, 16,071 functions, 15 cross-directory include links, 3 classes (it is C; the Classes tab says so rather than drawing nothing). Those are the numbers the page shows, and anyone with the same commit can get the same numbers; that is the standard every figure in this piece is held to.

† “Talks to” in the class view is a textual match — a class whose code mentions another class’s name — and is labelled as a pointer for review, not a resolved call graph. We would rather say that plainly than draw a pretty picture that cannot be checked.

Then run the Agent Scan over the same tree, and the timber gets one more colour: the files that call out to a model provider — which SDK, which endpoint, which jurisdiction the data would leave for — drawn as their own map. It does not tell you whether that code is good. It tells you it is there, and where, which is the thing nobody could tell you before.

Beautiful apps are fine. Build them. But the postcard is not the building, and the habit that keeps a building standing is dull: someone walks the scaffold, regularly, with a lamp, and writes down what they saw. The instruments exist. The walk is the part you have to decide to do.

Build the castle. Photograph the scaffolding.