A repository is an excellent record of what the machine will execute and a poor record of why. That asymmetry was survivable while the readers were people who had been in the room. It stops being survivable when the primary reader is a process that starts every session with no memory at all.
The repository is an incomplete account of itself
Source code states exactly what happens. It does not state what was considered and rejected, which constraints are legally binding versus merely conventional, which module is deprecated but still load-bearing, or which of two similar-looking functions is the one you are supposed to use. Those facts exist — in ticket comments, in chat threads, in a wiki nobody has permission to edit any more, and mostly in people.
Humans reading the repository silently merge those external sources back in. The merge is so fast and so habitual that it registers as reading the code rather than as supplying half the meaning. An agent performs no merge. It sees the files, and whatever the files say is the entire world.
What follows are five structural properties of ordinary, well-maintained repositories. None of them are signs of a bad team. All of them are actively hostile to a reader with no memory.
Failure mode one: authority
A filesystem has no concept of standing. A directory listing cannot tell you that architecture/event-sourcing.md is a live constraint while architecture/cqrs-migration.md is a proposal that lost. Both are files. Both are Markdown. Both are confidently written.
Given both, an agent will typically synthesise. It will read the constraint, read the proposal, note that they conflict, and produce something that partially satisfies each — which is the worst available outcome, because it is neither the current design nor the proposed one, and it looks deliberate. The full treatment is in proposal versus decision.
Failure mode two: staleness
Documents do not announce their age. A deployment guide written in 2022 renders identically to one written last Tuesday. Git history knows when the file was last touched, but "last touched" is not "last confirmed" — a typo fix in a two-year-old runbook resets the timestamp without anyone checking a single claim in it.
A human applies a rough discount for age using cues the file does not contain: they remember the migration, they know that stack was replaced, they notice the screenshot shows an old console. An agent applies no discount. It reads a superseded deployment procedure with the same seriousness as a current one and will attempt to follow it.
The correction here is not automated verification, which nobody has. It is making age explicit and inspectable, so that a reader — human or otherwise — is at least given the chance to weigh it.
Failure mode three: fragmentation
The moment a team adopts more than one agent tool, it acquires more than one instruction file. AGENTS.md, CLAUDE.md, .github/copilot-instructions.md, a Cursor rules file, a Windsurf rules file. Each was written at a different time, by a different person, with a different degree of care.
Nothing keeps them consistent. Somebody updates the one for the tool they use; the others quietly disagree. Now the repository does not have a policy — it has four policies, and which one applies depends on whose editor is open. Two developers can follow the repository's guidance faithfully and produce incompatible work.
This is worse than having no instruction files, because the disagreement is invisible. Nobody reads all four side by side. Each file looks authoritative in isolation.
Failure mode four: accumulation
The instinctive fix for a confused agent is to write more context. The instruction file grows. Someone adds a section on testing conventions, someone else adds a directory listing, someone adds a paragraph about a bug that was fixed eight months ago.
Two things then happen. The file becomes expensive — it is loaded on every request, and the useful constraints are now buried behind hundreds of lines of material the agent could have discovered by reading the repository. And it becomes unmaintainable — nobody prunes a document they did not write, so entries are only ever added.
The research on this is not encouraging. A 2026 study from ETH Zurich found that LLM-generated repository context files reduced task success while raising inference cost, and that repository overviews — the most commonly recommended section — provided no measurable benefit. More context, added without discrimination, is not neutral. See why generated instruction files can make things worse.
Failure mode five: departure
The knowledge that completes the repository lives in people, and people leave. When the engineer who designed the billing system goes, the repository does not change by a single byte, but it loses most of its meaning. What remains is a set of files that describe implementation without justification.
Teams have always absorbed this with a slow, painful rediscovery process: someone spends three months learning by breaking things. That process assumed a human successor who could ask around. As more of the reading and writing is done by agents that never ask and never accumulate, the rediscovery mechanism weakens at exactly the moment it is needed more.
The five compound rather than add
Taken individually, each failure mode is annoying and survivable. What makes ordinary repositories genuinely hostile is that they interact, and the interactions are multiplicative.
Departure creates staleness: when the person who maintained a document leaves, nobody notices it going out of date, because noticing required knowing what it described. Staleness creates authority confusion: a document old enough that nobody remembers its status is functionally the same as a document whose status was never recorded. Authority confusion creates accumulation: unable to tell which of three conflicting files is right, the reasonable response is to write a fourth explaining the situation, which is now the newest and most confident document in the set.
Accumulation then feeds fragmentation. As the instruction file grows unwieldy, someone splits it, or a new tool arrives with its own conventions and a fresh file gets written from scratch rather than reconciled. And fragmentation feeds back into authority confusion, because now there is no single place where a constraint is established.
The loop closes. Each pass leaves the repository slightly less legible than the last, and no individual step is large enough to trigger a response. This is why "we should clean up the docs" never gets prioritised: at any given moment the marginal decay is small, and it is only the accumulated total — visible in a way nobody measures — that hurts.
Agents amplify; they do not cause
Every one of these five failure modes predates AI tooling by decades. Undated documents, contradictory guidance, proposals that look like decisions, and knowledge bound to individuals are ancient problems. Teams survived them because human readers are unusually good at compensating for a bad record.
Agents remove the compensation. They read fast, read literally, act immediately, and produce plausible output regardless of the quality of their inputs. They also multiply throughput, so a repository's defects are exercised far more often per week than they used to be. The defect rate does not change; the exposure does.
This is why the productive framing is structural rather than behavioural. Nobody needs to be told to write better documentation — they have been told for thirty years. What is missing is a place where standing is declared as a matter of course and a mechanism that fails loudly when the structure of that place decays. Codee3 supplies both halves: a governed .ai/ layer with declared authority classes, and guards that fail CI on structural breakage inside it. The content is still yours to write.