Consistency as Leverage

[joshua-temple]

The Proposal

Pattern predictability reduces tokens more than prompt optimization. The biggest efficiency lever isn't the prompt: it's the codebase. A perfectly tuned prompt over an inconsistent codebase still forces the agent to rediscover conventions on every task; a mediocre prompt over a consistent one doesn't.

Why This Matters

Every inconsistency is a tax the agent pays on every task, forever:

• Context cost. An agent facing three error-handling styles must read all three to pick one. One style means one pattern to load, or none, because it can predict it.
• Correction loops. Unpredictable code produces plausible-but-wrong guesses. Each wrong guess is a full generate, review, fix cycle: the most expensive token pattern there is.
• Verification cost. Reviewers (human or agent) can diff against a known pattern cheaply. Reviewing novel structure means re-deriving intent from scratch.

The economics differ in kind, not just degree. Prompt optimization is linear: each improvement helps each task once. Consistency compounds: every pattern an agent can predict is context it never needs, on every task, for every agent, indefinitely.

What Consistency Looks Like

• One project structure, so file location is inferable from purpose
• Naming conventions strict enough that an agent can guess an identifier before reading it
• Documented architectural patterns, so "how do we do X here" has exactly one answer
• One error-handling idiom and one testing approach per repo

Open Questions

1. Enforcement mechanism. Which patterns get a lint rule vs. a documented convention vs. agent-instruction files (CLAUDE.md etc.)? Proposal needed: a rubric for choosing, since lint rules are cheap to check but expensive to legislate.
2. Measuring the claim. Can we demonstrate the token savings empirically? E.g., run the same task against a consistent and an inconsistent version of a codebase and compare tokens and correction loops. Without a number, this stays a slogan.
3. Evolving a wrong standard. What is the concrete process when a convention proves bad: who proposes, who ratifies, and does migration of old code happen eagerly or lazily?
4. Brownfield onboarding. For an existing inconsistent repo, do we (a) document the dominant pattern and freeze it, (b) migrate incrementally with a ratchet, or (c) enforce consistency only in new code? Each has a different cost curve. Which do we recommend by default?

[joshua-temple]

Accepted. Documented in #13.