The Authorless Codebase

The login flow works. You click through it five times and it works every time. Then you open the file behind it and find three functions that all look like they handle authentication — two of them never called, and the one that is called writes the session token to a place nothing else reads from. So you go looking for the person who wrote it, because there's clearly a reason it's like this, and you want to hear it before you touch anything.

There isn't one. The founder built this over a few weekends with a coding agent, raised a little money, and hired you to make it real. He can tell you exactly what the product does. He can't tell you why any particular line does what it does, because he never read it — he described what he wanted, accepted what came back when the screen looked right, and moved on. The prompts are gone. You're holding the output of a conversation nobody kept.

For a senior engineer, this should be familiar work. Inheriting code is most of the job. You've walked into legacy systems before and done the archaeology: run git blame, read the commit messages, find the Slack thread where someone argued for the weird workaround, reconstruct the reasoning until the strange decisions look like decisions. What you're really reconstructing is the why underneath the syntax.

That skill rests on an assumption so basic you've never had to say it out loud: somebody meant this. More than forty years ago, in his 1985 essay "Programming as Theory Building", Peter Naur described what a program actually is — a point drawn out sharply in this close reading for the AI era. The source code, Naur argued, isn't the program. The program is the theory — the working mental model of how the system fits together, why it's shaped this way, what was tried and rejected — and that theory lives in the heads of the people who built it. The code is a lossy export of that theory. Reading inherited code well means using it as a set of clues to rebuild the theory in your own head.

Now look back at the authentication file. Two unreferenced functions, a token written nowhere read. You start doing what you always do. You assume intent. Maybe the dead functions are a half-finished migration. Maybe the orphaned token is load-bearing somehow. You spend a morning tracing call paths, building the case for a design that explains all three.

There's no such design — no migration, no clever reason, no theory to recover, because no theory was ever built. The model produced three plausible-looking functions because plausible-looking functions are what an autoregressive model emits — it predicts likely continuations, it doesn't hold a design. The orphaned token is there because tokens usually get written somewhere, not because anything needs it. You're doing archaeology on a site where nobody was ever buried.

This is the authorless codebase, and it asks for a way of reading that senior engineers have never had to learn.

The texture of it is showing up in the data now. GitClear's analysis of 211 million lines of changed code, drawn from the repositories it tracks, found that as AI assistance climbed, duplicated code blocks rose sharply while refactored — "moved" — code fell to a multi-year low: more copy-paste, less of the consolidation a human does when they hold the whole design in their head. The 2025 Stack Overflow developer survey put a number on the felt experience: the single biggest frustration developers report with AI — cited by 66% of the developers who use them — is code that's "almost right, but not quite," with debugging that almost-right code the next complaint behind it. Almost-right is exactly what an authorless codebase is made of. It compiles, it demos, it passes the click-through. It just isn't about anything.

That's what makes it treacherous to inherit. Wrong code announces itself — it crashes, it fails a test, it throws. Almost-right code passes every surface check, banking credibility it never earned, and the bill comes due only under the one condition the demo never ran: real load, a strange input, the edge nobody clicked. You don't inherit a list of known bugs. You inherit a system that looks finished and isn't, with no marker for where the line runs.

Reading a human's code is archaeology: every artifact was left by someone with intent, so every oddity is a question that has an answer. Reading an agent's code is geology. The strata are real — you can measure them, build on them — but they were laid down by a process, not a person, and asking what the sediment meant is a category error. The trap that swallows good engineers in these codebases is doing archaeology on geology: spending days excavating for intent that the ground never had.

Geology calls for different tools. When you inherit one of these systems, change the question: stop asking "why did they do this," because the question has no addressee. Start asking what's true right now, not what was meant. Run the thing. Tests stop being a safety net and become the only theory you'll get — so the highest-leverage first move is writing the characterization tests the original "author" never did, pinning down what the system does before you reshape it. From there, what's worth keeping is a call only you can make — the codebase won't make it for you.

That's also the trap waiting in the other direction. A small METR randomized trial — sixteen seasoned developers working in repositories they'd contributed to for years — found they were about 19% slower when using AI tools, after predicting a 24% speedup; verification overhead was one of the factors behind it. If you let the same agent that produced the geology keep paving over it, you're not maintaining the system — you're adding strata. So once the demo works, the question that actually matters is simple: who's holding the theory while the agent keeps typing?

So when you inherit one of these systems, a few questions earn their place before any others:

• What does the application actually do, observed from the outside, independent of what the code claims?
• What touches money, customer data, or anything you can't undo — and is any of it sitting in code no one has read?
• What can you delete today, and what happens when you do?
• Where are the tests, and if there aren't any, what's the first behavior worth pinning down?

The founder who handed you this didn't make a mistake getting here. The agent got him from nothing to traction, and that was the right call at the time. But traction is where the job changes — from code that runs to a system that has to keep running, with someone accountable for it. That second job has never been about typing speed, and an agent can't hold it, because holding it means holding a theory and being answerable for it.

If you're staring at a working product nobody on your team can fully explain, that gap between it runs and we own it is exactly the seam we work in. Let's talk about what it takes to close it.