The shift in who reads code
For most of software history, design principles were written for a reader with a particular set of limits and strengths: a human sitting in an IDE, holding a rough mental map of the codebase, able to ask a colleague when the map runs out, and slow enough that a little extra indirection rarely mattered. SOLID, DRY, and layered architecture all assume that reader.
That reader is no longer the primary one. In an agent-first codebase, code is written, reviewed, and analyzed primarily by an agent — an LLM-driven program that reads, writes, and reviews code via tools. Humans still set intent and constraints, and still approve the changes that matter, but they rarely read the code line by line anymore. The code itself is authored and re-authored by agents, commit after commit, often faster than any human could review in full.
This is not a hypothetical near future. It is the working condition for a growing share of production codebases today, and it changes what "good design" means, because it changes the mechanics of the reader doing the design work.
Agent mechanics: what makes an agent a different kind of reader
An agent reading a codebase operates under constraints a human IDE user does not share, and lacks tools a human relies on without noticing.
Finite context, no persistent memory. An agent holds a bounded number of tokens in its context window — the finite token budget it can attend to at once — and, absent an external memory system, retains nothing between sessions. A human accumulates a mental map of a codebase over months; an agent reconstructs a working map, from scratch or from whatever files it re-reads, every time it starts a task.
Search instead of memory. Because an agent cannot hold a whole large codebase in context, it navigates by search: lexical search (grep/glob, as used by tools like Claude Code) or vector-index search (as used by tools like Cursor). Both approaches are approximate on large codebases, and both can miss. A well-documented failure mode is mundane and expensive: the agent does not find an existing utility through search, so it reimplements it, adding a duplicate that a human skimming the same directory would probably have recognized on sight.
Fragment reading. An agent typically reads a function, a file, or a small set of files relevant to the current task, not the whole system. Relationships that a human would infer from proximity, from having "seen this before," or from tribal knowledge absorbed in hallway conversations are invisible to an agent unless they are encoded somewhere the agent's search will actually surface them.
Degradation over long sessions. Even within the advertised context window, model performance degrades as a session grows — a phenomenon researchers have described as context rot. Research including Chroma's "context rot" study (2025) indicates the degradation is primarily a state-tracking failure rather than a reasoning failure: the agent does not get worse at logic, it gets worse at keeping track of what it already established earlier in the session. The practical consequence is severe: invariants that live only in the conversation — "remember, we decided X" — decay and vanish. Invariants must live in re-readable files, not in conversation memory.
Instructions are compliance, not enforcement. Agents can be told rules in prose — context files such as AGENTS.md or CLAUDE.md — and those files do help, but only within limits. Research on context files (ETH Zurich, 2025) found that curated, hand-written instruction files improved task success by roughly 4 percentage points, while autogenerated, unmaintained ones reduced success by about 3%, and that practical instruction budgets top out around 150-200 instructions before returns turn negative. The same research reports that compliance with a rule stated only in an instructions file runs around 25-40%, versus roughly 95% when the same rule is enforced as a runtime hook or a deterministic gate. An agent that reads "always do X" is not the same as a system that cannot proceed until X is true.
Why this produces new failure patterns
These mechanics do not just make agents worse at the same failures humans have; they produce failure patterns with a different shape.
Duplication instead of reuse. When search misses an existing utility, the path of least resistance is not "give up and go find it" — it is "write a new one that satisfies the current task." Aggregated across an ecosystem, this shows up as measurable drift. GitClear's AI Code Quality research, tracking roughly 200 million changed lines across 2024-2025, found copy-pasted code rising from about 8.3% to 12.3% of changed lines, refactored or moved code falling from about 25% to under 10%, and blocks of duplicated code growing roughly eightfold since AI coding assistants became mainstream. This is not evidence that agents are careless; it is evidence that search-based navigation, unaided, biases toward reimplementation over reuse.
Implicit conventions become invisible traps. A convention that lives in a senior engineer's head, or that is "obvious" only if you have read five other files first, is invisible to an agent reading a fragment. Temporal coupling — a hidden requirement that operations happen in a particular order, not expressed in types or signatures — magic strings, and undocumented formats are a leading source of agent-introduced bugs precisely because nothing in the immediate context signals that they exist. The fix is not better instructions; it is pushing the invariant into a form the agent's tools already enforce: types, lint rules, tests.
Self-review is not verification. An agent asked to check its own work is subject to the same blind spots that produced the work, plus a review-specific problem: LLM code review is noisy. Reported false-negative rates run around 24% and false-positive rates as high as 50%. In one documented case, a consensus of over 80 agent runs "confirmed" a vulnerability in OpenSSL that did not exist — a reminder that many samples from the same model are correlated, not independent, evidence. Multi-agent review with genuinely different lenses does help: the CodeX-Verify study reported a 39.7 percentage point improvement in defect detection over single-pass review. LLM review complements deterministic checks; it does not replace them.
Why human-IDE-era principles misfire here
None of this means SOLID, DRY, or layered architecture are wrong. It means they were tuned for a reader who navigates by accumulated familiarity and asks a colleague when stuck, and some of their standard applications quietly assume that reader is present.
Deep inheritance hierarchies and dependency-injection "magic" are efficient for a human who has internalized the framework's conventions and can jump straight to the relevant override; for an agent doing text search, the same hierarchy is a chain of indirection it must traverse call by call, at real cost to both time and correctness — an indirection tax. Strict DRY, applied preemptively, produces abstractions that fold several call sites into one shared function; a human can usually hold the shared function's several use cases in mind at once, but an agent editing one call site now has to reason about all the others too, which is a larger requisite context than editing one duplicated block would have been. Horizontal layering (controllers/, services/, models/) matches how humans learned to organize large teams around technical specialties; it scatters the files an agent needs for one capability across the directory tree, multiplying the number of search steps and the hop distance between an edit site and the knowledge required to make it safely.
None of these classic principles are being rejected as ideas. What changes is which version of each idea serves the primary reader well — and that recalibration is the subject of Relation to classic principles.
Where this leads
The six GARDEN principles are a response to these mechanics, not a stylistic preference: they are built around the idea that an agent must be able to find the right code quickly, hold only what it needs, treat contracts rather than code as durable, never certify its own work, keep invariants explicit and machine-checkable, and reach any knowledge it needs within one hop. The system these six principles form, and how they reinforce each other, is described in The garden model. For the canonical, standalone statement of each principle's rules, see GARDEN principles.