Nobody wrote this code

Here's a fun exercise. Go find a production incident from last month — a real one, the kind with a postmortem doc and a slightly haunted Slack channel — and trace it back to the line of code that caused it. Now ask the team a question that used to be the easiest question in software:

Who wrote this?

Watch what happens. Someone checks git blame. The commit belongs to Priya. But Priya says she didn't write it, exactly — she prompted it, skimmed it, and merged it, in roughly the time it takes to make a coffee. The model wrote it. Which model? Whichever one was wired up that Tuesday. With what context? Whatever happened to be in the window. Nobody knows, because none of that was recorded, because we never used to need to record it, because the author used to be a person you could ask.

Congratulations. You have just discovered the accountability vacuum, and your codebase has been filling with it for two years.

The warranty you didn't know you had

For the entire history of software, every line of code came bundled with a free, invisible, load-bearing guarantee: at the moment this line was created, at least one human brain understood it.

Not "understood it forever." Not "documented it." Just — for one shining moment, a person held that line in their head, along with its reasons, its assumptions, its little dangers. If the line was weird, it was weird on purpose, and the purpose lived in someone's skull, retrievable by walking to their desk.

This guarantee was so universal that we built our entire industry on top of it without ever naming it. Code review assumes it (the author explains, the reviewer checks the explanation). Debugging assumes it ("let's ask whoever wrote this"). Onboarding assumes it (juniors learn by asking authors why). Even git blame — the tool is literally named after the social contract — assumes that the name on the commit is a mind you can interrogate.

Peter Naur saw the deep version of this in 1985. In "Programming as Theory Building" he argued that the program isn't really the text at all — the real program is the theory in the builders' heads: why it's shaped this way, what breaks if you push there, which similarities are meaningful and which are coincidence. The text is just a lossy printout of the theory. Lose the theory, Naur said, and the program is effectively dead — you can run it, but you can no longer change it well.

Naur was worried about teams dissolving and taking the theory with them. He did not anticipate the 2020s solution: code that ships with no theory ever having existed.

A brief thought experiment involving a bridge

Imagine a city where bridges appear overnight. Good-looking bridges! Correct-looking rivets, plausible trusses, paint still wet. Each one was assembled by a machine that has read every bridge ever built and produces extremely bridge-shaped output. A licensed engineer walks across each new bridge once, bounces on it a little, and signs a form.

Now a bridge develops a crack. The city calls the engineer of record. The engineer says, honestly: "I didn't design it. I don't know why that beam is there. It looked like the beams I usually see. It bounced fine."

Every civil engineering body on Earth would set itself on fire. In software, we call this "shipping velocity" and put it in the investor update.

(To be clear — the machine-built bridges are often good. That's what makes this so slippery. If they were obviously bad, we'd have antibodies. They're mostly fine, occasionally subtly wrong, and uniformly unaccompanied by anyone who knows which is which.)

"But a human reviewed it" is doing a LOT of work in that sentence

The standard answer to all of this is that authorship doesn't matter because review is the real quality gate. A human approved the code; the human is the author-of-record; accountability preserved. Neat.

Except we have known for over a decade that review was never that gate. When Microsoft Research's Bacchelli and Bird studied modern code review across teams at Microsoft — the paper is literally titled "Expectations, Outcomes, and Challenges of Modern Code Review" — they found a gap between what everyone believed review did (find defects) and what it measurably did (mostly: style feedback, knowledge transfer, team awareness). Reviewers with low context, they found, struggle to find anything deep at all. And that was under the old regime, when the reviewer could at least assume the author understood the change and could be asked about it.

Review, it turns out, was never primarily a defect filter. It was an understanding ceremony — the ritual by which the author's theory got partially copied into a second head. Two people now sort-of understood the code, and that redundancy was the actual product.

Run that ceremony on code with no author-theory behind it and the arithmetic gets bleak: you used to end review with two partial understandings. Now you end with one partial understanding — the reviewer's, formed in minutes, of code nobody can explain — and we're calling that the same level of assurance because the ceremony looked identical from the outside.

One partial understanding, formed on a skim, is not a warranty. It's a vibe with a signature on it.

The vacuum has a shape

Here's what quietly disappears when authorship does. Not correctness — the code often works. What disappears is a set of answers to future questions:

• "Is this weird on purpose?" The retry loop with the odd backoff constant — deliberate workaround for a flaky vendor, or statistical noise from the model? The author would know. There is no author.
• "What was this protecting against?" Defensive code either guards a real dragon or clutters the cave. Deleting it safely requires the theory. There is no theory.
• "Who feels the pull to fix this?" Ownership was always partly emotional — your name on the commit, your wince in the postmortem. A prompt leaves no wince. Nobody lies awake about code nobody wrote.

And there's a nastier layer underneath, which the Stanford security researchers Perry, Srivastava, Kumar and Boneh measured directly: in their controlled study "Do Users Write More Insecure Code with AI Assistants?", participants working with an AI assistant produced less secure code than the control group — and simultaneously believed they had written more secure code. Sit with that combination. The vacuum doesn't just remove the person who understood the code. It hands the remaining person extra confidence they didn't earn.

So what do you do about a vacuum?

You can't legislate authorship back into existence. The models are not going away, and honestly, they shouldn't — the productivity is real and your competitors are keeping it. Telling engineers to "understand every line" at 2026 generation volume is telling them to hand-inspect a firehose.

What you can do is stop pretending the old warranty still applies, and start replacing it with something that doesn't depend on anyone's memory. The one witness that never needed the author is production itself: how often each function actually runs, how often it fails, what its latency is doing, whether anything calls it at all. Behaviour is authorship-blind — which used to be a limitation and is now the entire point. (This is precisely the gap runtime telemetry exists to fill; at CodeNSM we watch functions the way a floor supervisor watches a shift, because asking them who hired them stopped producing answers.)

But the first step is smaller and free: admit the warranty expired. The next nine posts in this series are a tour of what that expiry is doing to review, testing, mentorship, and comprehension — the whole immune system that quietly assumed someone, somewhere, once understood the line.

Somebody's name is on every commit in your repo. Ask them what the code does.

That silence you're imagining? That's the vacuum.