You are never going to read every line your agent writes, and you should not try. But some of what it writes are decisions rather than instructions, and those you do have to read, every time. This chapter is about making that part small, obvious, and always in the same place.
3.8.1Ask what will change, then pull it out
Before your agent builds anything, ask one question: what about this will I want to change later without touching the logic?
Build a rate limiter and you already know the number moves. Wire up a model and you know you will swap it, and adjust the timeout, and cap the retries. None of that is implementation. They are decisions wearing implementation's clothes, and buried inside a function they are invisible to you and trivially easy for an agent to duplicate somewhere else.
3.8.2Give every module one config file
Each module gets a single settings file, and every knob that module owns lives in it: limits, timeouts, retries, which model, which provider, which feature is switched on.
That file is what you read. You can skip a thousand lines of implementation and still know what your app will do, because every decision that module makes sits on one screen. Keys and passwords are the exception and never belong here; they stay in the secret handling you set up earlier.
Rule of thumb: if answering "what is our rate limit" means opening three files, the config is not doing its job.
3.8.3Leave exactly one way to change it
There is almost always more than one way to achieve something, and your agent will take whichever route it finds first. Say a limit can be set in the config, passed as an argument, or hardcoded in a helper. In a few months it will be set in all three, and they will disagree.
So remove the other routes deliberately. One name, one file, one way to change it. Good design here is not the flexibility you added, it is the options you took away.
That is worth more than any instruction you could write. An agent with one available path takes the right one every time, without being reminded, and without you noticing it was ever at risk of doing otherwise.
3.8.4The same shape in every module
Modules can be completely different inside and should still expose their settings identically: same filename, same location, same style. That sameness is a convention like any other, and it earns its place faster than most.
The payoff arrives the first time you need something from a module you have never opened. You know where to look before you look, and so does your agent.
3.8.5Have your agent pull the knobs out
Do this now: paste the prompt, then open one config file and read it end to end. If it does not tell you what that module will do, a knob is still buried in the code.
