Skip to content

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 qrspiupfront 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