The Repository as Interface¶
david-sanchez's framing: when agents are regular contributors, the repository itself is the primary UI for both humans and agents. Implicit conventions and tribal knowledge — which worked for human onboarding via code review + pair programming + asking questions — do not work for agents.
Explicit, machine-readable, enforceable¶
Every agent-touched repo needs: - Architecture patterns (how new features should be structured) - Dependency policies (approved/prohibited packages) - Testing conventions (style, coverage, which tests for which changes) - File organization rules (placement, naming) - Security requirements (input validation, auth, rate limiting, data handling)
Delivered as skill profiles / instruction files:
- .github/copilot-instructions.md
- Constitution-style specification frameworks
The failure mode (Sanchez, verbatim)¶
Teams skipping this step get agents that "add Redis when the standard is in-memory caching, create new patterns when the convention is to extend existing ones, or introduce new packages when a utility already exists."
Why this matters¶
Same structural claim Horthy makes about qrspi — upfront context investment is where the leverage is, not prompt cleverness. And it's the concrete instantiation of upfront-investment-paradox (Eric): teams that get the MOST out of agents invest the MOST in scaffolding.
Connects to¶
- specification-driven-development — the next rung up.
- qrspi — human-process analog: read the code, write the spec.
- upfront-investment-paradox — sociological parallel.
- harness-engineering — harness conventions are the local version of repo conventions.