An agent needs context to work on a codebase, and it needs the right slice of it. Give it too much and the context window fills up: attention lands on whatever happened to be read first and last, everything between is diluted, and with each extra file the cost rises while the quality falls. More room also means more ways to run off in the wrong direction.

Computer science has had answers for finding that slice for a long time. Principles like modularity, information hiding, separation of concerns, and loose coupling/high cohesion have been defined since the ’60s and ’70s. They are what turn a large, complete codebase into a set of small, self-contained modules. A module in this (i.e. Parnas’s) sense draws a line around a decision and keeps the consequences inside it: the scope, the responsibility, the reach of a change, the vocabulary that holds, the point where a term starts to mean something else. The same line is what keeps a human developer’s cognitive load in check. Where it is missing, both human and AI agent guess, and guessing leads to the wrong software.

Hence the hypothesis of this talk: the architecture that makes a codebase legible to an agent is the architecture that has always made it legible to humans. A new reader for an old idea, and the old readers are still there. The talk concludes with concrete measures to tell the agent what the architecture *should* be to guide it.