Faster,
not hollower.

Something quietly changed in how software gets made.

For as long as people have written programs, writing was also how we learned them. You typed the loop, so you knew why it stopped. You chose the retry limit, so you remembered the outage that taught you to. Understanding wasn't a separate activity. It was a side effect of the work.

AI removed the side effect.

Today a working feature can arrive in minutes, get reviewed in two, and be merged before anyone has built a picture of how it behaves when the bank times out. The code is fine. The understanding never formed. Multiply that by every change, every week, and you get software that runs but that nobody in the building can fully explain. People have started calling it comprehension debt. Like every debt, it stays invisible until it's due — usually at 2 a.m., usually the week after the one person who understood the system left.

In 1985 the computer scientist Peter Naur argued that a program isn't really its source code. It's the theory held in its programmers' heads: why each part exists, how the parts fit, what would break if you changed them. The text is a shadow of that theory. When the people who hold it leave, the program, in Naur's sense, dies — it keeps running, but it can no longer be safely changed.

That was a warning about people leaving. In the age of AI, it describes the default.

We don't want to slow down.

We aren't nostalgic about typing every line by hand, and we don't think the answer is to use less AI. We use it every day. The speed is real, and it's good.

The answer is to rebuild the loop on purpose: to make understanding form deliberately, in small moments, right alongside the speed. Not in a training course six months later. Not in a wiki nobody reads. In the two minutes after you ship something, while it's still yours.

The research already points the way. In a 2026 randomised trial, engineers who coded with AI understood less of what they built than engineers who coded by hand — except the ones who used AI to explain, not just to write. Their understanding stayed high. The tool wasn't the problem. The habit was.

So we build tools that turn that habit into something automatic, measurable, and shared by the whole team.