Here’s a list of things I have never once specified to my agents, in any skill, any CLAUDE.md, any prompt: what to name files. What to name functions. How to shape a function’s arguments. Where a new file should live. How to structure folders in any framework that leaves the choice open. Not because I haven’t gotten around to it, but because I decided early not to, and it’s one of the quieter reasons my multi-agent setup works as well as it does.
The reasoning is simple to state: I don’t want to disturb the model’s natural instincts about architecture. Everything downstream of that sentence is this post.
The instinct is a census
When a frontend agent building a Next.js app needs somewhere to put a UI component, it puts it in src/components/ui. Every agent. Every time. I have never written that path down anywhere in my life: no skill mentions it, no instruction file, no prompt. The same thing happens in Go: entrypoints land under cmd/, private packages under internal/, without anyone asking. These aren’t rules my agents follow. They’re instincts.
And the instinct has a precise shape: it’s a census. These models have read millions of codebases, and their first impulse about where something goes is effectively a probability distribution over all of them. src/components/ui isn’t correct in any deep sense; it’s just the highest-probability location for a UI component in a Next.js repo, the answer the most codebases gave. When I let the model’s first impulse stand, I’m not being lazy about standards. I’m inheriting the aggregated convention of the entire visible history of software, for free, with zero tokens of instruction.
Writers and readers share the prior
The payoff isn’t the writing. It’s the reading.
The same census that tells an agent where to put a component tells the next agent where to look for one. My teams are a rotating cast: implementers retired at 65% context, fresh reviewers, testers who joined the repo an hour ago. None of them have to learn anything about how this codebase is organized, because it’s organized the way their instincts already predict. Writer and reader converge without ever communicating, the way two agents in my worktree workflow converge on main.
Now look at what an arbitrary house convention does to that. Suppose I decreed that UI components live in app/widgets/elements, or that we name files in some bespoke casing, or shape handler arguments in our special way. I now pay twice, forever, on every agent that touches the repo. The writer has to be steered away from its first impulse: context spent, instructions maintained, drift guaranteed the moment the instruction falls out of a compacted window. And the reader has to guess: grep in the wrong place, search for the canonical name that isn’t there, reconstruct my taste before it can do its job. A house style is a tax levied on every future context window, and what it buys me is the feeling of having opinions.
Style guides were coordination technology for humans
It’s worth remembering why those conventions existed, because they weren’t dumb. Code standards, naming rules, readability guidelines, linters that enforce them: all of it was coordination technology for teams of humans with limited memory, different backgrounds, and no shared instincts. We standardized because a new engineer couldn’t absorb a million codebases before their first commit; the style guide was a compressed substitute.
Agents arrive pre-coordinated. The training data is the style guide, a bigger, more consistently internalized one than any team ever wrote, already installed in every model I’ll ever hire. So in an agentic codebase the best rule, for everything that’s genuinely arbitrary, is no rules at all. I want to be precise about the scope: this is about choices where the census is the only authority, including names, placement, formatting, and structure-by-taste. Conventions with semantics still get enforced, ruthlessly, by machines: the compiler, the tests, the reviewers. I’ve just stopped spending a single token of anyone’s context steering matters of taste, and stopped believing my taste in file placement was load-bearing to begin with.
Grown, not designed
The objection writes itself: surely this descends into chaos. It doesn’t, and the reason it doesn’t is the census again. Letting every agent follow its instincts doesn’t produce randomness; it produces convergence. The result is the most conventional-looking codebase you’ve ever seen, which is exactly the property you want when a new agent parachutes in with zero context: maximum legibility to anything that has read the same internet.
What actually changed is the verb. We used to design codebases: decide the structure up front, then defend it. Mine are grown. The agent that adds a capability decides what the code does and also where it lives, how it’s named, how it’s shaped; and because every such decision samples the same distribution, everything finds its rightful place without a planning meeting. Structure emerges from a thousand small, boringly canonical choices, the same way my features emerge from a pipeline rather than a hero.
I’ve come to think of it as a budget. Every project gets a limited amount of deviation from the ordinary. Deviation is expensive now, paid in instructions, steering, and every future agent’s confusion. I refuse to spend mine on file names. I spend it where deviation is the entire point: on what the software actually does. Everywhere else, the census already voted, and I’ve learned to like the winner.