The abstraction collapse

Software has always been a tower. At the bottom: electrons doing physics. Above that: logic gates, instructions, assembly, compilers, runtimes, libraries, frameworks, your application code. The entire history of the field is the story of adding floors so that each generation could work higher up, moving faster by knowing less about what's below.

And this always worked, because of a rule so implicit nobody wrote it down: every floor kept a skeleton crew. When you moved up to Python, somebody stayed behind to maintain CPython. When you adopted the framework, somebody at the framework project actually understood the event loop. You personally didn't know what was under you — but you knew, structurally, that someone did, and that they were reachable through, at worst, a chain of GitHub issues.

The tower was never "everyone understands everything." It was "every floor is staffed." Hold that phrase. We're about to watch it break.

A new floor appears (and it's the nicest one yet)

The prompt level is, let's be honest, a genuinely wonderful floor. You describe intent; implementation materializes. The view is incredible. The productivity is real. And so, rationally, individually, blamelessly, everyone is moving in — juniors who never lived on the lower floors at all, seniors who are delighted to stop paying rent there, whole teams whose de facto unit of work is now the prompt, not the function.

Here's the thing though. Every previous floor was built by people who lived downstairs, and using it kept you loosely tethered to below — your compiler had documented semantics, your framework had source you'd at least stack-traced through. The prompt floor is different in kind: what's below it isn't a well-specified machine layer maintained by a staffed community. It's your own application code — freshly generated, unread, unowned (Part 1), untheorized (Part 7). The floor directly beneath the one everybody now lives on is the one floor that has never had a skeleton crew, because it didn't exist until the model exhaled it last Tuesday.

Joel Spolsky gave us the law that predicts the failure, back in 2002: all non-trivial abstractions, he wrote in "The Law of Leaky Abstractions," are leaky. TCP sometimes fails to hide the unreliable network beneath it; SQL sometimes forces you to think about the query planner; every abstraction eventually has a day where the thing it's hiding punches through, and on that day, someone has to understand the layer below. Spolsky's point wasn't that abstractions are bad — it's that they don't excuse you from the stack; they just let you defer it. The deferral always comes due on the worst day, because leaks, by definition, happen when the hidden thing misbehaves.

Prompting is the leakiest abstraction ever shipped. It's not even an abstraction in the engineering sense — no spec, no invariants, no guaranteed mapping from intent to implementation, quality varying with a die roll (Part 2), delivered in a voice that never wavers (Part 6). It WILL leak. It leaks constantly. And the question Spolsky's law asks — who understands the layer below when it does? — now has, for the first time in the tower's history, a null answer.

What "nobody holds the bottom" feels like from inside

The collapse won't announce itself. It arrives as a texture change in ordinary work, and you've probably already felt the early versions:

• A bug survives three "fixes" because every fix was a re-prompt — three fresh coats of paint over a crack in a wall nobody opened. The fourth engineer finally reads the actual code and finds the problem in minutes. Notice: reading below the signature has quietly become an escalation path, the thing you do when the normal method fails. It used to be the normal method.
• A performance mystery bounces between teams for a week, because diagnosing it requires holding the actual call graph in a human head, and every head involved holds prompts. METR's 2025 study is suggestive here in a way that should worry you: experienced developers using AI assistance on code they knew deeply got slower, not faster — and the deep familiarity is exactly what let them notice reality diverging from their expectations at all. Now remove the deep familiarity, permanently, industry-wide. Who notices the divergence then?
• The system develops behaviours no one decided on. Not bugs exactly — emergent policies. Retry storms from three independently-generated retry layers. A caching strategy that exists in four subtly incompatible dialects. Nobody chose this architecture. It accreted, prompt by prompt, and there is no level of the org chart where the accretion is anyone's job to see, because seeing it requires living on a floor that's vacant.

John Ousterhout's A Philosophy of Software Design gives the structural reading: good abstractions are deep — simple interfaces hiding real functionality, deliberately designed to be safely unexamined. Generated code, unread and unowned, is not a deep abstraction. It's just unexamined — shallowness with the lights off. The difference between the two is exactly the difference between a bank vault and a dark basement, and from upstairs, on a quiet day, they look identical.

The tower's actual load-bearing wall

Here's the synthesis this whole series has been circling. Across ten posts we've watched the same pattern in ten costumes: authorship vanished (Part 1), quality randomized (Part 2), scars stopped forming (Part 3), review went theatrical (Part 4), velocity decoupled from progress (Part 5), confidence decoupled from correctness (Part 6), comprehension fell behind existence (Part 7), the mentor channel closed (Part 8), tests started mirroring (Part 9). Every one of those was a system that silently assumed the same resource: somewhere, a human understands this. That assumption was the tower's load-bearing wall. Naur named the resource in 1985 — the theory, the living model in builders' minds that makes a program changeable rather than merely runnable — and warned that a program whose theory has died can only be handled by superstition.

The abstraction collapse is just this: the wall didn't crack. It was unstaffed. Everyone got promoted upstairs at once, the pay was great, and no relief shift was hired for the bottom of the stack — for the first time in the tower's seventy-year history.

So. What now?

Not nostalgia — nobody's moving back downstairs, and the productivity gains are real and yours to keep. The honest response has two parts, and they're both about replacing an assumption with an instrument.

First: accept that comprehension is now a scarce, allocatable resource — and allocate it. You cannot staff every floor. You can absolutely staff the rooms that matter: the small minority of functions carrying the traffic, the money, and the blast radius. Which rooms those are is an empirical question with an empirical answer — production knows exactly which code is load-bearing, even when no human does. (This is the premise CodeNSM is built on: when nobody holds the bottom of the stack, watch the bottom of the stack — every function's live behaviour, so the vacant floors at least have cameras, and your scarce human depth gets spent where the building would actually fall.)

Second: keep a deliberate descent capability. The skeleton crew used to happen by accident — some engineers just liked the basement. Now it has to be policy: rotations where someone reads the hot path below the signatures; incident reviews that ask "who understood the layer where this leaked, and how long did it take to find them?"; a norm that the top-ten load-bearing functions always have a named human who has actually read them. Small costs. They buy back the thing Spolsky's law says you'll need on the worst day.

The tower isn't falling. Towers with unstaffed floors don't fall on schedule — they stand there, magnificent, right up until a leak meets a vacancy on a day that matters.

You can't re-staff every floor. You can find out which rooms are load-bearing.

Go look at your codebase. Actually look.

That's the whole series, and the whole point.