The authorless codebase

Onboarding into a software team has always been part code-reading, part conversation. The new joiner reads the code; the code raises questions; the new joiner finds the author and asks them. Why this and not that. What broke before this. Which constraint isn’t visible from where they are sitting. The codebase you can read is half the codebase. The other half lives in the heads of the people who wrote it.

That second half is thinning out, and most teams are still onboarding as if it weren’t.

A growing share of the code in any team that adopted AI tools in the last eighteen months is, in any meaningful sense, authorless. The git blame returns a name. The name remembers approving the diff. They cannot reconstruct why one path was chosen over another, because they didn’t choose; the model proposed and the human accepted. This is not a moral problem. It is an onboarding problem, and it changes what new joiners have to learn that didn’t exist before — and what mentors have to teach that they used to be able to skip.

Four of the techniques that made onboarding work quietly broke. Each has a remedy that is mostly cheap; the cheap part is also why most teams haven’t built it yet. Boring fixes get postponed.

1. The author interview — talking to no one

The first onboarding move is go ask whoever wrote this. On AI-authored code, that move now ends in a shrug. The author-of-record can describe what the code does, sometimes, but cannot tell you why one approach was picked over another, why a particular abstraction sits where it sits, or which constraint the design was reacting to. They didn’t make the call. They accepted it.

The new joiner, trained on a decade of mentors saying go ask the author, spends the conversation discovering that the author is not in the room. The model is gone. The artifact is the artifact. The reasoning behind it has to be reconstructed from the code itself, by the new joiner, often without the experience to do that reconstruction reliably.

The remedy is unglamorous: senior engineers have to re-author AI-generated code, retroactively, when they review it. Not in line-by-line comments — in a sentence at the top of the diff that says what the design was trying to do, what it could have done instead, and what constraint kept it from doing the alternative. This is the work the model didn’t do. If a senior engineer accepts an AI diff without doing it, they are accepting a piece of the codebase that has no author. New joiners pay that bill, six months later, in questions that have no answers.

The signal of a team that has internalized this: review comments include design rationale even when the diff is straightforward — because the diff doesn’t have an author who can be asked later. The review comment is the only place that thought lives.

2. Intent decay

Reading code well has always required an assumption: the way this is written reflects what the author was trying to express. Names mean something. Structure means something. Comments mean something. The code is dense with intent, and an experienced reader unpacks the intent as they read.

That assumption holds for hand-written code. It holds partially for code where a senior engineer has carefully reviewed and edited AI output. It does not hold for code where an AI proposal was lightly skimmed and accepted. There, the names are plausible rather than precise; the structure is idiomatic rather than intentional; the comments are stylistically appropriate rather than substantively necessary. The surface looks like intent. The substance is missing.

Call this intent decay. As a codebase accumulates AI-authored code, the what stays expressive — the code does what the code does — but the why thins out. New joiners trained on the older assumption read looking for intent and find a hall of plausible mirrors. They cannot tell which choices were considered and which were accepted; the code does not distinguish.

Two adaptations help. The first is at the team level: rebuild the substance of comments. Comments that say what the code does have always been low-value, and AI tools made them lower-value still — the model produces them for free. Comments that say why this and not that are now the highest-value comments in the codebase, because they are the only ones a model wouldn’t produce on its own. Teams that respond to AI adoption by writing more what comments are decorating; teams that respond by writing why comments are restoring substance.

The second adaptation is at the new joiner level: read with skepticism about intent. A name that sounds right is not evidence the choice was right. A structure that looks idiomatic is not evidence the structure was deliberate. The new joiner has to learn to ask, of every AI-shaped piece of code, was this chosen, or was this accepted? — and to extend less benefit-of-the-doubt to accepted code than to chosen code.

3. Plausibility patina

A codebase that has accumulated AI-authored code reads, paradoxically, as more consistent than a hand-written codebase of the same age. Style is uniform. Naming conventions are followed. The shape of files looks similar. To the new joiner walking in, this is reassuring; the codebase looks well-tended.

The reassurance is a patina. AI tools produce locally-coherent output across many files because they share training distributions, not because the codebase shares decisions. Underneath the stylistic uniformity, the architectural decisions can be inconsistent in ways the surface does not betray: two services that handle errors three different ways, three modules that do the same caching with non-interoperable contracts, four places where a config flag means slightly different things depending on which file is reading it. Hand-written codebases tend to wear their inconsistencies where you can see them; AI-shaped codebases hide them under shared style.

Call this the plausibility patina. It is the gap between “this codebase looks coherent” and “this codebase is coherent.” For new joiners, the patina is dangerous because it short-circuits the most important onboarding habit — suspecting that the codebase you are reading is messier than it appears, and going looking for the mess. Surface coherence is no longer evidence of architectural coherence, and the joiner who reads the patina as substance walks into the seams unprepared.

The remedy is to teach new joiners explicitly where the patina is thinnest, and point them at it. Module boundaries. Error handling. Configuration. Integration points. These are where AI-authored code most often diverges from itself across the codebase, and where a careful reader can see what the patina is hiding. The senior side of this work is to write down which inconsistencies the team knows about and has chosen not to fix. This used to be tribal knowledge. It can no longer be — tribal knowledge requires a tribe of authors, and half the authors are now models that don’t carry knowledge between sessions.

4. Trust topography

Pre-AI, every part of the codebase was, roughly, equally trustworthy in the same sense: written by humans, reviewed by humans, with the level of care the team usually brings. Post-AI, that uniform trust assumption is gone. Different regions of the codebase have different histories. Some are carefully reviewed AI output. Some are rubber-stamped AI output. Some are still hand-written. Some are AI-authored code that has since been hand-edited, which is a different beast again, with the AI’s pattern partially overwritten by human intent and partially preserved underneath. These regions have different probabilities of containing the recognizable shapes of confident wrongness. They merit different reading strategies.

This is the codebase’s trust topography, and new joiners have to learn it. The problem is that it lives nowhere. There is no map. The git history records who pressed merge, not who wrote what. Linters cannot detect a difference between deeply-considered AI-assisted code and lightly-skimmed AI output. The topography is real and invisible; new joiners walk through it without compass.

The cheap fix is to make some of it visible. Teams that adopt AI tools deliberately and want to be onboardable should mark, at the module or directory level, what their review confidence is. This module was rewritten with AI assistance and reviewed thoroughly; trust the contracts. This module was AI-extended quickly and the test coverage is shallow; treat as suspect. This module is hand-authored in the older style and behaves accordingly. The format does not matter. The existence does. A README, a comment block, a doc page — any of these is a transferable piece of trust topography, and any of them beats the alternative, which is folklore.

Teams that don’t write this down end up transferring the topography as folklore: the senior who has been there says “oh, don’t trust the billing module, that one got AI’d in a sprint and we never went back,” and the new joiner files it under tribal knowledge to be acquired by mistake. That is the slow form. It still works. It costs more than writing it down would, and it costs more than it used to, because the volume of folklore now scales with adoption.

What this changes about mentorship

The center of mass of onboarding mentorship was, for a long time, transferring tribal knowledge by being available to questions. The new joiner reads, runs into a wall, asks a question, the mentor answers, the loop closes. This worked because the mentor had the knowledge to transfer.

Under AI authorship at scale, mentors increasingly do not. They cannot tell the new joiner why a particular abstraction sits where it sits, because nobody chose; they cannot tell them why a name is what it is, because nobody named it deliberately; they cannot tell them which way error handling should flow, because the codebase contains three patterns and the mentor doesn’t remember which one was supposed to be the convention. The mentor’s authority over the codebase has been quietly replaced by their authority over its current state, which is a weaker position. The job has shifted with it.

It shifts in three places. From answering questions to teaching which questions can still be answered — many of the questions a new joiner will form, on first read, can no longer be answered, and learning to redirect those questions into ones the codebase or the team can still help with is the new mentor skill. From transferring knowledge to transferring calibration — the new joiner needs to learn which regions to trust, which to suspect, and how to tell the difference, and that calibration lives in instinct rather than facts; it is harder to transfer and at risk of being lost between mentor cohorts if it isn’t written down. From walking the codebase to walking the trust topography — the introduction tour used to be “here are the major components and what they do.” It now needs to be “here are the major components, what they do, and how the team currently feels about each one.” That second sentence is the part that didn’t exist before and now does.

None of this is harder than what mentors used to do. It is different, and most teams have not yet adjusted their habits to match. The fixes are the same boring ones the diagnostic surfaced: re-author at review time, write why comments, mark the trust topography, teach calibration explicitly. They cost time on the senior side, and they save weeks on the new-joiner side; the math works out, but the work has to actually happen, and “actually happen” is the part where most teams stop.

The first team meeting where someone says out loud we have written code we cannot now explain to a new hire is the meeting where onboarding starts working again. Most teams are weeks past needing that meeting and have not yet had it; their new joiners are absorbing the codebase’s actual difficulty as if it were their own difficulty, and the team is reading the new joiners’ struggle as a signal about the new joiners rather than a signal about the codebase. That misread is the slowest, costliest failure mode in this space, and the only way out of it is to name what changed.